What labels should and should not be put on a metric? [Intermediate]
Answer
Metric labels should describe stable, bounded dimensions that are useful for aggregation, such as service, route, method, status, environment, cluster, and dependency. They should not contain unbounded identifiers such as user_id, request_id, session_id, raw URL, or exception message.
Technical explanation
Labels multiply time-series cardinality, so every new label must have operational value.
Keep label semantics consistent across services so dashboards and alerts can be reused.
Use logs and traces for high-cardinality investigative fields, not metrics.
Hands-on example
Example: good metric: http_requests_total{service='checkout', route='/orders/{id}', method='POST', status='201'}. Bad metric: http_requests_total{url='/orders/abc123', user='u987', request_id='...'}. The bad version is expensive and hard to aggregate.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Observability interview questions
- What is observability, and how is it different from traditional monitoring? [Basic]
- What are the three pillars of observability (metrics, logs, traces)? [Basic]
- What is the difference between monitoring and observability in practice? [Basic]
- What are the four golden signals of monitoring? [Basic]
- What is the difference between the USE method and the RED method? [Basic]
- When would you use the USE method versus the RED method? [Basic]
- What is an SLI, an SLO, and an SLA, and how do they relate? [Basic]
- How do you choose good SLIs for a service? [Basic]