After a lot of productive discussion between the Prometheus and
OpenTelemetry community we decided that it made sense for Prometheus to
own its own copy of the code in charge for handling OTLP ingestion
traffic.
This commit is removing the README and update-copy.sh files that had the
previous steps to update the code.
Also it is updating the licensing of all the files to make sure the
OpenTelemetry provenance is explicit and to state the new ownership.
Signed-off-by: Jesus Vazquez <jesusvzpg@gmail.com>
Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com>
If the underlying data is `nil` the default encoding
will render `"null"` which is not accepted by
(some) Prometheus client libraries.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
* fix(scaleway-sd): use public IPs if no private IP present
* tests(scaleway-sd): add instance with routed public ip and no private ip
---------
Signed-off-by: Heyoxe <32708033+Heyoxe@users.noreply.github.com>
Previously the metrics adapters for client-go were registered in an init function.
This resulted in clobbering default metrics providers when these packages are imported
into an application that leverages the default client-go metrics registry.
Instead, let's only register these adapters when requested.
Signed-off-by: Stephen Heckler <sheckler@cloudflare.com>
Up until this point, if a scrape was done with the protobuf format Prometheus would always try to ingest native histograms even with the feature flag disabled. This causes problems with other feature-flags that depend on the protobuf format, like 'created-timestamp-zero-ingestion'. This commit decouples native histogram parsing from ingestion, making sure ingestion only happens when the 'native-histogram' feature-flag is enabled.
Signed-off-by: Arthur Silva Sens <arthur.sens@coralogix.com>
Prometheus restores alert state between restarts and updates. For each rule, it looks at the alerts that are meant to be active and then queries the `ALERTS_FOR_STATE` series for _each_ alert within the rules.
If the alert rule has 120 instances (or series) it'll execute the same query with slightly different labels.
This PR changes the approach so that we only query once per alert rule and then match the corresponding alert that we're about to restore against the series-set. While the approach might use a bit more memory at start-up (if even?) the restore proccess is only ran once per restart so I'd consider this a big win.
This builds on top of #13974
Signed-off-by: gotjosh <josue.abreu@gmail.com>
Currently, running promtool tsdb analyze with the --extended flag
will cause an 'index out of range' error if running it
against a block that does not have any native histogram chunks.
This change ensures that promtool won't try to display data that doesn't exist.
Signed-off-by: Will Hegedus <whegedus@linode.com>
When a rule group changes or prometheus is restarted we need to ensure we restore the active alerts that were firing for a corresponding rule, for that Prometheus uses the `ALERTS_FOR_STATE` series to query the previous state and restore it. If a given rule has high cardinality (think 100s of 1000s for series) this proccess can take a bit of time - this is the first of a series of PRs to improve this problem and I'd like to start with exposing the time it takes to restore a rule group as a gauge.
Signed-off-by: gotjosh <josue.abreu@gmail.com>
