Last updated: May 7, 2026
Overview
Dash0 uses resource equality rules to identify and name resources based on OpenTelemetry semantic conventions.
Each platform has resource equality rules that determine when telemetry from different sources describes the same observed system, and resource naming rules that assign human-readable names and types.
This page provides an overview of resource equality concepts and links to platform-specific references. For practical examples of resource fragmentation, see Why Resource Equality?.
How Resource Equality Works
Dash0 applies a hierarchical set of rules to determine when different telemetry sources describe the same observed system, and assigns names and types to make resources identifiable in the UI.
Dash0 uses three types of rules for processing resources:
- Equality Rules: Determine when different telemetry sources describe the same observed system
- Naming Rules: Assign human-readable names to resources
- Typing Rules: Classify resources by type
All rules are based on OpenTelemetry semantic conventions, ensuring compatibility with standard instrumentation libraries and collectors.
Equality Rules
Equality rules use a hierarchy evaluated in order of precedence to identify when different signals describe the same observed system:
- Browser and mobile application detection: Evaluated FIRST before any other rules (client-side telemetry is immediately classified)
- Technology-specific rules: Match resources using platform-specific attributes (Kubernetes, AWS, GCP, etc.)
- Identity fallback: As a last resort, exact match (same keys, same typed values)
When two resources are matched by any equality rule, Dash0 assigns them the same resource identifier. The system adds three special attributes:
dash0.resource.id: The unique identifier computed from the matching equality ruledash0.resource.name: Human-readable name derived using naming rulesdash0.resource.type: Resource type classification derived using typing rulesdash0.resource.hash: The the stable hash of the resource attributes for the particular log, metric or span; this attribute is seldom useful for end users, but is needed as an internal mechanic in Dash0
The dash0.resource.id, dash0.resource.name, dash0.resource.type and dash0.resource.hash resource attributes are assigned automatically by Dash0 when ingesting your telemetry.
There you pay no surcharges due to this additional metadata.
Technology-specific rules identify resources using standardized OpenTelemetry attributes for each platform. Rules are evaluated in descending order of precedence: the first matching rule determines the resource identity (dash0.resource.id).
When multiple resource dictionaries share the same value for dash0.resource.id, their attributes are stored separately in the backend and can be queried by any attribute value present across all matched resources. For details, see Storage & Query Behavior.
Dash0 supports resource equality rules for the platforms listed in the Supported Platforms section below. For detailed rules for each platform, see the platform reference pages.
Identity Fallback
As a fallback, resources with exactly matching attributes are considered identical.
Two resources are identical if they have equivalent sets of attribute keys (case-sensitive, order-insensitive) and, for each attribute key, the associated values are the same.
Rule Precedence
Higher-precedence rules take priority when multiple rules could match the same resource.
Rules are evaluated in this order (highest to lowest priority):
- User-Defined Override: If
dash0.resource.nameordash0.resource.typeare already set, they take precedence (see Resource Attributes) - Browser and Mobile Apps: Web and native mobile applications (evaluated FIRST before all other rules)
- Kubernetes Workloads: Pods identified by
k8s.pod.uid - Kubernetes Resources: Deployments, daemonsets, replicasets, statefulsets, cronjobs, jobs, namespaces
- AWS Services: Lambda, ECS, SQS, SNS, API Gateway
- GCP Services: Cloud Run, Pub/Sub, Cloud Storage
- Containers: Container ID (non-Kubernetes)
- Host ID: Host ID only (
host.id) - Heroku: App and dyno
- CI/CD: Pipeline runs
- Vercel: Serverless functions
- Service Fallback: Service triplet
- Container Name: Container name (very low priority)
- Kubernetes Nodes: Nodes (only when workload attributes absent)
- Kubernetes Clusters: Clusters
- Cloud Account: Cloud account fallback
- Host Name: Host name only (
host.name, lowest priority)
Browser and mobile application detection happens FIRST to ensure client-side telemetry is always classified correctly. host.name has the lowest precedence because hostnames are often misconfigured in containerized environments, e.g., pod names are often reported as host.name, although they are not hosts. For stable host identification, set both host.id (used for equality) and host.name (used for naming).
Naming Rules
Naming rules assign human-readable names to resources based on resource attributes. These names appear throughout the Dash0 UI: in the Resource Explorer, in span detail panels, in the Log explorer, alert notifications, and more.
Naming rules follow the same precedence order as equality rules. Each equality rule has a corresponding naming rule that uses a subset of the same attribute keys, preferring human-readable values (e.g., k8s.pod.name) over UIDs, falling back to UIDs when names aren't available.
A resource with k8s.pod.name=api-server-xyz automatically receives dash0.resource.name=api-server-xyz.
See the Supported Platforms section for an overview of the rules.
Typing Rules
Typing rules classify resources by type using resource attributes. Resource types enable filtering and visualization by resource category in the Dash0 UI (e.g., k8s.pod, aws.lambda, gcp.cloud.run, host, container).
Typing rules follow the same precedence order as equality and naming rules. Each equality rule has a corresponding typing rule that assigns a resource type based on the presence of specific attributes.
A resource with k8s.pod.name or k8s.pod.uid set automatically receives dash0.resource.type=k8s.pod. You can override this by explicitly setting the dash0.resource.type attribute in your OpenTelemetry SDK configuration.
Supported resource types:
- Kubernetes:
k8s.pod,k8s.deployment,k8s.daemonset,k8s.statefulset,k8s.replicaset,k8s.job,k8s.cronjob,k8s.namespace,k8s.node,k8s.cluster - AWS:
aws.lambda,aws.ecs.task,aws.sqs,aws.sns,aws.apigateway,aws.log.group - GCP:
gcp.cloud.run,gcp.cloud.storage,gcp.pubsub - Other:
container,host,heroku.dyno,vercel.project,workflow,browser(includes mobile apps),cloud.account
For complete typing rules for each platform, see the platform reference pages listed in the Supported Platforms section below.
Supported Platforms
Dash0 provides equality, naming and typing rules for major cloud providers, orchestration platforms, and application environments.
| Platform | Description |
|---|---|
| Kubernetes | Workloads, pods, deployments, nodes, and clusters running in Kubernetes |
| AWS | Lambda functions, ECS tasks, SQS queues, SNS topics, API Gateway, and additional services with naming support |
| GCP | Cloud Run services, Pub/Sub topics, and Cloud Storage buckets |
| Containers and Hosts | Docker containers and host systems outside of Kubernetes |
| Other Platforms | Heroku dynos, Vercel functions, CI/CD pipelines, browser and mobile applications, cloud accounts, and service-based fallback |
Azure is not currently supported with platform-specific resource equality rules. Set the cloud.resource_id resource attribute to control the granularity of your resources in Azure or other clouds for which Dash0 has currently no bespoke rules.
Best Practices
- Use resource detectors in OpenTelemetry SDKs to automatically populate platform-specific attributes
- Leverage platform-specific processors, such as K8sAttributes in the OpenTelemetry Collector
- Set consistent attributes across all telemetry sources for the same observed system
- Set both
host.idandhost.namefor stable host identification—host.idis used for equality matching whilehost.nameis used preferentially for naming - Override with
dash0.resource.nameordash0.resource.typewhen the computed values aren't suitable for your use case - Monitor
dash0.resource.typeto ensure resources are being classified correctly
Further Reading
For related concepts and implementation details, explore the following resources.
Related Topics in This Section
- About Resources: Overview of resources in Dash0
- Explore Resources: Get started exploring resources in Dash0
- Why Resource Equality?: Practical examples of resource fragmentation scenarios
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 SDKs: Language-specific SDK documentation
- OpenTelemetry Collector: Learn about the OpenTelemetry Collector and processors
- k8sattributesprocessor: Enrich telemetry with Kubernetes metadata