Why Resource Equality?

The same application or infrastructure component often emits telemetry from multiple sources—an OpenTelemetry SDK inside a container, a log agent on the host, a metrics exporter, such as kube-state-metrics. Each source describes the same observed system, but with different sets of resource attributes.

The Dash0 Intervention

Without intervention, an observability backend treats each unique signal as a separate resource. The result is resource fragmentation: your pod's spans appear on one resource, its logs on another, and its metrics on a third. You lose the unified view you need to troubleshoot effectively.

Resource equality is Dash0's solution to this problem. It's an expanding set of rules that Dash0 applies at ingestion time to determine when different signals describe the same observed system, so their telemetry can be correlated automatically.

Common Fragmentation Scenarios

This section walks through common scenarios where fragmentation occurs and how Dash0's resource equality rules handle them automatically.

Amazon EKS Pod Logs

When using Fluent Bit or Fluentd to collect Amazon EKS pod logs, the log agent accesses the host's /var/log/pods/<namespace>_<pod_name>_<pod_id>/<container_name>/Copy path. Without special configuration, it can only set:

• k8s.namespace.nameCopy
• k8s.pod.nameCopy
• k8s.pod.uidCopy
• container.nameCopy

Meanwhile, the OpenTelemetry SDK inside the same pod reports a much richer set of attributes: service name, deployment metadata, node information, and more. Despite describing the same pod, these two signals would produce two separate resources without resource equality.

Amazon ECS Tasks + CloudWatch Logs

ECS workloads can send logs to CloudWatch using the awslogs driver. The AWS Logs semantic conventions define aws.log.{group|stream}.{arns|names}Copy resource attributes, which can be retrieved from Amazon ECS metadata endpoints.

However, logs fetched from CloudWatch have no metadata about what generated them. Without explicit mapping, there's no way to correlate CloudWatch logs with ECS task telemetry from an embedded SDK.

Vercel Spans and Logs

Vercel spans (via the @vercel/otelCopy package) include detailed resource attributes:

123456789101112131415161718192021
{
  "service": {
    "name": "my-app",
    "namespace": "my-app"
  },
  "cloud": {
    "provider": "Vercel",
    "platform": "Vercel Functions",
    "region": "iad1"
  },
  "vercel": {
    "environment": "production",
    "url": "my-app.vercel.app",
    "deployment_id": "dpl_abc123",
    "project_id": "prj_xyz789"
  },
  "faas": {
    "name": "function-identifier",
    "version": "$LATEST"
  }
}

Vercel log drains provide a different, sparser set of metadata. Without correlation, spans and logs from the same Vercel deployment appear as separate resources.

Kubernetes Pod with Service Mesh Sidecar

Kubernetes pods running service mesh solutions, such as Istio or Linkerd, have multiple containers, each potentially reporting different resource attributes:

• Main application container: Sets service.name=my-apiCopy, container.name=appCopy, process.runtime.name=pythonCopy, telemetry.sdk.name=opentelemetryCopy
• Envoy sidecar proxy: Sets service.name=envoyCopy, container.name=istio-proxyCopy, process.runtime.name=c++Copy
• Log collector sidecar: May only report basic Kubernetes metadata

Without resource equality, telemetry from these three containers would appear as three separate resources, making it difficult to get a unified view of pod health.

AWS Lambda with CloudWatch Logs

AWS Lambda functions often send logs to CloudWatch using the default runtime logging. Meanwhile, an embedded OpenTelemetry SDK instruments the function to send traces and metrics. These two signals report very different attributes:

• OTel SDK: Sets faas.name=order-processorCopy, faas.instance=invocation-123Copy, service.name=order-serviceCopy, cloud.region=us-east-1Copy, telemetry.sdk.*Copy
• CloudWatch logs: May only include aws.log.group.names=/aws/lambda/order-processorCopy, aws.log.stream.names=2026/04/27/[$LATEST]abcCopy, with limited resource context

Without explicit correlation, there's no automatic way to connect CloudWatch logs with SDK-reported traces and metrics.

Multi-Container Pod with kube-state-metrics

Kubernetes deployments often use kube-state-metrics to expose cluster-level metrics about workload state. These metrics describe resources at the pod or deployment level but contain different attributes than the telemetry from applications running inside those pods:

• Application in pod: Sets full resource attributes including service.nameCopy, k8s.pod.uidCopy, k8s.deployment.nameCopy, container.nameCopy
• kube-state-metrics: Reports aggregate metrics with k8s.deployment.nameCopy, k8s.namespace.nameCopy, but missing k8s.pod.uidCopy since it describes the deployment, not individual pods

This creates a challenge: how do you correlate deployment-level metrics with pod-level application telemetry?

Kubernetes Enrichment

Many deployments use the OpenTelemetry Collector with the k8sattributes processor to enrich telemetry with Kubernetes metadata. This can lead to fragmentation when some telemetry passes through the collector while other telemetry doesn't:

• Via collector: Application sends spans with minimal attributes (service.name=apiCopy), collector enriches with k8s.pod.uidCopy, k8s.namespace.nameCopy, k8s.deployment.nameCopy, k8s.node.nameCopy
• Direct to backend: Host agent sends logs directly with only k8s.pod.uidCopy, k8s.pod.nameCopy, container.nameCopy

The two paths produce signals with different attributes for the same observed system.

Further Reading

For complete resource equality rules and reference material, explore the following resources.

Related Topics in This Section

• About Resources: Overview of resources in Dash0
• Explore Resources: Get started exploring resources in Dash0
• References: Complete reference for equality, naming, and typing rules across all supported platforms

Dash0 Guides & Knowledge

• What are OpenTelemetry Resources?: Deep dive into how resources describe which system is generating telemetry data
• Service Attributes Best Practices: Learn what resource attributes are and how they can be categorized
• Kubernetes Attributes Best Practices: Best practices for Kubernetes resource attributes

OpenTelemetry Resources

• Resource Semantic Conventions: Official specification for resource attributes
• OpenTelemetry Collector: Learn about the OpenTelemetry Collector and processors
• K8sAttributes Processor: Enrich telemetry with Kubernetes metadata