Skip to content
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

Add a dropwizard-metrics -> OTel metrics bridge #6259

Merged
merged 3 commits into from
Jul 15, 2022

Conversation

mateuszrzeszutek
Copy link
Member

This is the first version of the dropwizard->OTel metrics bridge; I think it'll very likely have a somewhat limited usability, because the dropwizard metrics API does not have the concept of tags/attributes (!). Some of the dropwizard reporters/exporters just append the tag values to metric names (for example, the signalfx one, lol), and this bridge does not detect such conventional use. I guess we can try to implement this later, if there's any demand for it.

@mateuszrzeszutek mateuszrzeszutek requested a review from a team July 4, 2022 09:48
@trask trask merged commit db1250d into open-telemetry:main Jul 15, 2022
LironKS pushed a commit to helios/opentelemetry-java-instrumentation that referenced this pull request Oct 23, 2022
* Add a dropwizard-metrics -> OTel metrics bridge

* disable by default

* enable metrics for test
LironKS pushed a commit to helios/opentelemetry-java-instrumentation that referenced this pull request Oct 31, 2022
* Add a dropwizard-metrics -> OTel metrics bridge

* disable by default

* enable metrics for test
@mateuszrzeszutek mateuszrzeszutek deleted the dropwizard-metrics branch November 18, 2022 10:27
LironKS pushed a commit to helios/opentelemetry-java-instrumentation that referenced this pull request Dec 4, 2022
* Add a dropwizard-metrics -> OTel metrics bridge

* disable by default

* enable metrics for test
@Ch4ni
Copy link

Ch4ni commented Dec 22, 2022

apologies for the necro-thread. I'm looking into dropwizard->Otel at the moment and just came across this code.

Would something like the transformers from this PR apply to the DropwizardMetricsAdapter? Obviously it would be a little different from an end-user point of view because one would need to supply a Customizer at the agent level, rather than at a runtime code level.

@mateuszrzeszutek
Copy link
Member Author

Hey @eurythmia ,

I assume that you want to extract the attributes from the metric name, is that correct?
Providing custom code that'd perform the attributes extraction to the agent would be very non-trivial due to all the classloader magic and shading that we're doing; but I think it should be possible to extract a library instrumentation (which you would have to set up in your app manually) that'd cooperate with the javaagent well. Would that fit your use case? If so, can you create an issue with a bit more detailed description of what you want to achieve?

@Ch4ni
Copy link

Ch4ni commented Dec 28, 2022

Hey @eurythmia ,

I assume that you want to extract the attributes from the metric name, is that correct?

That's the current use case, yes :-)

Providing custom code that'd perform the attributes extraction to the agent would be very non-trivial due to all the classloader magic and shading that we're doing; but I think it should be possible to extract a library instrumentation (which you would have to set up in your app manually) that'd cooperate with the javaagent well.

Clarifying question: are you proposing that the code to perform attributes extraction be provided in the same way "agent extension"s/non-contrib-instrumentations are provided (i.e. it's code that lives outside of the agent, and is available within the agent's runtime classpath/context, distinct from the application's runtime classpath/context)? If so, this is sort of what I was envisioning when I proposed this question - I don't think that the agent should have any responsibility to grab anything from the application's runtime classpath/context, that just sounds messy 😅

Would that fit your use case? If so, can you create an issue with a bit more detailed description of what you want to achieve?

I think we're on the same page here, but I'll have to go through the source code a bit more to ensure that I am - once I've done so I can definitely raise a detailed issue that describes the problem and solution.

Thanks for taking the time to respond, I appreciate it!

@mateuszrzeszutek
Copy link
Member Author

Clarifying question: are you proposing that the code to perform attributes extraction be provided in the same way "agent extension"s/non-contrib-instrumentations are provided (i.e. it's code that lives outside of the agent, and is available within the agent's runtime classpath/context, distinct from the application's runtime classpath/context)?

Not exactly - I was thinking of a completely separate library instrumentation that you could use both with and without the agent; kind of like the micrometer OpenTelemetryMeterRegistry. It'd most likely come in a form of a custom dropwizard MetricRegistry, with custom metric instruments implementations that simply delegate to OTel instruments. You would have to use that OTel registry in your application, and you could pass any attributes transformer function you want.

Right now we don't have any instrumentation-specific SPIs; and we have lots of library instrumentations that can work either standalone or with the agent (well, most of them can). I'm a little bit hesitant about introducing a completely new entity when we already have an established pattern that works for most cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants