Your dashboards can tell you a service is burning through CPU. Your traces can tell you a request took 900 milliseconds when it should've taken 90. What neither can tell you is which functions are consuming those CPU cycles. That gap has always been where profiling lives, and it's why we brought Polar Signals into Dash0 back in August.
Today, continuous profiling is generally available in Dash0, bringing code-level performance visibility alongside your logs, metrics, and traces. Powered by eBPF and built on OpenTelemetry Profiling signals, it lets you investigate CPU consumption across your Kubernetes workloads without changing application code or deploying language-specific profilers.
Seeing what your applications actually execute
Traces and logs reflect decisions about what to capture through instrumentation and logging configuration. If nobody instrumented a hot loop, it won't appear as a separate operation in your traces.
Profiling provides a fundamentally different capability. Using eBPF, Dash0 periodically samples the code running on each CPU across a host, capturing execution paths without requiring application changes, language-specific SDKs, or service restarts. Over time, these samples reveal where CPU time is actually spent, including in functions that were never explicitly instrumented.
By collecting samples at the Linux kernel level rather than relying on application-specific instrumentation, Dash0 Profiling offers three important advantages:
-
Low production overhead: Always-on continuous profiling is designed to consume less than 10 millicores of CPU (1% of a CPU core), with approximately 100–500 MB of memory per node depending on active processes and workload characteristics.
-
Broad language and kernel coverage: A single eBPF agent per node supports Go, Rust, C, C++, Java, Node.js, Python, Ruby, PHP, and LuaJIT, with visibility into native libraries and Linux kernel functions.
-
On-CPU and off-CPU visibility: Identify functions consuming CPU time and, with off-CPU profiling enabled, investigate where threads spend time blocked on locks, I/O, or other system activity.
These capabilities make profiling valuable for both cost optimization and application performance. Teams can identify the functions responsible for excessive compute consumption and optimize them to reduce infrastructure costs.
For performance-sensitive systems such as databases, trading platforms, and high-traffic services, even modest improvements in CPU efficiency can translate into meaningful gains in throughput and responsiveness.
OpenTelemetry-native profiling, powered by Parca
Dash0 Profiling combines the continuous profiling technology developed by Polar Signals through Parca with our OpenTelemetry-native architecture.
Profiles are ingested through OTLP, whether collected by the Dash0 Kubernetes Operator or supported external profilers through the OpenTelemetry Collector. This keeps profiling interoperable with the broader OpenTelemetry ecosystem without locking you into a proprietary data format.
Parca also adds advanced symbolization, broad runtime support, and the ability to resolve function names and source locations without bundling debug information into production binaries.
What ships at GA
| Capability | What ships | Why it matters |
|---|---|---|
| Native OTLP & pprof ingestion | Collect eBPF profiles through the Dash0 Operator or ingest supported profiling data through OTLP and the OpenTelemetry Collector. | Bring profiling into your existing observability workflow without depending on a proprietary format. |
| Memory profiling | Ingest and analyze supported heap and allocation profiles from runtime-specific profilers. | Identify allocation-heavy code paths, investigate memory retention, and uncover opportunities to reduce memory consumption. |
| Query-time symbolization | Resolve sampled addresses into function names and source locations using build IDs and available debug information. | Investigate optimized, stripped production binaries without bundling debug information into deployments. |
| Flame graphs and sandwich view | Explore CPU profiles through flame graphs, self/total time breakdowns, and aggregated caller/callee views. | Find expensive code paths, including frequently called functions scattered throughout a profile. |
| Filtering and runtime frame hiding | Narrow profiles by Kubernetes workload, node, or process, and hide selected runtime frames. | Focus on the application code relevant to an investigation. |
| Agent0 and MCP integration | Make profiling data available to Agent0 and connected coding agents. | Investigate CPU bottlenecks and guide optimization efforts with production evidence. |
Turning it on
Profiling is integrated into the Dash0 Kubernetes Operator and is disabled by default, so nothing changes in your clusters until you explicitly enable it.
Once enabled, the Operator deploys an eBPF profiler that automatically collects execution samples from supported workloads across your nodes. Profiles are enriched with Kubernetes metadata, including Pod labels and annotations, so you can investigate CPU consumption by workload, namespace, or node.
Because the profiler needs host-level access, deployment requires elevated privileges. The documentation covers the necessary configuration and security requirements.
From flame graphs to actionable insights
Flame graphs are the starting point for exploring profiles in Dash0. Each frame represents a function in a sampled call stack, with its width showing the proportion of CPU time attributed to that function and its callees. You can examine total time, which includes time spent in called functions, or self time, which isolates the work performed by the function itself.
When an expensive function appears across many call paths, the sandwich view brings its callers and callees together so you can understand its aggregate cost. You can also filter and group profiles by workload, node, process, or CPU core, and hide runtime frames to focus on the application code you can actually optimize.
Dash0 can also derive metrics from profiling samples at query time, letting you track CPU consumption for individual functions without instrumenting them in advance.
Profiling data is also available to Agent0 and coding agents through Dash0's MCP server. Instead of guessing which code paths to optimize, these agents can use production profiles to investigate CPU bottlenecks and focus on functions that actually consume resources.
Pricing
Profiling follows the exact same transparent, consumption-based model as spans and logs in Dash0. It is billed separately at $0.60 per million samples, with no per-host licenses.
Profiles also get their own lane in SignalControl, allowing you to filter profiling data before storage and keep costs under control. A useful starting point is a low-cost baseline across your fleet, with more detailed collection for workloads you're actively optimizing.
Where this is going next
General availability is just the beginning. We're already working on extending profiling into new workloads and making its insights easier to act on:
-
GPU profiling: Bring continuous profiling to NVIDIA CUDA workloads, helping teams identify GPU bottlenecks in AI training and inference.
-
Deeper trace-to-profile correlation: Navigate from slow requests to the functions executing in their context. The backend already supports this, with Go integration available today and broader language support dependent on evolving OpenTelemetry instrumentation.
-
AutoTune with Agent0: Analyze production profiles to identify expensive code paths and propose optimizations through pull requests, backed by profiling evidence.
We're working toward a future where profiling doesn't just show you where resources are spent, but helps you turn those findings into measurable performance improvements.
Getting started with Dash0 Profiling
Profiling has long been a specialist's tool, something performance engineers would deploy during an investigation and switch off afterward.
We think it belongs in the same place as your other signals, running continuously at a cost you can afford, and connected to the agents that act on what it finds.
Dash0 Profiling is generally available today. If you're already running the Dash0 Operator, enabling profiling is a simple configuration change.
Explore the profiling documentation to get started, or start a free trial and see where your applications are spending CPU time.