opentelemetry-java-contrib
opentelemetry-java-contrib copied to clipboard
open-telemetry
OTel Metrics Micrometer MeterProvider
First pass at implementing a MeterProvider that wraps Micrometer MeterRegistry.
It looks like the async instruments from OTEL may need more machinery to work correctly here.
I see, that was my misunderstanding. I assumed that the callback would hold onto the observer and would continually publish results.
What's the cost of registering counters + things w/ labels in micrometer? The current mechanism to allow Baggage labels in metric attributes may come with large performance costs.
Every permutation of tags is a separate instrument. As of today Micrometer has no concept of exemplars.
Every permutation of tags is a separate instrument. As of today Micrometer has no concept of exemplars.
Baggage != exemplars. baggage is the ability to attach labels (dynamically) via distributed context propagation.
See: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/baggage/api.md
Baggage != exemplars. baggage is the ability to attach labels (dynamically) via distributed context propagation.
Right, in that case we can just treat them like Attributes and mix them in with the Tags used to create each instrument. Should be easy as I do have Context readily available. I'd be concerned that Baggage would contain keys with very high cardinality, though, but that's an issue that any metrics exporter will have to deal with.
Just curious, is there a reason to have an SDK that implements the OTel metrics API using micrometer, instead of the other way around, a micrometer registry that writes to the OTel metrics API? Is it to allow OTel users to have access to all of micrometer registry implementations? If the collector can fill that gap, the reverse may be more valuable by opening up cool features like exemplars and baggage to micrometer users (at least I think it'd be possible).
Of course it could be good to have both, just wondering.
@anuraaga
Just curious, is there a reason to have an SDK that implements the OTel metrics API using micrometer, instead of the other way around, a micrometer registry that writes to the OTel metrics API?
My use case is that we already have a series of Spring apps that make fairly extensive use of Micrometer and they report to a custom metrics exporter that only has Micrometer bindings. Having a binding from OTel to Micrometer would make it easier to adopt components that make use of OTel metrics (e.g. BatchSpanProcessor) without having to take on the risk of replacing the rest of the metrics config. That said, given that I'm finding it more difficult than I had anticipated to bridge between the facades in this direction I am questioning whether it will be easier or less risky. But I do think that having a bridge between Micrometer and OTel in both directions could be useful.
Hi @HaloFour - I think this was implemented by @mateuszrzeszutek now
https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/micrometer/micrometer-1.5/library
Should we go ahead and close this PR?
I think this was implemented by @mateuszrzeszutek now
https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/micrometer/micrometer-1.5/library
This PR seems to implement the reverse bridge: OTel -> Micrometer. Anyway -- is this still valid/needed?
Personally, anyone using Micrometer today is more likely to want to stick with the Micrometer API, and would be more interested in a OTeL Registry for Micrometer as an alternative output mechanism.
What are your thoughts @jonatan-ivanov?
I believe that the bridge is still needed as there will be projects that need to make use of both facades and Micrometer is already more established, especially in Spring Boot applications. But I think that this PR draft specifically took a naive approach which won't work for a proper bridge, so I'd be fine closing this PR as long as an issue remains open to explore this space.
@kenfinnigan Since this is bridging the OTel Metrics API to the Micrometer API, I guess this would be useful for those users who want to use the OTel Metrics API but also want to use a backend that is not supported by OTel but supported by Micrometer.
The OTel registry/OTLP support in Micrometer I guess is the other way: people want to use the Micrometer API but they also want to use OTLP (fyi: we are planning to add OTLP support in our next feature release).
Sorry I had forgotten that this is the reverse direction. Though I tend to agree with @kenfinnigan that there probably wouldn't be that much usage of this, and it is a fairly complex beast. If someone wants to continue with this PR we could still consider it but maybe it's ok to go ahead and close for now.
fyi: we are planning to add OTLP support in our next feature release
@jonatan-ivanov @shakuzen Just checking whether this is still needed given we have the OTel API MeterRegistry now? I guess the use cases are the same, but the OTel API version will have more features (e.g., integrate with other OTel instrumentation, especially tracing to get exemplars) and don't know of any drawback though there may be.
@HaloFour is this replaced by https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/micrometer-meter-provider?
