Skip to main content
Hello, span explorers. In this lesson we’ll cover resources in spans and what “resources” mean in OpenTelemetry. Resources attach identity and context to telemetry so you can tell where a span, metric, or log originated. Why do we need resources? If you collect spans from every system in your organization, how do you distinguish spans coming from a service, a VM, a container, a pod, or an on‑prem host? Resources describe the entity producing telemetry so you can answer questions like “Which service generated this error?” or “Is this latency limited to the payments namespace?”
The image explains the need for resources to provide context to telemetry data, specifically addressing the problem of lacking metadata about data producers. It highlights the solution that resources offer in describing the entity producing the telemetry.

​
What is a Resource?

A Resource is a set of key/value attributes that identify the source of telemetry. Common resource attributes include service name, host/hostname, container name or ID, cloud provider, region, and deployment environment (prod/staging).
The image describes the concept of defining a resource as a collection of attributes that identify the source of telemetry data, with examples such as Service, Host, Container, Cloud, and Environment.

​
Why Resources Matter

Resources let you identify the producing entity for telemetry so you can ask operational questions such as:
  • Was this error coming from service B on AWS?
  • Is the latency isolated to the Kubernetes namespace payments?
  • Which team owns the service that emitted this span?
The image explains the importance of resources in tracing services, showing how different services (A, B, C) emit spans to a telemetry backend for monitoring and error tracing.
Examples of concrete resource attributes:
  • service.name = "payment-service"
  • pod.name = "payment-api"
  • cloud.provider = "aws"

​
Default Resource Attributes

OpenTelemetry SDKs provide default resource attributes you should know:
  • service.name (defaults to unknown_service if not set)
  • telemetry.sdk.name
  • telemetry.sdk.language
  • telemetry.sdk.version
The image is a table titled "Default Resource Attributes" showing various attribute keys, their example values, and their purposes. Each row lists attributes related to service name, SDK provider, language runtime, and SDK version.
Attribute KeyTypical ValuePurpose
service.namepayment-serviceIdentifies the service producing telemetry
telemetry.sdk.languagepythonRuntime/language of the SDK
telemetry.sdk.version1.0.0SDK version for debugging and compatibility
If you don’t set service.name, it will default to unknown_service. With many services emitting telemetry, this makes it hard to identify which trace belongs to which service—so it is a best practice to set service.name for every instrumented app.

​
Automatic Resource Detection

OpenTelemetry supports automatic resource detection via detectors. Detectors gather environment metadata and populate resource attributes without manual configuration. Typical detectors can collect:
  • OS type and description
  • Hostname and architecture
  • Process details
  • Container name/ID
  • Kubernetes pod and namespace
  • Cloud provider and region
The image is a table listing different types of resource detectors and their provided attributes, such as OS type, host name, and container ID, to aid in adding attributes for telemetry. It highlights the benefit of reducing configuration effort and standardizing telemetry across platforms.
Automatically-detected resource metadata reduces configuration effort and helps standardize telemetry across environments.

​
Benefits of Resource Attributes

Adding resource attributes makes it easier to:
  • Group and filter telemetry by service, pod, container, or host
  • Troubleshoot incidents by narrowing scope quickly
  • Correlate telemetry across services and environments
  • Support multi-cloud and multi-environment setups
The image explains why adding resource attributes is beneficial, highlighting that it makes it easier to group, filter, and troubleshoot, and features a logo for Jaeger, a commercial observability backend.

​
Custom Resource Attributes

You can add custom resource attributes for business or operational metadata, for example the team owning a service, application grouping, or feature flags. These attributes complement auto-detected attributes and improve searchability and access control in observability backends.
The image describes "Custom Resource Attributes" which add extra information about telemetry, including "Which service," "What environment," and "Which team."
To attach custom attributes in code, pass a Resource to the TracerProvider during initialization. The following Python example shows creating a custom resource and configuring a tracer provider so every span includes those attributes:
The image illustrates adding resource attributes via code, including metadata such as service.name, team, and deployment.environment. Each attribute is associated with a description and example value.

​
Configure Resources via Environment Variables

In many deployments, especially with automatic instrumentation, configuring resources using environment variables is easier because it requires no code changes and works across CI/CD and orchestration tooling. Example (bash):
Using environment variables enforces consistent resource attributes across deployments and allows updates from CI/CD pipelines or orchestration tools.
The image describes four use cases for adding resource attributes related to telemetry: CI/CD pipeline integration, filtering and grouping, tracing across services, and supporting multi-cloud or multi-environment setups.

​
Common Use Cases

  • Configure attributes from CI/CD or infrastructure without modifying code.
  • Filter and group telemetry in the backend (for example, show only traces from production).
  • Facilitate cross-service tracing by consistently tagging spans.
  • Support multi-cloud or multi-environment setups by tagging cloud.provider or region.

​
Summary

  • A Resource in OpenTelemetry defines the origin of telemetry data (service, host, container, environment).
  • Configure the resource once during SDK initialization; it is automatically applied to all spans, metrics, and logs produced by that SDK instance.
  • Default attributes include service.name (defaults to unknown_service), telemetry.sdk.name, telemetry.sdk.language, and telemetry.sdk.version.
  • Resource detectors can automatically collect metadata (host, process, container, Kubernetes, cloud provider).
  • You can add additional attributes manually via Resource.create(...) in code or via the OTEL_RESOURCE_ATTRIBUTES environment variable.
  • Follow semantic conventions for attribute names to ensure consistency across telemetry.
The image is a summary of OpenTelemetry resource configuration, highlighting key points about defining telemetry data origins, SDK initialization, default attributes, and resource detectors.
For consistent and searchable telemetry, set service.name and other domain-specific attributes using OpenTelemetry semantic conventions. Prefer environment variables for deployment-wide defaults and let resource detectors populate infrastructure-level attributes automatically.
Links and references That’s it for this section.

Watch Video