> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Monotonicity
> Describes metric monotonicity, choosing Counters versus Gauges and proper aggregation for accurate rates and current state measurements
Monotonicity describes whether a metric's value moves in a single direction over time (only increases) or can both increase and decrease. Understanding monotonicity is essential for choosing the right instrument, aggregation, and downstream calculations (for example, computing rates or deltas).
Key distinctions:
* Monotonic metric: Value only increases (e.g., cumulative counters).
* Non-monotonic metric: Value can increase and decrease (e.g., gauges).
Common analogies:
* Monotonic: an electricity meter or an HTTP request counter — readings only go up.
* Non-monotonic: a speedometer or thermometer — readings go up and down.
A typical monotonic example is a counter that tracks the total number of HTTP requests handled by a service. Gauges are used for values that fluctuate, such as current CPU or memory usage.
Operational metrics such as CPU usage, memory usage, and queue length are normally non-monotonic: they rise and fall as load changes. Monotonicity directly influences the choice of instrument type and aggregation method:
* Use a `Counter` for monotonically increasing measurements and aggregate as `Sum` (often used to compute deltas or rates).
* Use a `Gauge` or `ObservableGauge` for measurements that can go up and down and aggregate as `LastValue` (to represent the current state).
Summary table: instrument, aggregation, and example use cases.
| Instrument | Typical aggregation | Typical use case |
| --------------------------: | -------------------------: | --------------------------------------------- |
| `Counter` | `Sum` | Total number of requests, retries, bytes sent |
| `Gauge` / `ObservableGauge` | `LastValue` | Current CPU usage, memory usage, queue length |
| `Histogram` | `Distribution` / `Buckets` | Latency distributions, payload sizes |
Illustration: a monotonic HTTP request counter never decreases. The slope varies (fast during traffic spikes, flat when idle), but the value always moves forward. This property makes Counters ideal for computing rates (requests per second) by taking deltas over time.
Contrast with non-monotonic metrics: queue size, CPU, and memory usage can increase and decrease. These fluctuations require different handling and aggregations because deltas or rate computations on these values do not make sense.
Practical examples (pseudocode):
* Monotonic Counter (OpenTelemetry-like pseudocode)
```javascript theme={null}
const requests = meter.createCounter("http.server.requests", {
description: "Total number of HTTP requests"
});
// Increment on each request
requests.add(1, { route: "/api" });
```
* Non-monotonic Gauge (OpenTelemetry-like pseudocode)
```python theme={null}
cpu_gauge = meter.create_observable_gauge(
"system.cpu.usage",
callback=observe_cpu_usage,
description="Current CPU usage percentage"
)
```
In short:
* If the measurement only ever increases, treat it as monotonic: use `Counter` and aggregate as `Sum`.
* If it can go up and down, treat it as non-monotonic: use `Gauge`/`ObservableGauge` and aggregate as `LastValue`.
Choosing the correct instrument and aggregation for monotonic vs. non-monotonic metrics ensures accurate downstream calculations (for example, computing rates, deltas, or current-state snapshots). This improves alerting, dashboards, and capacity planning.
Do not model decreasing values with a `Counter`. Treating non-monotonic data as monotonic leads to incorrect sums, rates, and alerts. If you need to represent decreases, use a `Gauge` or an appropriate observable instrument.
Links and references:
* [OpenTelemetry Metrics Specification](https://opentelemetry.io/docs/specs/otel/metrics/)
* [OpenTelemetry Instrumentation Concepts](https://opentelemetry.io/docs/concepts/)
* [Monitoring Best Practices: Counters vs Gauges](https://prometheus.io/docs/practices/naming/)