Add a dropwizard-metrics -> OTel metrics bridge

[mateuszrzeszutek]

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.

[Ch4ni]

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]

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]

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]

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.