Dependency: Update to Prometheus 0.300.*#36873
Conversation
ArthurSens
requested review from
a team,
dashpole,
fatsheep9146,
jpkrohling,
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
|
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 https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/38097
This reverts commit af6b17e.
8 participants
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.