Continuous Profiling English: Grafana Pyroscope Vocabulary
Learn the English vocabulary for continuous profiling and Grafana Pyroscope: flame graphs, CPU sampling, heap profiling, cardinality, and observability terms for DevOps engineers.
Continuous profiling is one of the three pillars of deep observability — alongside metrics and traces. Grafana Pyroscope brings profiling into the same ecosystem as Loki, Tempo, and Prometheus, letting you correlate slow traces with CPU hot spots or memory growth. If you work in DevOps, SRE, or backend engineering, knowing this vocabulary in English will help you communicate clearly in incident channels, design reviews, and vendor discussions. This guide explains the essential terms.
What Is Profiling?
Profiling
Profiling is the process of measuring where a program spends its time (CPU profiling) or how it uses memory (memory profiling) during execution. A profiler is the tool that collects this data.
“Before optimising anything, we profiled the service — the profiler revealed that 60% of CPU time was spent in JSON serialisation.”
Do not confuse profiling with monitoring. Monitoring tells you that something is slow; profiling tells you where in the code the slowness occurs.
Continuous Profiling
Continuous profiling means collecting profiling data constantly in production, not just during one-off debugging sessions. Pyroscope pulls profiles from running services at regular intervals.
“With continuous profiling enabled, we can go back in time and see exactly what the CPU was doing during last Tuesday’s latency spike.”
Core Pyroscope and Profiling Vocabulary
Flame Graph
A flame graph is the primary visualisation for profiling data. It shows a call stack as a series of horizontal bars: the width of each bar represents how much time was spent in that function. The call hierarchy goes top to bottom (or bottom to top, depending on the tool).
“Looking at the flame graph, we can see that
db.query()is taking up nearly half the total CPU time.”
Flame graphs were invented by Brendan Gregg and are now the standard way to visualise profiler output. In English discussions, you will hear: read the flame graph, look at the flame graph, interpret the flame, and a wide bar in the flame graph indicates a hot spot.
Call Stack / Stack Trace
The call stack is the sequence of function calls active at a given moment. Profilers sample call stacks thousands of times per second and aggregate them.
“The call stack showed that every hot path went through
serialize_response— a clear optimisation target.”
Sampling Rate
The sampling rate is how frequently the profiler takes a snapshot of the call stack. Higher sampling rates give more detail but add overhead. Pyroscope’s default is 100 samples per second.
“We lowered the sampling rate in production to reduce profiling overhead.”
CPU Profile
A CPU profile captures where the CPU time is being spent — which functions are “hot” (consuming the most processing time). It answers the question: “What is my code doing?”
“The CPU profile showed that our regex validation ran on every request and was unexpectedly expensive.”
Heap Profile / Memory Profile
A heap profile (or memory profile) shows how memory is allocated — which objects are using the most space and which code paths allocated them. Useful for finding memory leaks.
“The heap profile revealed a leak: we were accumulating connection objects in a map and never releasing them.”
Goroutine Profile (Go-specific)
For Go applications, a goroutine profile shows the state of all goroutines — blocking goroutines can indicate deadlocks or excessive concurrency overhead.
“The goroutine profile showed 4,000 blocked goroutines waiting on a database connection — the pool was exhausted.”
Observability and Cardinality Vocabulary
Observability
Observability is the ability to understand the internal state of a system from its external outputs: logs, metrics, traces, and profiles. The term comes from control theory.
“Our observability stack now covers all four signals: logs in Loki, metrics in Prometheus, traces in Tempo, and profiles in Pyroscope.”
Label / Tag
In Pyroscope, labels (also called tags in some systems) are key-value pairs attached to profile data — for example, service=api, region=eu-west-1, env=production. Labels let you filter and group profiles.
“Add a
versionlabel to your profiles so you can compare CPU usage between releases.”
Cardinality
Cardinality refers to the number of unique values a label can take. High cardinality labels — like user IDs or request IDs — create enormous amounts of data and should be avoided in profiling and metrics.
“Don’t use request IDs as a profile label — the cardinality would be unbounded and crash the storage backend.”
Hot Spot
A hot spot is a section of code that consumes a disproportionate share of CPU time or memory. Flame graphs make hot spots visually obvious as wide bars.
“The flame graph identified the hot spot immediately: all three services were calling the same expensive utility function on every tick.”
Overhead
Overhead is the additional resource consumption introduced by a tool or mechanism — in this case, by the profiler itself. A profiler that consumes 5% of CPU is said to add 5% overhead.
“Pyroscope’s eBPF-based profiler adds minimal overhead — under 1% CPU in most workloads.”
Integration Vocabulary
Instrumentation
Instrumentation is the process of adding code or agents to a system to collect telemetry data (metrics, traces, profiles). Pyroscope supports pull-based and push-based instrumentation.
“We instrumented the service with the Pyroscope Go SDK — it took about 10 lines of code.”
SDK / Agent
The SDK (Software Development Kit) is a library you add to your code to push data to Pyroscope. An agent is a sidecar or separate process that pulls data from the runtime without code changes (e.g., using eBPF).
“For Python services we use the Pyroscope SDK; for Go, we are evaluating the eBPF agent to avoid modifying the application code.”
Exemplar
An exemplar is a trace ID or other reference embedded in a metric or profile data point, allowing you to jump from a profile directly to the corresponding distributed trace.
“Exemplars in Pyroscope let us click from a flame graph straight to the Tempo trace — that cross-signal correlation is the real power.”
Key Collocations
- collect profiles — “Pyroscope collects profiles continuously from all running pods.”
- read a flame graph — “It takes practice to read a flame graph efficiently.”
- identify a hot spot — “We identified the hot spot within minutes of enabling profiling.”
- CPU overhead — “Confirm the CPU overhead before enabling in production.”
- profiling data — “Profiling data is retained for 30 days in our setup.”
- correlate profiles with traces — “Correlate profiles with traces to understand the full picture.”
- sampling interval — “Adjust the sampling interval based on acceptable overhead.”
- memory leak — “The heap profile confirmed a memory leak in the connection pool.”
Phrases for Incident Reviews and Standups
- “Pull up the flame graph for the 14:00 window — I want to see what was hot during the latency spike.”
- “The CPU profile shows that serialisation is our biggest hot spot — that’s where we should focus the optimisation sprint.”
- “We have a memory leak somewhere. The heap profile should tell us which allocation site is responsible.”
- “Let’s correlate the slow trace with the profiling data from the same time window.”
- “Before we ship this change, let’s compare the CPU profile between the old and new versions.”
Practice
Take a recent performance issue you have investigated (or invent a realistic one) and write a 4-to-6-sentence incident summary in English, as if you were posting it in a Slack channel or postmortem document. Include at least 5 terms from this guide: flame graph, hot spot, CPU profile, sampling rate, overhead, continuous profiling, heap profile, or cardinality. Focus on clarity: a good incident summary in English states what happened, where it happened in the code, and what was done about it.