Should OTel have support for Go execution traces as a signal type?

[rashmi-tondare]

Background

Go's runtime/trace package produces execution traces which is a binary timestamped event stream capturing goroutine state changes, scheduler decisions, GC phases and syscall timings. These have been available since Go 1.5 and the format was significantly overhauled in Go 1.22 to be more structured and splittable.

Execution traces are distinct from what the existing runtime instrumentation package covers. That package is built on runtime/metrics and emits scalar OTel metrics. They are also distinct from pprof-style sampled profiles covered by the OTel profiling signal. Execution traces preserve full causal ordering between individual events rather than aggregating samples. The two are complementary: pprof for continuous aggregate visibility, execution traces for deep causal diagnosis of a specific window.

Go 1.25 added runtime/trace.FlightRecorder, which makes programmatic trace capture possible for the first time, so snapshots can be written to any io.Writer rather than a local file. This introduces the possibility to integrate execution traces into an observability pipeline, but only if OTel has a defined way to receive and represent them.

The gap

There is currently no OTel support for Go execution traces. They cannot be ingested by Pyroscope (pprof format only), Tempo (OTel spans only) or any other backend in the ecosystem. The only tool that understands them is go tool trace, which requires manual retrieval of a local file.

In practice, teams using execution traces in production dump binary snapshots to object storage and log the URL, which ends up entirely outside their existing observability stack. go-squawk is an attempt to at least make the export reliable via FlightRecorder, but it does not solve the underlying gap of execution traces having no place in the OTel ecosystem.

Questions

1. Should OTel treat Go execution traces as a first-class signal or is this intentionally out of scope given that the format is Go-specific and has no cross-language equivalent?

2. Is the existing OTel profiling signal the right place for this or is the event-stream model different enough to need separate treatment?

[pellared]

@rashmi-tondare, please take a look at open-telemetry/opentelemetry-collector-contrib#46089 and leave a comment (and 👍) if you find it useful.