Data Monitoring / Alerting & Observability Design
Observability: Counter versus gauge semantics
A monotonically increasing request counter is plotted as current load. Inspect metric type, reset behavior and the intended time window.
Environment and inputs: Platform-neutral monitoring design with Prometheus and OpenTelemetry examples; syntax and signal availability depend on the deployed stack.
Failure scenario
A monotonically increasing request counter is plotted as current load. Confirm the cause before choosing a fix.
Evidence to collect
Inspect metric type, reset behavior and the intended time window. Record the time, affected scope and a healthy comparison interval.
Worked diagnostic example
Illustrative PromQL request-counter rate; replace the metric and labels with the documented instrumentation.
sum by (service) (rate(http_requests_total[5m]))Fix the confirmed cause
Derive an appropriate rate for counters and retain direct values for gauges where meaningful. Write the expected result first. Change one relevant setting at a time.
Check the result and hand over
Repeat the check for counter versus gauge semantics using the same scope and a representative interval. Check that the symptom is resolved, expected records are present and downstream results are correct. If coverage, correctness or latency worsens, restore the recorded configuration through the agreed rollback process.
Scope and precautions
Prefer read-only access and limit queries to the relevant period or dataset. This example has not been tested on your systems. Test changes in an approved environment. Keep credentials and sensitive data out of shared evidence.