OpenTelemetry support for Buck2 build observability

[schickling-assistant]

Request

Please consider native OpenTelemetry support for Buck2, or a documented stable contract for converting Buck2's existing build observability data into OpenTelemetry traces and metrics.

Buck2 already has useful structured observability surfaces:

• invocation/event logs (buck2 log show, what-ran, critical-path, slowest-path, summary)
• build reports (buck2 build --build-report)
• BuckEvent span start/end/instant events in app/buck2_data/data.proto
• snapshot events with daemon/resource/remote-execution/cache counters
• --client-metadata and --write-build-id for caller correlation

What seems missing is a supported way to connect those signals to standard OTEL backends without every integration depending on unstable implementation details.

Why OTEL would help

Many Buck2 users run builds inside larger CI, fleet, or developer-platform systems that already use OpenTelemetry for distributed tracing and metrics. Those systems need to answer questions like:

• Was time spent before Buck2 started, in Buck2 loading/analysis, local actions, remote execution, cache lookup, upload/download, materialization, or tests?
• Which targets/actions were on the critical path?
• Did a failure come from toolchain setup, analysis, action execution, remote execution, cache/CAS, test execution, or output materialization?
• How should a Buck2 invocation correlate with an existing CI/job/request trace?
• Can build summaries and high-level action spans be queried in standard OTEL tools without storing/parsing full BuckEvent logs in every integration?

A useful generic trace shape would be:

CI/job/request span
  -> buck2 invocation span
    -> load / analysis / action execution / test / materialization spans
    -> remote execution and cache metrics where available

Existing related work

This seems related to, but distinct from, BES/BEP work:

• API design for BuckEvent data #226 discusses API design for BuckEvent data and external event consumers.
• BuckEvent: provide a Buck Event Publisher proto #685 proposed a BuckEvent Publisher proto and discusses queueing, acknowledgements, and reliability.
• Oss observability proposal draft #806 is the OSS observability proposal draft and records consensus around implementing BES/gRPC.
• [WIP] Bazel Build Event Stream support #811 is a WIP Bazel Build Event Stream adapter for Buck2.
• Standardize Build Event Protocol bazelbuild/remote-apis#318 discusses standardizing build event protocols across Bazel/Buck2/Siso/Reclient. One relevant takeaway is that tool-specific build event schemas may remain distinct while a generic observability layer such as OpenTelemetry can still provide cross-tool traces/metrics.

Possible directions

Would the Buck2 maintainers be open to one of these directions?

1. Native OTEL export: opt-in OTLP traces/metrics/logs from Buck2 via config, CLI flags, or environment variables.
2. Stable bridge contract: documented BuckEvent/build-report fields and recommended mappings for external BuckEvent-to-OTEL adapters.
3. Correlation support first: documented support for accepting/surfacing W3C trace context (traceparent/tracestate) or recommended usage of --client-metadata / --write-build-id to link Buck2 invocations into an existing distributed trace.

This would let Buck2 keep BuckEvent as the build-domain source of truth while giving CI and developer-platform systems a principled, standard observability integration path.

Posted on behalf of @schickling

field	value
agent_name	🥉 co2-bronze
agent_session_id	9ccf7eb2-e3d4-4047-b991-c60f5e7b3d43
agent_tool	Codex CLI
agent_tool_version	0.125.0
agent_runtime	Codex CLI 0.125.0
agent_model	unknown
worktree	dotfiles/main
machine	dev3
tooling_profile	dotfiles@unknown-dirty