Linking the Three Pillars of Observability
Logs, metrics, and traces are only useful in isolation. Their real power emerges when you can navigate between them — clicking a spike on a latency graph and immediately seeing the traces and logs from that exact moment, for that exact service version.
This capability is called Unified Observability, and it requires one prerequisite: the same three tags must be present on every signal your system emits.
The Golden Trio:
service.name— Groups all signals (logs, metrics, traces) under a single application entity. Without this, you cannot answer "show me everything from the checkout service."service.version— Correlates a spike in errors with a specific deployment or code change. Without this, you know what broke but not when it was introduced.deployment.environment— Prevents production data from being contaminated by staging or canary deployments. Without this, a load test in staging can trigger production alerts.
The practical test: Open any dashboard panel in your organization. Can you filter it by all three of these variables? If not, that panel is incomplete. During an incident, you will waste time manually excluding irrelevant environments or versions.
Correlation in practice: Modern backends use these tags to build automatic links. For example, when service.name=checkout and service.version=v1.2.0 appear on both a metric and a trace, the backend can render a "View Traces" button directly on the metric graph. This only works if the tags match exactly — checkout and Checkout are different values.