Make otelarrow admission control metrics consistent #36359
Merged
Conversation
This file contains 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
…essed in MiB of request data
…tor-contrib into jmacd/redo_36033_except_admission
…opentelemetry-collector-contrib into jmacd/inst_admit
…tor-contrib into jmacd/inst_admit
mwear
approved these changes
Nov 14, 2024
moh-osman3
approved these changes
Nov 14, 2024
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.
Description
The OTel-Arrow receiver has metric instruments which are not perfectly useful because they were applied inconsistently. To make these consistent and simplify the implementation, the instruments are moved from the Arrow-specific receiver code path to the new admission controller and provided through asynchronous instruments.
This means that the admission controller, which applies to both OTLP and Arrow data paths, reflects resources acquired by both paths consistently.
Note that this PR is a draft because it has to be applied after #36141.The former use of synchronous instruments required two calls per acquire, whereas the use of asynchronous instruments probes the controller twice per collection interval.
Note that because the admission controller only sees bytes acquired, the former counters for requests-in-flight and items-in-flight have been removed. We do not believe these were very useful.
Link to tracking issue
Fixes #36334
Testing
✅
Documentation
✅