CONCEPT Cited by 1 source
Stack tag enrichment¶
Stack tag enrichment is the practice of annotating and filtering profile call stacks at query time with a small DSL that can:
- Add tags (arbitrary strings) to whole stacks or to individual frames / functions they contain;
- Remove frames the viewer doesn't care about using regex matching;
- Be applied per-service or per-profile and composed (multiple schemas in sequence).
The effect is that a flame-graph UI can present the same raw
samples in many different specialised views — e.g. "stacks
tagged as expensive string copies", "stacks tagged as
unintended auto auto-copying", "stacks with the framework
frames stripped". Dashboards can be built on the tag dimension
without any new data capture.
The Strobelight "Stack Schemas" canonical form¶
"Strobelight has multiple mechanisms for enhancing the data it produces according to the needs of its users. One such mechanism is called Stack Schemas (inspired by Microsoft's stack tags), which is a small DSL that operates on call stacks and can be used to add tags (strings) to entire call stacks or individual frames/functions. These tags can then be utilized in our visualization tool. Stack Schemas can also remove functions users don't care about with regex matching. Any number of schemas can be applied on a per-service or even per-profile basis to customize the data."
— Meta Engineering, 2025-01-21 Strobelight post (Source: sources/2025-03-07-meta-strobelight-a-profiling-service-built-on-open-source-technology)
The Strobelight implementation is explicitly inspired by Microsoft's stack tags in Windows Performance Analyzer.
What makes it powerful¶
- Query-time, not capture-time. Tags attach to samples that already exist; the raw capture is unchanged. One schema revision instantly reshapes every historical flamegraph.
- Per-service customisation without forking the capture path. One service sets up a schema for its own domain vocabulary (e.g. "database backend call" / "cache path" / "ML inference") while the capture pipeline remains identical.
- Composable. Multiple schemas apply in sequence — one might tag cache paths, another might strip framework boilerplate, a third might tag known-expensive operations.
Use-case examples (from the Meta post)¶
- Expensive-copy dashboards. Engineers tag
std::vectorcopy calls in hot ads services, turn the tag into a dashboard, spot accidental copies fromauto(the "Biggest Ampersand" — one&, 15,000 servers/year saved). - Unnecessary smart-pointer overhead. Tag frames
containing
shared_ptrcreation/destruction on hot paths. - C++ container misuse. Tag frames calling inappropriate
containers (
std::mapwherestd::unordered_mapis better, linear scans over small constant sets).
The payoff is that static analysis can't tell you which instance is the expensive one. Profile data can.
Differences from runtime metadata attach¶
Stack tag enrichment operates on existing stacks at query time. concepts/runtime-metadata-attach operates on stacks at sample time by reading thread-local storage into each sample. They're complementary — tag enrichment reshapes the view; runtime-metadata-attach adds data that wasn't in the raw stack at all.
Seen in¶
- sources/2025-03-07-meta-strobelight-a-profiling-service-built-on-open-source-technology — canonical Meta instance; Stack Schemas DSL used fleet-wide for custom dashboards on hot-path anti-patterns (vector copies, smart-pointer overuse, container misselection).
Related¶
- systems/strobelight — the canonical production instance.
- concepts/flamegraph-profiling — the dominant consumer of tagged + filtered stacks.
- concepts/stack-trace-sampling-profiling — the parent technique producing the raw stacks.
- concepts/runtime-metadata-attach — the sibling concept that adds data at sample time rather than at query time.
- patterns/profiler-orchestrator — the system shape in which tag enrichment fits.