feat(pyroscope.ebpf): Expose OTel eBPF profiler internal metrics to Prometheus

[korniltsev-grafanista-yolo-vibecoder239]

Summary

The opentelemetry-ebpf-profiler defines ~213 internal OTel metrics (208 counters, 5 gauges) covering unwinding, caching, symbolization, errors, perf events, and more. These were previously suppressed by passing a noop OTel meter in init(), making profiler internals invisible to operators.

This PR wires a real OTel MeterProvider backed by a Prometheus exporter so these metrics are now scraped alongside the existing pyroscope.ebpf component metrics.

Changes

• Removed ebpfmetrics.Start(metricnoop.Meter{}) from init() which was disabling all profiler metrics
• Added an OTel→Prometheus bridge in New() using the same pattern as alloy's otelcol components:
  • Creates a dedicated prometheus.Registry + OTel SDK Prometheus exporter + MeterProvider
  • Passes the real meter to ebpfmetrics.Start() so all profiler metrics are instrumented
  • Registers the registry with the component's Prometheus registerer for scraping
• Updated component documentation with the new metrics

Implementation details

The opentelemetry-ebpf-profiler/metrics package uses global state — metrics.Start(meter) populates package-level maps of OTel counters and gauges, and metrics.Add()/metrics.AddSlice() are called throughout the profiler at runtime. Since Start() is effectively a one-time setup and all Add calls happen after controller.Start() in Run(), moving the call from init() to New() is safe.

No lazycollector is needed since the meter is created once and never re-wired (unlike otelcol components that recreate on Update()).

Verified locally

Running alloy with a pyroscope.ebpf component, the following new metrics appear on /metrics:

# HELP HashmapNumStackDeltaPages Current size of the stack delta pages hash map
# TYPE HashmapNumStackDeltaPages gauge
HashmapNumStackDeltaPages{component_id="pyroscope.ebpf.instance",component_path="/",otel_scope_name="pyroscope.ebpf",...} 0
# HELP NumExeIDLoadedToEBPF The number of executables loaded to eBPF maps
# TYPE NumExeIDLoadedToEBPF gauge
NumExeIDLoadedToEBPF{component_id="pyroscope.ebpf.instance",component_path="/",otel_scope_name="pyroscope.ebpf",...} 0
# HELP NumGenericPID_total Number of generic PID events (report_events)
# TYPE NumGenericPID_total counter
NumGenericPID_total{component_id="pyroscope.ebpf.instance",component_path="/",otel_scope_name="pyroscope.ebpf",...} 86
# HELP NumProcExit_total Number of exit PID events (report_events)
# TYPE NumProcExit_total counter
NumProcExit_total{component_id="pyroscope.ebpf.instance",component_path="/",otel_scope_name="pyroscope.ebpf",...} 25
# HELP NumProcNew_total Number of new PID events (report_events)
# TYPE NumProcNew_total counter
NumProcNew_total{component_id="pyroscope.ebpf.instance",component_path="/",otel_scope_name="pyroscope.ebpf",...} 67
# HELP UnwindInfoArraySize Current size of the unwind info array
# TYPE UnwindInfoArraySize gauge
UnwindInfoArraySize{component_id="pyroscope.ebpf.instance",component_path="/",otel_scope_name="pyroscope.ebpf",...} 0

Metrics are only emitted after they have been recorded at least once by the profiler. On a busier host with interpreted-language workloads, many more of the ~213 metrics will appear (unwinding, symbolization, cache hits/misses, etc.).

Existing metrics (pyroscope_ebpf_*, pyroscope_symtab_*, pyroscope_pyperf_*) remain present and unchanged.

🤖 Generated with Claude Code

[cla-assistant]

All committers have signed the CLA.

[marcsanmi]

Should we wrap this at package-level with sync.Once? If two pyroscope.ebpf instances exist (the docs say this is possible, though not recommended), the second Start() call creates new OTel instruments on the second instance's meter, overwriting the globals.

Trade-off: With sync.Once, only the first instance's Prometheus registry exports the profiler metrics. This is acceptable since the profiler metrics are global by design (the upstream library uses package-level state). Maybe worth a brief code comment (?)

[marcsanmi]

LGTM