Essential tags for a request latency metric

WHAT THIS TESTS This evaluates whether you can design metric labels that maximize analytical value while respecting the cardinality limits of a time-series database.

A GOOD ANSWER COVERS The essential labels for a request latency metric are the HTTP method, a normalized route or endpoint template rather than the raw path, and the response status code or status class. Method lets you separate reads from writes, the route template lets you compare latency across logical endpoints, and the status code lets you distinguish fast errors from slow successes. Depending on topology you may add the service name, instance or pod, and the region or availability zone, which help localize where slowness occurs. The crucial reasoning is that every label value must be bounded and low cardinality: a handful of methods, a fixed set of route templates, a small set of status codes. This keeps the number of time series manageable while still letting you answer questions like which endpoint is slow, for which method, returning which status, in which region.

COMMON WRONG ANSWERS Adding unbounded labels such as user_id, session_id, request_id, full unnormalized URL with query strings, or a timestamp, each of which causes a cardinality explosion that can overwhelm the metrics backend. Such high-cardinality dimensions belong in logs or traces, not metric labels.

LIKELY FOLLOW-UPS How do you normalize a path like /users/123 into /users/:id? Where should per-user detail live instead? How does adding one high-cardinality label multiply series? What does the OpenTelemetry HTTP semantic convention recommend?

ONE CONCRETE EXAMPLE A histogram metric http_request_duration_seconds carries labels method set to GET or POST, route set to a template like /orders/:id, and status set to 200, 404, or 500. With a few methods, a few dozen routes, and a handful of status codes, the series count stays in the low thousands, fully manageable. You can then query p99 latency for POST on /orders/:id returning 500 to spot a slow failing write path, while user-level identifiers stay out of the metric and live in correlated traces instead.