Add @Counted annotation similar to @Timed

Sometimes the execution time is not that relevant, but the number of executions is. It would be nice if there were a @Counted annotation that could be used to count how often the annotated method has been called. I know this is currently already possible with a Counter, but this is quite tendious, as I have to inject the MeterRegistry create a Counter for each method and store it in a field and increment it in the method.

Environment: Spring 5+ / Spring Boot 2+ / Spring Boot Actuator

My current thoughts:

• name: The name of the counter/metric
• mode(s) : COUNT_INVOKED/COUNT_RETURNED/COUNT_THROWED - Which modes to record (via tags).

Usecase

Easy way to check for sudden bursts in method calls (client connect) and easy way to check critical components (open DB connection) for liveliness.

[jkschneider]

However does @Timed also verify the return type (success/throwing)?

@ST-DDT See the recently merged https://github.com/micrometer-metrics/micrometer/pull/707, which adds an exception tag to @Timed. So you could drill down dimensionally on exception=none for “success” and anything else for “throwing”.

Does it count invocations at all, or just time them?

Yes, Timer always ships at a minimum count (of invocations), total time, and max. Optionally distribution statistics like percentiles, histograms, SLAs. Depending on the monitoring system, sometimes also min, standard deviation, etc. Standard deviation is an insane metric to even think about for most real world latencies which are almost never normally distributed, but I digress…

It is because timers also count invocations that we say “don’t count something you can time”. Counter statistics are a strict subset, best used for things you can’t time. For example, one counter is jvm.gc.memory.promoted. I can’t time the promotion of bytes.

[jkschneider]

We have this principle… “never gauge something you can count, never count something you can time”. Method executions are by definition time-able. Even if you don’t intend to use timing information now, what harm is there in sending the rest of the timing data which of course includes the count?

I’m worried that this feature would help people do the wrong thing… Many start out thinking just about throughput, and it isn’t immediately apparent that timing information is just as relevant.

I’m thinking about the example of “checking open DB connection for liveliness”. I think I’d almost immediately want to know what the max latency looks like on DB connection interactions right after I’ve satisfied my initial desire to verify that there is a certain throughput of queries going through it.