Dependency: Update to Prometheus 0.300.* #36873
Conversation
ArthurSens
requested review from
a team,
fatsheep9146,
jpkrohling,
dashpole,
mx-psi and
songy23
as code owners
github-actions
bot
added
exporter/datadog
github-actions
bot
requested review from
Aneurysm9,
ankitpatel96,
bertysentry,
chrroberts-pure,
dgoscn,
dineshg13,
gouthamve,
gramidt,
jade-guiton-dd and
liustanley
| // This includes ScrapeManager lib that is used by the Promethes receiver. | ||
| // We need to set the validation scheme to _something_ to avoid panics, and | ||
| // UTF8 is the default in Prometheus. | ||
| model.NameValidationScheme = model.UTF8Validation |
There was a problem hiding this comment.
Note for after this merges (non-blocking): Is this actually necessary? Seems like it should always be set to this by default? https://github.com/prometheus/common/blob/cc17dab08e7c33f70e3b5ab865d6789f0ff95761/model/metric.go#L37
There was a problem hiding this comment.
Hmmm, I think that change in prometheus/common was made after this PR was open.
I haven't tested this with the newest common version, definitely worth a try as a follow up to this
There was a problem hiding this comment.
What would happen if someone is still running Prometheus 2.x but upgrades their OTEL Collector pipelines first? I'd imagine that could be a common scenario since people are probably not trying to do these upgrades in lock-step.
There was a problem hiding this comment.
Great question!
Even though the default validation scheme changes, we still use our own library to translate OTLP into Prometheus. This package still translates everything just like the old ways so we don't expect any changes here.
| @@ -56,6 +63,7 @@ func createMetricsReceiver( | |||
| nextConsumer consumer.Metrics, | |||
| ) (receiver.Metrics, error) { | |||
| configWarnings(set.Logger, cfg.(*Config)) | |||
| addDefaultFallbackScrapeProtocol(cfg.(*Config)) | |||
There was a problem hiding this comment.
Note for after this merges (non-blocking): If this is setting the default scrape protocol, why do we still need to set it in our configuration everywhere?
There was a problem hiding this comment.
By everywhere you mean all those test changes I've made?
There was a problem hiding this comment.
That, and also in the compliance repo
|
Some questions, but lets get this merged and fix them afterwards |
|
Can you re-open the compliance PR? |
|
Here you go prometheus/compliance#143 |
dashpole
added
the
ready to merge
|
That was some work, thank you everyone who helped here ❤️ |
|
@ArthurSens I think this breaks existing configs. Note: I'm building a custom collector via https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder, so YMMV. But as far as I can tell, this will also affect users that do not build their own image. After updating to Setting |
You're correct! We're trying to fix the problem here: #38018 |
This is now effectively a required parameter, see: open-telemetry/opentelemetry-collector-contrib#36873 (comment)
This is now effectively a required parameter, see: open-telemetry/opentelemetry-collector-contrib#36873 (comment)
Ah, there is already an issue for it. Sorry about the ping then. I searched the repo for existing issues, but I searched for |
…dation (#38018) #### Description During the release process, we noticed a breaking change in the Prometheus receiver caused by #36873. In that PR, I tried adding a fallback scrape protocol by default everytime the PrometheusReceiver was built, but it turned out that config validation happened even before the component was created. And the collector fails startup with invalid configuration This PR moves the addition of scrape protocol to the validation step. <!-- Issue number (e.g. #1234) or full URL to issue, if applicable. --> #### Link to tracking issue Fixes #37902 <!--Describe what testing was performed and which tests were added.--> #### Testing <!--Describe the documentation added.--> #### Documentation <!--Please delete paragraphs that you did not use before submitting.-->
…dation (open-telemetry#38018) During the release process, we noticed a breaking change in the Prometheus receiver caused by open-telemetry#36873. In that PR, I tried adding a fallback scrape protocol by default everytime the PrometheusReceiver was built, but it turned out that config validation happened even before the component was created. And the collector fails startup with invalid configuration This PR moves the addition of scrape protocol to the validation step. <!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. --> Fixes open-telemetry#37902 <!--Describe what testing was performed and which tests were added.--> <!--Describe the documentation added.--> <!--Please delete paragraphs that you did not use before submitting.-->
#### Description #36873 the prometheus receiver can now keep dots in metric names rather than converting them to underscores. E.g. say there is a metric `my.metric` scraped from prometheus receiver, its name is `my_metric` before 0.120.0 vs. `my.metric` now. This should have broken some datadog integration tests, but those are skipped in race detector (which is always on in CIs) so the failures did not show up in CIs.
#### Description Add a changelog amending #36873. There are indeed several breaking changes associated with the 3.0 version update: https://prometheus.io/docs/prometheus/latest/migration/ #### Link to tracking issue related to http://github.com/open-telemetry/opentelemetry-collector-contrib/issues/38097
This reverts commit af6b17e.
Description
Supersedes #36642
This PR updates the prometheus/prometheus library in our go.mods to 0.300.* (which represents Prometheus 3.0).
It touches many go.mod files, but the Prometheus Receiver is the only component heavily affected by breaking changes.