Metric types encode the question you can answer

A counter accumulates a nonnegative quantity such as completed requests or bytes sent. Its ordinary trajectory rises, but process restarts can reset it. A gauge records a state that can increase or decrease, such as current queue depth or available memory. A distribution records many observations, retaining enough information for questions beyond a single total. For nonnegative durations, a count and accumulated duration can produce a mean; histogram buckets additionally preserve coarse shape. None of these instruments automatically states where an observation begins or which requests qualify.

Keep units and event boundaries explicit. A count of request attempts differs from unique user operations, and a server-side duration differs from client-perceived waiting. A gauge sampled every fifteen seconds can miss a short spike between scrapes. A counter sampled at the same frequency can preserve accumulated event count across that interval while losing timing detail, assuming the process and collection path preserve it. Instrument choice therefore trades which information survives aggregation; exporting a final average alone discards the weights needed to combine instances correctly.

Prometheus rate and increase interpret counter decreases as resets and use the observed sample sequence; they cannot recover arbitrary events that disappeared before an unobserved reset. Compute a rate for each original series before summing across instances. If one counter resets while another rises, summing the raw counters first can hide the decrease and erase evidence the reset-aware operation needed. Changing instance identity, duplicate collection, and missing scrapes require their own treatment. A smooth aggregate is not proof that every underlying source was complete and counted once.

To combine latency means, sum compatible duration totals and divide by summed observation counts. Averaging instance averages gives equal weight to each instance rather than each request, which is a different question. The same principle applies to success ratios: a quiet unhealthy instance and a busy healthy instance do not contribute equally to an event-weighted service ratio. Keep windows, units, and eligible populations aligned. Do not sum gauges blindly either: adding independent queue lengths can be meaningful, while adding replica copies of one logical value can double-count it.

Build fixtures containing a restart, an idle instance, a missing scrape, and unequal request counts. Predict the desired result from the event history, then compare the metric query. Decide how to represent missing or stale evidence rather than filling every gap with zero. OpenTelemetry additionally distinguishes delta and cumulative temporality and monotonic from nonmonotonic sums; exporting or converting them requires the matching data-model semantics. A collector that changes temporality needs state and reset handling, not simply a different label on the same numeric samples.

The queue lab provides a gauge example only. Reset, set both arrival λ=1 and service μ=3, predict that current backlog falls from four to zero in two seconds, then Play or Step. For a separate growing-state case, Reset and re-enter both λ=4 and μ=2, predict growth, then inspect. Rate edits retain elapsed time and recalculate from the initial four; they do not switch a live accumulated queue. The lab does not expose a request counter or implement rate queries. Its limited purpose is to show why a falling state value is not a negative event count.