Check that the generated parser code is consistent with the input definition.
Remove the file before re-generating to make sure that missing goyacc is
not effecting the check.
Fixes: #7488
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
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>
