Dash0 Raises $110M Series B at $1B Valuation

Last updated: May 7, 2026

Overview

Complete reference guide for resource equality, naming, and typing rules across all supported platforms.

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.

Note

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:

  1. Equality Rules: Determine when different telemetry sources describe the same observed system
  2. Naming Rules: Assign human-readable names to resources
  3. 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:

  1. Browser and mobile application detection: Evaluated FIRST before any other rules (client-side telemetry is immediately classified)
  2. Technology-specific rules: Match resources using platform-specific attributes (Kubernetes, AWS, GCP, etc.)
  3. 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 rule
  • dash0.resource.name: Human-readable name derived using naming rules
  • dash0.resource.type: Resource type classification derived using typing rules
  • dash0.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).

Note

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):

  1. User-Defined Override: If dash0.resource.name or dash0.resource.type are already set, they take precedence (see Resource Attributes)
  2. Browser and Mobile Apps: Web and native mobile applications (evaluated FIRST before all other rules)
  3. Kubernetes Workloads: Pods identified by k8s.pod.uid
  4. Kubernetes Resources: Deployments, daemonsets, replicasets, statefulsets, cronjobs, jobs, namespaces
  5. AWS Services: Lambda, ECS, SQS, SNS, API Gateway
  6. GCP Services: Cloud Run, Pub/Sub, Cloud Storage
  7. Containers: Container ID (non-Kubernetes)
  8. Host ID: Host ID only (host.id)
  9. Heroku: App and dyno
  10. CI/CD: Pipeline runs
  11. Vercel: Serverless functions
  12. Service Fallback: Service triplet
  13. Container Name: Container name (very low priority)
  14. Kubernetes Nodes: Nodes (only when workload attributes absent)
  15. Kubernetes Clusters: Clusters
  16. Cloud Account: Cloud account fallback
  17. Host Name: Host name only (host.name, lowest priority)
Note

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.

Example

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.

Note

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.

PlatformDescription
KubernetesWorkloads, pods, deployments, nodes, and clusters running in Kubernetes
AWSLambda functions, ECS tasks, SQS queues, SNS topics, API Gateway, and additional services with naming support
GCPCloud Run services, Pub/Sub topics, and Cloud Storage buckets
Containers and HostsDocker containers and host systems outside of Kubernetes
Other PlatformsHeroku dynos, Vercel functions, CI/CD pipelines, browser and mobile applications, cloud accounts, and service-based fallback
Note

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.id and host.name for stable host identification—host.id is used for equality matching while host.name is used preferentially for naming
  • Override with dash0.resource.name or dash0.resource.type when the computed values aren't suitable for your use case
  • Monitor dash0.resource.type to ensure resources are being classified correctly

Further Reading

For related concepts and implementation details, explore the following resources.

Dash0 Guides & Knowledge

OpenTelemetry Resources