Dash0 receives profiles through OTLP. Use a profiler that exports OpenTelemetry profiles, or convert existing profiling data before forwarding it.

The available profile types depend on the profiler and runtime. A collection setup that produces On-CPU profiles does not automatically collect heap, allocation, or off-CPU profiles. See Profile type and units.

Before you begin

Identify your organization's OTLP endpoint and the destination dataset. Configure the exporter with an auth token that permits profile ingestion into that dataset. Check both its signal types and permissions.

OpenTelemetry Profiles is an alpha signal. Use compatible profiler and Collector releases, and follow the configuration instructions for the versions you deploy.

Host-wide eBPF profilers need privileged access to the nodes they profile. See Profiling Security before you deploy one.

Collect with the Parca Agent

We recommend the Parca Agent. It is the most complete eBPF profiler for Dash0. It profiles processes across a Linux host without code changes, supports opt-in off-CPU profiling, and uploads the debuginfo that Dash0 needs to symbolize compiled code.

On Kubernetes, let the Dash0 operator deploy and configure the agent. Set the operator.ebpfProfilerEnabled Helm value to true. The operator then runs the agent as a DaemonSet, sends its profiles through the operator's Collector, and uploads debuginfo to every Dash0 export in the operator configuration. See the operator's managed eBPF profiler guide for the requirements and settings, including the off-CPU threshold.

The managed agent is not currently supported on GKE Autopilot.

Collect with the OpenTelemetry eBPF Profiler

The OpenTelemetry eBPF Profiler also collects call stacks across supported processes and runtimes on Linux hosts. It runs as the profiling receiver in the OpenTelemetry Collector eBPF Profiler distribution. It does not upload debuginfo to Dash0, so compiled code without debuginfo can appear unsymbolized.

Deploy a supported release of the profiler distribution on the hosts you want to profile. Check that release's kernel, privilege, and host-access requirements. Do not use a locally built development binary for production.
Configure the profiling receiver in a profiles pipeline with an OTLP exporter. Follow the project's Collector configuration example and its instructions for enabling profile support in your Collector version.
Point the exporter at Dash0, or at a Collector that forwards profiles to Dash0. Apply the destination's authentication and TLS settings. The upstream local example uses an insecure local endpoint, not a Dash0 ingestion endpoint.

On Kubernetes, the operator's guide shows how to send its profiles to the operator's Collector.

Collect with a runtime profiler

A runtime-specific profiler can export OpenTelemetry profiles without a host-wide eBPF agent. For Java, async-profiler supports OTLP output, including export to an OTLP-compatible HTTP endpoint.

Use a release that supports the required OTLP profile format. Its OTLP output is experimental and may change incompatibly. Check the profiler's supported events and export options rather than assuming every profiling mode produces the same data.

If the profiler cannot supply the authentication or dataset configuration required by Dash0, send profiles to a Collector's OTLP receiver and configure that Collector to export them to Dash0.

An existing OpenTelemetry tracing or metrics agent does not necessarily collect profiles. Check its documentation for explicit profile collection and export support.

Scrape pprof endpoints with Parca

To collect profiles from applications that expose pprof endpoints, such as Go's net/http/pprof, run Parca in its OTLP forwarder mode. Parca discovers scrape targets dynamically, Prometheus-style, converts the scraped profiles to OpenTelemetry profiles, and sends them to a Collector. It does not need privileged access or a Parca database.

The Parca pprof scraping integration shows a Kubernetes setup that forwards profiles through the Dash0 operator's Collector, and lists pprof options for other runtimes.

Import pprof profiles with the Collector

The OpenTelemetry Collector Contrib pprof receiver converts pprof data into OpenTelemetry profiles. Its remote mode polls a single configured endpoint and cannot discover targets, so use Parca to scrape a fleet of applications. The receiver suits these sources:

File: Read pprof files matching a configured path pattern.
Server: Accept pushed pprof payloads over HTTP.
Remote: Poll one application's HTTP profiling endpoint.
Self: Profile the running Collector itself.

Configure the pprof receiver in a profiles pipeline, then configure an OTLP exporter to send the converted profiles to Dash0 or a forwarding Collector. To forward them through the Dash0 operator, send the converted OTLP profiles to the operator's Collector. Do not send raw pprof payloads to an OTLP endpoint.

The receiver's profile support is alpha. Check that your Collector build includes the receiver and that its release supports the collection mode you need.

Do not confuse the receiver with the pprof extension. The extension exposes debugging profiles of the Collector. It does not ingest application profiles.

Import JFR recordings

The async-profiler JFR converter can convert JFR recordings into pprof or OTLP profiles. Choose the event type to convert, such as CPU, allocation, or lock events, so the output represents one measurement.

For the pprof path, pass the converted files to the pprof receiver's file mode and forward its OTLP output. Converting a recording does not send it to Dash0, and a raw JFR file is not an OTLP payload.

Use the Dash0 operator on Kubernetes

The Dash0 operator profiling guide explains how to enable the operator's profiles pipeline. Enabling profile forwarding alone does not deploy a profiler. Collect profiles with the operator-managed Parca Agent, or forward them from a separately deployed profiler, such as the OpenTelemetry eBPF Profiler or Parca pprof scraping.

Check that profiles arrive

Open Profiling under Telemetry. Select the destination dataset, a time range that includes collection, and a Profile type emitted by your profiler. See Explore Profiles for the explorer controls.

If no profiles appear, check that the source produces profiles and that each Collector in the forwarding path has a profiles pipeline. Inspect the Collector logs for export failures, then check the endpoint, token, and dataset configuration.

If frames show memory addresses instead of function names, see Symbolize Profiles.

Collect and Send Profiles