Cumulative Request Counters: Handle Resets Before Aggregating

A cumulative level carries earlier history

A buyer comparing inference reporting may see a request total beside a time selector and assume the number counts requests completed within that selected interval. First establish whether the display shows a raw cumulative level or a calculation over the interval. The distinction can change the apparent volume without changing any application work.

In OpenTelemetry specification v1.61.0's Stable Temporality section, cumulative points repeat their start time, while delta points advance it. The observation timestamp says when the value was observed; the optional start timestamp identifies its accumulation or unbroken-sequence origin. The specification strongly recommends that start timestamp for restart-aware interpretation. These native OTLP timestamps are not automatically equivalent to Prometheus fields.

For a cumulative reading, the observation time tells you when that level applied; the accumulation origin tells you how far back its history extends. Moving the dashboard's left edge does not erase that earlier history. Two instance levels observed together can still contain different lengths of accumulation.

References: [O1]

Keep the writer identifiable before interpreting a decrease

The Stable Single-Writer section of that OpenTelemetry specification requires one logical writer per stream. It explains that indistinguishable writers can make cumulative points appear to reset. Preserve the intended resource and attribute identity before interpreting successive values.

For the buyer, this means an instance label must actually distinguish the producers being compared. If a display alternates values from two producers under one identity, a smaller second number need not describe the first producer's history. A reset adjustment cannot repair an unresolved question about whose counter was observed.

Metric type matters too. An active-request gauge may fall as work finishes. That decrease does not describe a reset of a cumulative completed-request counter. For correctly identified floating counter samples, Prometheus v3.5.0's resets calculation interprets a decrease between consecutive samples as a reset. That interpretation alone proves neither a particular process restart nor failed application requests. Request the supporting identity and lifecycle context rather than diagnosing an incident from the graph's shape.

References: [O1][P1]

OPS-COUNTER-01: raw fleet totals miss 100 of 110 completions

OPS-COUNTER-01 is wholly fictional counter accounting. Two distinct, correctly identified floating monotonic counters, A and B, count the same declared completed-request unit and outcome. At two matched observation instants, A reads 100 then 10; B reads 200 then 300.

Separately stipulate that A resets to zero after its first observation, with no unobserved increments between that first observation and the reset. There are no other resets or observation losses. The reset is a supplied fact of the example, not a diagnosis inferred solely from the two values.

A therefore contributes 10 new completions after its reset and none before it within this interval. B contributes 300 minus 200, or 100. The stipulated new completions total 10 plus 100, or 110.

Now combine the raw levels first. The starting fleet total is 100 plus 200, or 300. The ending total is 10 plus 300, or 310. End minus start gives 10. The ending fleet total is higher, so comparing only these two totals conceals A's decrease. Subtracting those totals misses 100 of the 110 stipulated completions.

This does not mean 100 requests failed, nor that A completed the missing 100. A's discarded historical baseline offsets part of B's new accumulation in the raw-total subtraction. The error is in the interpretation of the combined evidence.

The no-unobserved-increments assumption is essential. Remove it and A might have completed additional requests before resetting; these two observations cannot determine how many. The complete interval activity would then remain unknown. No elapsed duration is supplied, so 110 is a count under the assumptions, not a requests-per-second result.

Calculate the per-stream change before combining results

Prometheus v3.5.0 documents the order directly: take each series' rate before aggregation. Its rate calculation adjusts breaks in monotonicity and extrapolates to the selected range's ends. The corresponding paragraphs in the current official documentation, checked October 20, 2026, retain those semantics.

OPS-COUNTER-01 explains why the order matters. Keeping A separate from B preserves A's downward step for interpretation. Adding raw levels first leaves only 300 and 310; no later inspection of those two totals can recover the discarded constituent history. Combining compatible per-instance results after reset handling preserves information that a raw-level sum can erase.

Prometheus also documents increase as rate multiplied by the window's duration in seconds. Because it extrapolates over that window, the result can be fractional even when individual increments are integers. A fraction need not imply that the application completed part of a request.

The worked 110 is not a claimed output of either function. Actual estimates depend on the supplied samples and selected window, including extrapolation. Preserving individual streams enables the documented calculation; it does not reconstruct unobserved work before an unseen reset.

References: [P1][P2]

Match the quantity to the request-volume question

A cumulative count describes accumulation from its origin. An interval estimate describes estimated increments over named boundaries. A per-second rate describes the average pace over its calculation window. A buyer needs the quantity that matches the intended comparison, with the counted event unchanged.

The example declares completed requests as its unit. A count of attempts, accepted requests or internal model calls would describe a different event. Retried attempts can also differ from distinct end-user requests. Ask the provider to identify the actual boundary and outcome before comparing volumes across offers.

Useful successful work needs an additional definition. A completed response is not automatically correct, useful or accepted by its recipient. Reset-aware arithmetic can improve the interpretation of the counter without establishing those outcomes.

A change in the included population, window or calculation can change the displayed estimate. Resolve those differences before comparing volumes across offers.

Compare offers at the step where instance histories are combined

Suppose Offer One supplies only raw fleet totals of 300 and 310 and labels their difference interval completions. Offer Two supplies A and B separately, the common observation instants, the counter definitions and the stipulated reset context from OPS-COUNTER-01. It explains each instance's contribution before combining them. These are fictional evidence packages for the same example.

One's arithmetic describes the change in combined levels but leaves the requested completed volume unsupported. Two supports the example's 110 under its stated assumptions. The richer explanation establishes a different evidentiary result; it does not establish that Two's infrastructure is faster.

For an actual request-rate offer, ask the provider to show how each included instance stream contributes to the displayed fleet number. Keep its counting unit, outcome and observation times attached to those contributions. Ask how available accumulation-start context, the selected calculation window and the order of aggregation affect the result.

The explanation should account for instances joining or leaving the reported population and for unresolved identity collisions or observation gaps. A silently omitted instance leaves fleet coverage unanswered.

Have the provider explain whether the result is a cumulative level, an extrapolated interval estimate or a per-second rate. A reset count can help explain a discontinuity, but does not itself supply the missing request volume or a restart diagnosis. Prefer evidence that preserves each included stream through reset handling, then combines compatible results for the same population and window.

Keep neighboring questions with their own evidence. The linked sampled-trace article addresses which requests enter the retained population. The pooled-latency article addresses how distributions support a fleet percentile. Resolving either question does not resolve cumulative-counter resets, and correct reset handling does not establish either of those other claims.

Take a separate equipment project to the physical deployment service

If the equipment decision also requires receiving, rack integration, agreed hardware QA, onsite installation or IT cabling, Leviathan's Complete Physical Deployment service can discuss those physical stages as a defined package. Use the service and project-inquiry links below with a nonconfidential equipment summary, site and intended physical handoff.

Counter interpretation here is educational. Monitoring design, telemetry integration, inference operation and software acceptance remain with the customer's appointed teams and providers. The physical inquiry concerns the equipment work and its records; this article supplies no operating procedure or approval for actual work.

References: [L1]