[receiver/prometheus] Add fallback_scrape_protocol when using target allocator #39672
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…allocator This applies a similar fix as 72b834b, but when using TargetAllocator. Signed-off-by: MATILLAT Quentin <[email protected]>
|
Is there a way to test this? Please add a changelog. |
…l addition when using target allocator Signed-off-by: MATILLAT Quentin <[email protected]>
This tests that the provided value is properlly forwared, and if there is no value, that a default is applied Signed-off-by: MATILLAT Quentin <[email protected]>
|
I created the changelog entry, and added a test. |
krajorama
approved these changes
Apr 30, 2025
Co-authored-by: George Krajcsovits <[email protected]>
|
Hmm, looks like we're getting blocked by a vulnerability in another component. I'm going to rebase the PR on top of main to see if it get's solved |
ArthurSens
added
ready to merge
dragonlord93
pushed a commit
to dragonlord93/opentelemetry-collector-contrib
that referenced
this pull request
May 23, 2025
…allocator (open-telemetry#39672) This applies a similar fix as 72b834b, when using TargetAllocator. #### Description For the same reason as we already add a `fallback_scrape_protocol` to the config, this PR add the same behavior when using the Target Allocator. It's important for me, as even the `fallbackScrapeProtocol` from the Prometheus CRD is ignored (I guess it's because the allocator advertise itself as version 2.55.1, which does not support (nor require) `fallback_scrape_protocol`). Maybe it's a change that should be done on the target-allocator side, but I kind of like the symmetry with what we're already doing with provided configuration. #### Link to tracking issue Same issue as open-telemetry#37902, but when using a target allocator --------- Signed-off-by: MATILLAT Quentin <[email protected]> Co-authored-by: George Krajcsovits <[email protected]> Co-authored-by: Arthur Silva Sens <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This applies a similar fix as 72b834b, when using TargetAllocator.
Description
For the same reason as we already add a
fallback_scrape_protocolto the config, this PR add the same behavior when using the Target Allocator.It's important for me, as even the
fallbackScrapeProtocolfrom the Prometheus CRD is ignored (I guess it's because the allocator advertise itself as version 2.55.1, which does not support (nor require)fallback_scrape_protocol).Maybe it's a change that should be done on the target-allocator side, but I kind of like the symmetry with what we're already doing with provided configuration.
Link to tracking issue
Same issue as #37902, but when using a target allocator