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

Last updated: May 7, 2026

Resource Fragmentation

When observability data for a single system is split across multiple resources due to inconsistent attributes across telemetry sources.

Resource fragmentation occurs when different telemetry sources describing the same logical infrastructure component produce different resource attributes, causing an observability backend to treat them as separate resources. This splits your observability data across multiple resource views, preventing you from getting a unified picture of system health.

Why Fragmentation Happens

Different telemetry sources rarely report identical resource attributes, even when they describe the same component.

For example, a Kubernetes pod might emit telemetry from multiple sources:

  • OpenTelemetry SDK inside the pod: Reports service.name, k8s.pod.uid, k8s.deployment.name, k8s.namespace.name, and rich deployment metadata
  • Log agent on the host: Only accesses basic pod information like k8s.pod.uid, k8s.pod.name, and container.name
  • Metrics exporter (e.g., kube-state-metrics): Reports cluster-level metrics with k8s.deployment.name and k8s.namespace.name but missing k8s.pod.uid

Without intervention, an observability backend treats each unique attribute dictionary as a separate resource. The result is that 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.

How Dash0 Solves Resource Fragmentation

Dash0 automatically merges fragmented resources using resource equality—a Dash0-specific mechanism that identifies when different signals describe the same observed system.

How it works:

  • Platform-specific matching: Dash0 applies 30+ equality rules based on OpenTelemetry semantic conventions, using attributes like k8s.pod.uid for Kubernetes or faas.instance for AWS Lambda to identify the same resource across different telemetry sources
  • Automatic correlation: When multiple resource dictionaries share the same identifier (e.g., the same pod UID), Dash0 assigns them the same dash0.resource.id, allowing you to query and view their telemetry together
  • No configuration required: Resource equality works automatically without modifying your instrumentation or adding configuration

Example: A Kubernetes pod with telemetry from an OpenTelemetry SDK, a log agent, and kube-state-metrics would normally appear as three separate resources. Dash0's equality rules detect that all three share the same k8s.pod.uid and merge them into a unified view where you can see spans, logs, and metrics together.

Impact on Monitoring and Troubleshooting

Resource fragmentation creates several challenges that Dash0's resource equality solves:

  • Split RED metrics: When spans and metrics come from different sources with different attributes, calculating accurate RED metrics (Rate, Errors, Duration) for a service becomes difficult or impossible
  • Lost correlation: You can't correlate spans with their logs, or metrics with their traces, making root cause analysis harder
  • Duplicate dashboards: You need separate dashboards and queries for different telemetry types instead of a single unified view
  • Query complexity: Finding all telemetry for a specific component requires multiple queries with different filter criteria

By automatically merging fragmented resources, Dash0 gives you a complete picture of each system component, enabling faster troubleshooting and more accurate monitoring.

Further Reading

For detailed information on how Dash0's resource equality works: