Skip to main content

Export run traces via OTLP to your own observability backend

Run Observability already shows OpenTelemetry traces from the worker and the run engine inside Spacelift, and you can download a Jaeger file for a single run. That's useful, but it's not enough for teams that already run Grafana, Tempo, Datadog, Honeycomb, New Relic, or Splunk. They want those spans to land in their own backend automatically, next to the rest of their telemetry, without downloading a file per run.

A large financial services customer running Grafana already has the consumer side built and wants a place to send these traces. Partners and other teams are getting a separate, unparented trace per tofu command and have to filter them by hand. They need a run root span plus export. It's also hard today to tell whether a slow run is on us or on a provider download.

What this should include:

  • An account-level OTLP/HTTP endpoint, with headers and auth, and optionally per-stack or per-space overrides. Batching and retry should be part of it.
  • The same spans you already see in the Observability tab: the run root span, phases, hooks, providers, modules, policy eval, and server-side spans.
  • Propagate TRACEPARENT so OpenTofu's own OTLP spans nest under the Spacelift run. OpenTofu v1.13 supports inbound propagation.
  • Follow OpenTelemetry semantic conventions for attribute names, and keep the endpoint config contract stable. Those are one-way doors.
  • Self-hosted parity on day one.
  • Share the OTLP envelope with the audit and SIEM export work, rather than building this twice.
Workaround
Problem
Status: ⬆️ Gathering votes1 comment

Log in to comment and vote

Comments1

  • Jonah Kowall

    Team•

    Nov 11

    Thanks for writing this up. This is on the plan. Run traces already show in the run's Observability tab and download as a Jaeger file. The next step is a configurable OTLP/HTTP export, so those spans land in your own backend (Grafana Tempo, Datadog, Honeycomb, New Relic, Splunk, or anything OTLP-compatible) without a per-run download.

    Two things come first. One is a single run-level root span, so plan, apply, hooks and OpenTofu spans nest under one trace instead of one trace per command. The other is server-side spans, so you can see time spent between phases and not only on the worker. Shipping export without those would hand you the same fragmented traces you're filtering by hand today.

    We plan to follow OpenTelemetry semantic conventions, keep Spacelift-specific attributes under spacelift.*, and ship self-hosted at the same time. We expect to run a beta before GA. If you want in, comment with the backend you'd send to and whether you use public or private workers. No date yet.