@Timed annotation with dynamic tags derived from input arguments and/or output

Use case

While @Timed annotation provides good starting point for annotating particular methods in a single service. In case of a platform single API can get used by completely different clients with somewhat different access patterns. Implies different notification thresholds or alert receivers. Consider a sample api

    @Timed
    public Response process(BucketId bucketId, ProcessingParams params) { ... }

If all incoming requests are timed in a same manner a metric visualization could take the form of

However if we were to take a look at it with a bit more precision, say plot requests to different bucket ids separately one could arrive at

Going further, excluding outliers paints a completely different picture

As it usually happens, some like 20% of requests of specific form could incur up to 80% of support burden and identifying those would make the whole monitoring exercise much more useful.

Proposal

Introduce a new (or extend existing?) @Timed annotation which could take optional list of tag names as well as custom expressions similar to SpEL

So that annotations could take form of

    @Timed(
       inputTags = {"bucket_id", "#{[0]}"},
       outputTags = {"status": "#{[0]?.status}"}
    )
    public Response process(BucketId bucketId, ProcessingParams params) { ... }

Cardinality

This, of course, is open to some abuse in cases where cardinality of input/output values becomes high. Consider what would happen in example above if bucket_id turns out to be a randomly generated UUIDv4. In such a case, making sure the right value/expression is provided is ultimately part of developer’s responsibility.

It is worth noting at this point the current alternative is to provide a dedicated endpoint to every specific use-case which does not seem scalable.

References

This issue has use case similar to #1586 yet a different approach to address it. This issue is different from extraTags in a sense that extraTags are static and current issue proposes dynamically evaluated values. This issue is different from #1265 in a sense that it is protocol agnostic. It is also different from #535 in a sense that tag value is provided “declaratively”

[michaelmcfadyen]

Micrometer is decoupled from spring so I’m not sure that using SpEL is a suitable solution.

[codefromthecrypt]

this concern came up in a library I worked on in the past, Feign. It is common to any annotation based modeling library I think. What we used instead of adding things to the annotation itself, is a helper. This allows you to do whatever you want, including a spring specific implementation if available. For example a null “expander” or “extractor” could defer to a default or a platform based lookup

https://github.com/OpenFeign/feign/blob/master/core/src/main/java/feign/Param.java#L36

https://github.com/OpenFeign/feign/blob/d3f7d76f57edc07cc5008cd01d0477effe90b0c3/README.md#custom-expansion

maybe this is useful?