Use these concepts to read the Profiling Explorer across OpenTelemetry profile types.

Profile and sample

A profile contains call stacks with associated measurement values and metadata about the profiled workload. A sample associates a call stack with values recorded by the profiler. Aggregating samples shows which code paths account for the selected measurement.

The profiler's collection method and configuration determine what it records. With periodic sampling, short-lived work can fall between samples. Do not treat sample counts as a count of every function call.

Profile type and units

Choose a measurement in Profile type. OpenTelemetry profiles specify their measurement types and units.

Unit	Interpretation
Time, such as milliseconds	Read the profile type to distinguish the kind of time being measured. CPU time and elapsed time answer different questions.
Bytes	Interpret values as the memory measurement recorded by the profiler, not as time.
Counts	Check what the profiler counts. Samples, allocations, and function calls are not interchangeable.

Read charts, tables, and comparison legends in the displayed units. Compare the same measurement and units on both sides. Available profile types depend on the data in your dataset.

See the OpenTelemetry Profiles data format for the sample and value-type model.

Frame and call stack

A frame is an entry in a sampled call stack, such as a function. The profiler can supply a function name, source file, line number, binary, and memory address. For compiled code, Dash0 resolves memory addresses to names with debuginfo. See Symbolize Profiles.

A call stack is the ordered sequence of frames for a sample. The root is the outermost end of that sequence. The leaf is the innermost frame to which the sample's measurement is attributed.

A caller invokes a function. A callee is a function it invokes. The Sandwich view shows these relationships around a selected frame.

Self and Total

Self: The measurement attributed directly to the function, excluding its callees.
Total: The measurement attributed to the function together with its callees.

The units follow the selected profile type. For On-CPU, these are self time and total time. For a byte-valued profile, read them in bytes.

A function can have a small Self but a large Total when its callees account for most of the measurement. Start with Self to find leaf-level contributors. Use Total to find the higher-level operations responsible for them.

For example, in an On-CPU profile, a function with 10 ms of self time and 90 ms in its callees has 100 ms of total time. The same relationship applies to byte-valued profiles. Callee values are already included in their callers' Total. Do not add all functions' total values together.

On-CPU

On-CPU profiles describe code observed while executing on a CPU. Use them to investigate CPU consumption in application code, libraries, runtimes, and the kernel.

CPU-time values derived from samples are estimates, not timings of every function invocation. Small differences can reflect sampling variation rather than a change in the code's performance.

On-CPU time is not request latency. A slow request may spend much of its wall-clock duration waiting for a network response or another resource, which an on-CPU profile alone does not explain.

Off-CPU

Off-CPU profiles describe where threads wait while they are not running on a CPU, for example while blocked on locks, I/O, or the scheduler. Use them together with On-CPU profiles when execution time does not explain how long work takes. The operator-managed Parca Agent collects off-CPU profiles when you opt in. See Collect and Send Profiles.

CPU cores

For On-CPU, the CPU cores chart measures CPU consumption in cores, not as a percentage of one machine's capacity. A value of 1 means one CPU-second per second. A value of 2 means two CPU-seconds per second.

CPU time can exceed elapsed time when threads or processes run in parallel. For example, two cores busy for 10 seconds account for 20 CPU-seconds. When you select multiple workloads, the chart shows their combined consumption, not a single host's utilization percentage.

Flame graph and flame chart

A flame graph aggregates call stacks. Frame width represents the amount of profiled activity attributed to a call path. Horizontal position does not represent chronological order. Stack depth shows the call relationships, not how long an individual call lasted.

A flame chart places samples on a time axis. Use it to investigate when activity occurs rather than only its aggregate contribution.

Reversing the call-stack order starts the flame graph at the leaves. It brings leaf contributions together across different callers without changing the samples.

Key Concepts