CONCEPT Cited by 1 source
Symbolic-information payload¶
Symbolic-information payload is the side-table of human-readable names accompanying a profile: function names, file paths, line numbers, executable/binary build IDs, and inlining/demangling metadata. It is what turns a profile from a collection of raw instruction addresses into a flame graph an engineer can read.
Why it's architecturally distinctive¶
Unlike metrics or logs, profiling data is a two-part payload:
- Samples — small, structurally uniform (stack frames as pointer chains, with counts/weights).
- Symbolic information — potentially large, structurally irregular, and often dominates storage for real workloads.
This matters because:
- Symbols are high-cardinality but repetitive. One release of one binary has tens of thousands of function names; they repeat across millions of samples. Naive per-sample storage of symbol strings is wasteful.
- Symbols are build-ID-scoped. A new release invalidates the symbol table; each binary generation has its own.
- Symbols can arrive out-of-band. The raw stack frames are instruction addresses; symbolisation can happen at ingest, query, or somewhere in between (see delayed symbolisation).
Any continuous-profiling DB has to design storage for this two-part payload specifically — the lessons from metrics (uniform float time-series) and logs (text lines) don't transfer directly.
In the Pyroscope 2.0 rearchitecture¶
The Pyroscope 2.0 launch post names symbolic information as one of three traits the rearchitecture specifically accommodates:
"Pyroscope 2.0 applies similar architectural principles, adapted for the unique characteristics of profiling data: large payloads, heavy symbolic information, and bursty query patterns."
(Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)
A straight port of Mimir's metrics architecture would not handle the symbolic-information side-table well; the Pyroscope 2.0 engineering is the adaptation.
Prior art: Meta Strobelight¶
Meta's Strobelight deals with the same problem at hyperscaler scale, using a delayed symbolisation service that resolves instruction addresses to symbols only when a profile is actually viewed — keeping the ingest path cheap. Pyroscope 2.0 likely borrows the same deferred-symbolisation idea.
Related¶
- systems/pyroscope-2 — the OSS continuous-profiling DB designed for this payload trait.
- systems/strobelight — hyperscaler prior art.
- concepts/continuous-profiling — the signal class that generates this payload trait.
- concepts/otlp-profiles-signal — the wire format that has to represent the two-part payload.