When we talk about observability, it’s easy to obsess over dashboards, monitors, or traces. But underneath all of that, one thing quietly determines your ability to understand systems: tags.
Tags (sometimes called labels or attributes) represent the context of telemetry data.
Many people think:
“Entities exist and they emit telemetry.”
But I prefer to flip it:
“Telemetry exists, and it has its context — including the emitting entity.”
Because telemetry becomes independent once it’s released from the emitting entity, each piece must carry its context.
That context lives in tags, which makes tagging the foundation of usable telemetry.
From my experience, effective tagging boils down to two categories of principles: one focused on quantity, and the other on quality.
Principle 1 (Quantity): Add as Much Context as Possible
Tags are the building blocks for asking meaningful questions of your telemetry data. The richer the context, the more powerful your analysis.
Even if you don’t know how you’ll use a tag today, you can’t add it retroactively to past telemetry once you realize it’s important.
With only one tag, such as:
service: checkout
you quickly run into limits. You can’t ask questions like
- "Which regions are failing?"
- "How many errors are happening in production?"
But with more tags, such as:
service: checkout
region: us-east-1
env: production
team: payments
you can answer those questions.
If you’re not sure what tags to start with, lean on reserved tags from your platform or industry-standard tags such as those defined in OpenTelemetry semantic conventions. In many cases, platforms handle these specially, offering richer analytics and visualizations.
These give you a ready-made foundation of context without guesswork.
Principle 2 (Quality): Keep Tags Canonical and Composable
Adding lots of tags is powerful — but only if they’re consistent and composable.
- Canonical: one authoritative way to represent each dimension.
- Composable: each tag represents one thing, so you can filter or group them independently.
Scenario A: Only a composed tag
service: auth-prod
Here you lose the ability to filter or group by environment.
If someone asks "How many errors in production?", you can’t answer this.
Scenario B: Mixed duplication
service: auth-prod
environment: prod
Now you’ve got two sources of truth for environment. The env:prod tag already represents the environment, so encoding it again inside service:auth-prod is unnecessary. Hardcoding multiple values to represent the same thing always leads to drift over time.
Being canonical also means unifying the values that point to the same dimension.
For example, you might see both of these in different parts of a system:
env: prod
env: production
Both names are acceptable on their own — but not when they coexist.
If you filter by env:prod, you’ll miss telemetry tagged with env:production, and vice versa.
Pick one naming convention and stick to it.
Defining tags this way keeps them simple, canonical, and composable.
service: auth
env: prod
Wrapping Up
Tags aren’t just metadata. They are the context carriers that make telemetry meaningful to your team — and to everyone else who relies on your data.
By keeping these two principles in mind:
- Quantity: Add as much context as possible (start with reserved/standard tags if unsure).
- Quality: Keep tags canonical and composable (one dimension per tag, consistent values).
This way, you’ll make your observability data more valuable, reliable, and future-proof.
Top comments (0)