A resource represents the entity producing telemetry as resource attributes. For example, a process producing telemetry that is running in a container on Kubernetes has a process name, a pod name, a namespace, and possibly a deployment name. All four of these attributes can be included in the resource.
In your observability backend, you can use resource information to better investigate interesting behavior. For example, if your trace or metrics data indicate latency in your system, you can narrow it down to a specific container, pod, or Kubernetes deployment.
If you use Jaeger as your observability backend, resource attributes are grouped under the Process tab:
A resource is added to the
MetricProvider when they are
created during initialization. This association can not be changed later. After
a resource is added, all spans and metrics produced from a
from the provider will have the resource associated with them.
Semantic Attributes with SDK-provided Default Value
There are attributes provided by the OpenTelemetry SDK. One of them is the
service.name, which represents the logical name of the service. By default,
SDKs will assign the value
unknown_service for this value, so it is
recommended to set it explicitly, either in code or via setting the environment
Additionally, the SDK will also provides the following resource attributes to
Most language-specific SDKs provide a set of resource detectors that can be used to automatically detect resource information from the environment. Common resource detectors include:
- Operating System
- Process and Process Runtime
- Cloud-Provider-Specific Attributes
- and more
You can also provide your own resource attributes. You can either provide them
in code or via populating the environment variable
If applicable, use the
semantic conventions for your resource attributes.
For example, you can provide the name of your
env OTEL_RESOURCE_ATTRIBUTES=deployment.environment=production yourApp