Support Micrometer Annotations

[kelunik]

Is your feature request related to a problem?

Currently, we need to use AspectJ to support @Timed in Micrometer.

Describe the solution you'd like

I'd be great if we could let the Elastic APM Agent handle the @Timed and other annotations of Micrometer to be able to drop our AspectJ dependency.

Describe alternatives you've considered

• Keep AspectJ in use, which currently blocks testing Java 25, see Java 25 Support eclipse-aspectj/aspectj#346
• Manual instrumentation instead of using annotations, polluting our business logic

[SylvainJuge]

Hi !

From what I understand here, using @Timed allows you to capture a metric that represents the time spent in a specific method, and in order to do this "magic" AspectJ is required (probably an implementation detail of Micrometer here).

In general this kind of use-case is best handled by capturing a transaction or a span, which even provides more flexibility in the name and in the attributes.

Can you elaborate a bit on what kind of code is executed through AspectJ in your case ? Are you creating a span for every method annotated with @Timed, or are you capturing this as metrics with micrometer ? If captured as metrics with micrometer, those metrics should be already captured.

Going back to the capturing as spans/transactions, there are multiple ways to do that, even without modifying your code:

• by configuration using trace_methods
• using annotations provided the agent Public API

However, for a more future-proof approach, if you can I would suggest to switch to an OpenTelemetry-based solution:

• use OpenTelemetry java agent or Elastic distribution of OpenTelemetry (EDOT)
• use OpenTelemetry API in your application and use either manual instrumentation or annotations
• as an alternative to code modification, you can use configuration to capture methods as spans (equivalent to trace_methods with Elastic APM Java agent).

[kelunik]

From what I understand here, using @Timed allows you to capture a metric that represents the time spent in a specific method, and in order to do this "magic" AspectJ is required (probably an implementation detail of Micrometer here).

Yes, that's an implementation detail of Micrometer. There's an open feature request for an equivalent in open telemetry: open-telemetry/opentelemetry-java-instrumentation#7030

Currently, AspectJ is required, but it'd be great if Elastic APM can do it instead, like with @CaptureSpan.

In general this kind of use-case is best handled by capturing a transaction or a span, which even provides more flexibility in the name and in the attributes.

The issue with spans is that they're not recorded if there's no transaction and if sampling is used, they don't provide a complete picture. That's why we sometimes use metrics and sometimes spans.

[kelunik]

This won't be neccessary with Java 25 anymore, see https://blog.kelunik.com/2025/08/24/method-trace-java-25.html.

[SylvainJuge]

Thanks @kelunik for writing and publishing your blogpost !

I wasn't aware of this new API introduced in Java 25, this is really interesting as it seems to fit exactly your use-case where you can monitor execution time without having to use instrumentation API as everything is managed through JFR and the code remains very minimal.

I think it could even be possible to implement a generic version of this and control it only through configuration. That could probably be an interesting contribution to make in opentelemetry instrumentation (or contrib) as well.

As a side note I would suggest to try using the stable code semantic conventions for the metric attributes.

[kelunik]

I think it could even be possible to implement a generic version of this and control it only through configuration. That could probably be an interesting contribution to make in opentelemetry instrumentation (or contrib) as well.

Yes, already thought about this. It's so simple, that providing this in a separate package seems like a bad idea (think leftpad in node), but shipping this as part of Elastic APM / Open Telemetry API sounds like a good idea.

As a side note I would suggest to try using the stable code semantic conventions for the metric attributes.

Good point, I've adjusted that in the post, thanks!