Dash0 Raises $110M Series B at $1B Valuation
Profile every process on your Kubernetes nodes with the OpenTelemetry eBPF profiler. No code changes required.
Profiling is the fourth observability signal. Logs tell you what happened. Metrics tell you how much and how often. Traces tell you which path a request took. Profiles tell you which lines of code consumed the time.
Dash0 continuous profiling is powered by the OpenTelemetry eBPF Profiler. It runs as a DaemonSet on each Kubernetes node, samples call stacks from every running process using Linux's eBPF mechanism, and sends profiles to Dash0 through your OpenTelemetry Collector. No changes to your application code or container images are required.
Because it operates at the kernel level, a single profiler pod covers all languages simultaneously: Go, Java, Python, Node.js, PHP, Perl, and Erlang/Elixir (BEAM).
sendto, recvfrom, futex, epoll) relative to your application code.Continuous profiling requires two components in your Kubernetes cluster:
The profiler sends only container.id as the resource identifier. The collector resolves it to service name and full Kubernetes metadata using the k8sattributes/profiling processor.
The profiler requires privileged access to the host. It mounts /proc, /sys/kernel/debug, and /sys/fs/cgroup read-only, and runs with hostPID: true.
The eBPF profiler is a purpose-built OpenTelemetry Collector distribution that embeds the profiling receiver. Deploy it as a DaemonSet so one pod runs on each node.
The profiler's collector config defines the profiling receiver and the OTLP exporter. The endpoint depends on which collector you use.
If you use the Dash0 Operator:
If you use a standalone OpenTelemetry Collector:
Replace <your-collector-namespace> with the namespace where your OpenTelemetry Collector is running (e.g., opentelemetry).
To visualize this configuration:
The current stable release is 0.154.0. Check the releases page for newer versions.
The collector receiving profiles from the eBPF profiler must have the service.profilesSupport feature gate enabled and a profiles pipeline configured. The steps differ depending on which collector you use.
Add the following to your Dash0 Operator Helm values:
This enables the service.profilesSupport feature gate and adds the profiles pipeline to the Operator's collector automatically.
This step extends your existing collector configuration. The otlp/dash0 exporter referenced in the pipeline is the
one you configured when setting up the
OpenTelemetry Collector. If you haven't
set up the collector yet, do that first.
Add the following to your collector's daemonset-values.yaml:
Apply the update:
If you deployed the collector as a raw manifest, add --feature-gates=service.profilesSupport to the collector container's args, then add the k8sattributes/profiling processor and profiles pipeline to the collector's config as shown above.
Confirm the profiler pods are running:
Check the profiler logs for OTLP export errors:
Navigate to Telemetry > Profiling in Dash0. Services with profiling data will appear within a few minutes.
If no data appears:
--feature-gates=service.profilesSupport is set in both the eBPF profiler args and the collector argsprofiles pipeline is present in the collector's service.pipelines