Observabilityhard

How do you handle high-cardinality labels/tags in metrics?

Tags

#metrics#cardinality#labels

Back to category Practice quiz

Answer

High-cardinality labels (e.g., userId) explode metric series. Avoid them in metrics, use aggregation or bucketing, and move per-entity details to logs or traces.

Advanced answer

Deep dive

Cardinality drives storage cost and query performance:

Prefer low-cardinality dimensions (status, region, tier).
Use histograms/buckets for ranges instead of unique IDs.
Keep per-user/per-order info in logs or traces.
Apply label allowlists and drop unbounded labels at ingestion.

Examples

Bad vs good labels:

Bad: user_id=123456, request_id=... (explodes series)
Good: status=500, region=eu-west, route=/checkout

Common pitfalls

Adding request IDs as metric labels.
Allowing arbitrary tags from clients.
Not monitoring series count growth.

Interview follow-ups

How do you detect cardinality explosions early?
When is it acceptable to use higher cardinality?
How do logs and traces complement metrics here?

Related questions

Explain the RED and USE methodologies and when to use them.

#red#use#metrics

Logs vs metrics vs traces — when do you use each?

#observability#logs#metrics

What does code coverage tell you and what does it not?

#coverage#quality