-
Notifications
You must be signed in to change notification settings - Fork 848
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MetricsProcessor #1810
Comments
Hi @parallelstream . Thanks for this suggestion. I think it is an interesting one, but I think that this is something that should be specified cross-language. Can you open up an issue in the specs to start the discussion there? Just as a heads-up, the specs folks might ask for an OTEP to track this, since it's a significant change to the standard metrics SDK implementation. In addition, we generally like to see draft PRs in several languages with a rough implementation to go along with the spec issue. Would you be willing to do that prototyping work, as well? Thanks! |
sure, will do both, @jkwatson |
Opened the one together with PR here open-telemetry/opentelemetry-specification#1116 |
@as-polyakov can we close this issue now that we have the ability to deal with labels in views? |
resolved |
Is your feature request related to a problem? Please describe.
Similar to SpanProcessor, we need a hook for metrics which would allow users to intercept metrics lifecycle eventы with their own logic.
Describe the solution you'd like
Describe alternatives you've considered
Main problem I am trying to address - is to be able to add certain labels to metrics depending on Context (i.e. dynamically). One alternative can be to just do that and make it a standalone feature aka "sticky labels". Had a simple PR for this here. However MetricsProcessor is a more generic solution which can address other use cases.
As for the implementation, instead of using immutable Labels we can pass ReadWriteLables object, this would make it follow the same patter as in SpanProcessor
Additional context
There's a problem with this approach - statically bound instruments will not be able to dynamically add labels during record operation. Since we only intercept onLabelsBound() in case one statically binds an instrument and then uses that to record multiple measurements with different contexts, only first bind call will be intercepted
The text was updated successfully, but these errors were encountered: