CONCEPT Cited by 1 source

Ad-hoc profiler¶

Ad-hoc profiler = a user-authored profiler — typically written as a small script in a dedicated DSL — that a profiler platform runs as a first-class profiler without requiring source-code changes + code review + release cycle to the platform itself.

It is the escape hatch that makes a centralised profiler orchestrator (patterns/profiler-orchestrator) feel uncentralised from the user's side: the platform ships with the common-case profilers pre-built, and the long tail of questions engineers actually want answered is covered by bring-your-own scripts.

Why it matters¶

Shipping a new first-class profiler is expensive:

"Adding a new profiler from scratch to Strobelight involves several code changes and could take several weeks to get reviewed and rolled out."

— Meta Engineering, 2025-01-21 Strobelight post (Source: sources/2025-03-07-meta-strobelight-a-profiling-service-built-on-open-source-technology)

Meanwhile, most diagnostic questions are narrow: "how long does this one C++ function take on this one call path?", "how many times per second does this inline-allocation hit?". Answering them with a full platform PR is overkill. The ad-hoc-profiler shape lets an engineer:

Write a tiny script in a DSL the platform runs.
Commit the script.
Ship it through the same orchestrator (safety rules, queue management, symbolization, output to the same UI) that the first-class profilers use.

Latency drops from weeks → hours.

Canonical Meta instance (bpftrace)¶

Strobelight supports ad-hoc profilers written in bpftrace — the high-level tracing DSL for Linux eBPF:

"Engineers can write a single bpftrace script (a simple language/tool that allows you to easily write eBPF programs) and tell Strobelight to run it like it would any other profiler. An engineer that really cares about the latency of a particular C++ function, for example, could write up a little bpftrace script, commit it, and have Strobelight run it on any number of hosts throughout Meta's fleet — all within a matter of hours, if needed."

(Source: sources/2025-03-07-meta-strobelight-a-profiling-service-built-on-open-source-technology)

See patterns/ad-hoc-bpftrace-profiler for the pattern.

Design requirements for a platform to support ad-hoc profilers¶

The platform needs:

Sandbox — user-authored code must be safe. eBPF's verifier is the canonical mechanism.
DSL — user-authored source in a compact form. bpftrace is the canonical fit for eBPF.
First-class onboarding — the platform treats the script as a profiler: safety rules, queuing, rate limits, output routing.
Cheap rollout path — commit → run-on-fleet in hours, not weeks.

Safety interplay¶

Ad-hoc profilers re-raise the safety concerns the platform exists to manage — PMU-counter collisions, write-rate to downstream DBs, interference with host workloads. The orchestrator is responsible:

"If all of this sounds powerfully dangerous, that's because it is. However, Strobelight has several safeguards in place to prevent users from causing performance degradation for the targeted workloads and retention issues for the databases Strobelight writes to."