Micrometer: Add @Counted annotation similar to @Timed

Created on 24 Aug 2018  路  6Comments  路  Source: micrometer-metrics/micrometer

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.

doc-update

Most helpful comment

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.

All 6 comments

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.

@jkschneider Good point. However does @Timed also verify the return type (success/throwing)? AFAICT it does not. EDIT: Does it count invocations at all, or just time them?
AKA What use does it have, if my connectDB() method returns after 1ms, if it throws an exception while doing so?

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.

don't count something you can time it is an interesting point, but what about metrics related to execution amount? A number of some executions for example. I guess @Counter will be super useful for business metrics usage

This seems to be resolved already in #1435.

don't count something you can time it is an interesting point, but what about metrics related to execution amount? A number of some executions for example. I guess @counter will be super useful for business metrics usage

The point was that you can count the executions while also timing them with a timer - Timers include a count. That said, as @izeye has pointed out, we've added this in #1435

Was this page helpful?
0 / 5 - 0 ratings