Counter Metrics

Counter metrics track monotonically increasing occurrences such as requests, errors, or processed messages. They are useful for measuring event rates and total counts over time.

A counter is a metric whose value increases when an event occurs. Typical examples include HTTP requests received, exceptions raised, jobs processed, or messages consumed. A counter should not normally decrease during the lifetime of the process or monitored resource.

Counters are most useful when converted into a rate over a time interval. For example, a monitoring system can calculate requests per second from successive counter samples. This makes counters useful for traffic, error-rate, and throughput measurements.

A counter can reset when its application or process restarts. Monitoring systems therefore need to recognize resets rather than interpreting a restart as a large negative change. In practice, rate calculations commonly account for such resets.

Counters differ from gauges because a gauge represents a current value that may move in either direction. A queue-depth gauge can rise and fall, while a messages-processed counter continually accumulates successful processing events.

Key points

• Counters represent cumulative event occurrences.
• A counter normally increases rather than decreases during its lifetime.
• Rates derived from counters are useful for throughput and error-rate monitoring.
• Process restarts can reset a counter.
• Use a gauge for values that naturally increase and decrease.

Interview questions

What is a counter metric, and when would you use one?

A counter is a cumulative metric used to record occurrences of events. I would use it for things such as HTTP requests, errors, completed jobs, or consumed messages. Each occurrence increments the counter. I would usually derive a rate from it when I want to understand activity over a period.

Why are counters often used to calculate rates?

A counter tells us how many events have accumulated, but its absolute value is often less useful than how quickly it is changing. Comparing samples over a time interval gives the number of new events during that interval. Dividing that change by the elapsed time produces an event rate. This can be used for metrics such as requests per second or errors per minute.

Can a counter decrease?

A counter is intended to represent a monotonically increasing quantity, so it should not decrease during normal operation. However, its observed value can reset when the process or metric source restarts. Monitoring systems should distinguish such a reset from normal counter behavior. If a quantity naturally moves both upward and downward, a gauge is generally a better fit.

How would you instrument request and error metrics in a Java backend?

I would maintain a request counter that increments once for each completed or received request, depending on the chosen measurement point. I would use a separate error counter for requests that meet the defined error condition. Both metrics should have carefully chosen labels, such as HTTP method or status class, while avoiding high-cardinality values like arbitrary user IDs. Rates of these counters can then be used to monitor traffic and errors.