The Identity Card
In OpenTelemetry, telemetry is split into two distinct parts: the signal data itself (Spans, Metrics, Logs) and the Resource — a description of the entity producing that data.
Think of the Resource as the identity card stapled to every piece of telemetry your application emits. It answers the question: "Who sent this?" Resource attributes don't change per request; they are set once when the SDK initializes and remain constant for the life of the process.
The core Resource attributes every service must set:
| Attribute | Example Value | Why It Matters |
|---|---|---|
service.name |
payment-gateway |
The logical name of the service |
service.version |
v1.2.0 or sha-a1b2c3d |
Correlates errors to a specific deploy |
deployment.environment |
production, staging |
Prevents mixing prod and test data |
service.instance.id |
pod-abc-123 |
Distinguishes individual replicas |
In code (Python SDK): a Resource is created once at startup from a dict of typed attribute constants — ResourceAttributes.SERVICE_NAME, SERVICE_VERSION, and DEPLOYMENT_ENVIRONMENT — rather than raw dictionary keys.
Notice the use of ResourceAttributes.SERVICE_NAME — a typed constant from the opentelemetry-semantic-conventions package — rather than the raw string "service.name". This protects you from typos and gives you IDE autocomplete.
Infrastructure attributes are typically auto-detected by Resource Detectors (libraries that inspect the environment at startup):
host.name: The hostname of the machine.k8s.pod.name,k8s.namespace.name: Kubernetes identity.cloud.provider,cloud.region: AWS, GCP, Azure metadata.
If you standardize the four core attributes across every application in your organization, you solve 90% of cross-signal correlation problems immediately.
Interviewers often ask: "What's the difference between a Resource attribute and a Span attribute?" The answer: Resource attributes describe the producer (the service itself — static, set once at startup). Span attributes describe the operation (a specific request or event — dynamic, set per operation). Mixing these up leads to high-cardinality Resource attributes, which can cause performance problems in some backends.