Add OpenTelemetry (OTLP) Tracing Layer for APM Integration

[tpavlu]

Hey folks! 👋

I've been exploring rspack's tracing capabilities and was impressed by the Perfetto integration - it's great for local profiling. I was hoping to be able to add this tracing in a way that could get collected more automatically internally.

The Problem

For teams using Datadog (or similar APM platforms) for observability across CI/CD pipelines, or developer usage of the rspack dev server it'd be great to track rspack build performance alongside everything else. Right now the only options are:

• perfetto → writes to a file, great for local analysis
• logger → stdout, good for CI logs

Neither of these integrates with the Datadog APM platform out of the box. We currently collect build metrics but would love an automated way to collect higher fidelity tracing information at scale.

What I'm Proposing

Add an otel tracing layer that exports via OpenTelemetry Protocol (OTLP). The nice thing about OTLP is it's vendor-neutral - one implementation works with lots of other tools:

Platform	OTLP Support	Documentation
Datadog	✅	OTLP Ingestion
Grafana Tempo	✅	OTLP Protocol
New Relic	✅	OTLP Endpoint

How It Would Work

Usage would follow the existing patterns:

# Build with OTEL support (feature-gated to keep default builds lean)
pnpm run build:cli:otel

# Then use it like the other layers
RSPACK_PROFILE=OVERVIEW RSPACK_TRACE_LAYER=otel rspack build

For Datadog specifically, you'd enable the OTLP receiver in the agent and you're good to go:

# datadog.yaml
otlp_config:
  receiver:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

The Motivation

The appeal here is:

• Tracking build times over time in the same dashboards as everything else
• Alerting on regressions without building custom tooling
• Correlating slow builds with other pipeline issues

I imagine teams doing CI builds at scale would find this useful.

Implementation Thoughts

The good news is rspack already uses the tracing crate, and there's a mature tracing-opentelemetry bridge. So it should slot in pretty cleanly alongside the existing PerfettoTracer and StdoutTracer.

The main pieces would be:

• Add opentelemetry, opentelemetry-otlp, tracing-opentelemetry as optional deps
• Create an OtelTracer implementing the existing Tracer trait
• Wire it up in the CLI layer handling

Questions

Before I dig deeper, wanted to check:

1. Is this something the team would be interested in supporting?
2. Any concerns about the approach?
3. Preferences on feature flag naming (otel vs opentelemetry)?

Happy to put together a PR if there's interest. Would love to hear thoughts either way!
Wasn't sure the right home so posted here as well
#12915

Can remove which ever is less correct!

[hardfist]

1. Actually we do support OTEL in previous version for our own needs at refactor: tracing #8195, but we found it's not useful as perfetto for detailed async analysis so we remove the support in later version.
2. We would like to do the integration by plugins like https://nextjs.org/docs/app/guides/open-telemetry so @rspack/cli and @rspack/core are not coupled with any otel sdk directly and we're concerned about the increased size，so I'm not sure whethertracing-opentelemetry is a must need(if it's too big), maybe we could collect tracing data using simple tracing layer and the convert it to otel format on js side
3. otel flag seems good

PR is welcome and if the increased size and maintain cost is accept then we can consider support it.