open-telemetry / open-telemetry/opentelemetry-java
Allow users to customize AttributesProcessor and append to exist View
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 2.5k
- Forks
- 1k
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 58
Description
Is your feature request related to a problem? Please describe.
I am a framework developer, and my framework integrates the opentelemetry sdk. In my case, I need to trim or perform additional processing on the attributes of all instrument metrics (to adapt to different observability systems). Although I can achieve attribute trimming by registering a View, if there are already existing views, I need to modify all of them. The io.opentelemetry.sdk.metrics.internal.view.AttributesProcessor can solve my problem. However, the current constructor of AttributesProcessor is not public, and the getAttributesProcessor method in the io.opentelemetry.sdk.metrics.View class and the addAttributesProcessor method in the io.opentelemetry.sdk.metrics.ViewBuilder are also not public. Currently, I can only use reflection for handling.
Describe the solution you'd like
Make AttributesProcessor, getAttributesProcessor, and addAttributesProcessor public. hopefully View can be mutable, it is not possible to directly append AttributesProcessor to an existing view now.
Describe alternatives you've considered
Maybe AttributesProcessor can be separated from View, can be registered in SdkMeterProviderBuilder. Similar to View, can use InstrumentSelector to select instrument metrics to apply AttributesProcessors.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading io.opentelemetry.sdk.metrics.internal.view.AttributesProcessor, View, and ViewBuilder, focusing on their constructors and processor access or mutation methods. Clarify whether the completed change should expose these APIs or introduce provider-level registration, then define tests for customizing processors and appending one to an existing view.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100