OpenTelemetry: Improve Trace-Propagation

[lforst]

Goals

The Next.js OpenTelemetry instrumentation should be decisive about trace propagation since the current implementation makes it difficult to use OpenTelemetry instrumentation.

Background

Currently, Next.js propagates OpenTelemetry trace data for incoming requests, but not for outgoing requests. This makes Next.js very tricky to use with existing official OpenTelemetry instrumentation (like the OTEL http instrumentation) which generally instruments both, incoming, and outgoing requests. To be able to use the OTEL instrumentation, you need to either, very expensivley, stomp all spans created by Next.js, or weirdly override the OpenTelemetry instrumentation.

Since it is very common to use the OpenTelemetry HTTP instrumentation, Next.js is probably doing more harm in this situation than good.

Proposal

My proposed solution for this is pretty straightforward:

• Next.js should not concern itself with trace-propagation
• EXCEPT for when propagation requires framework-level capabilities (for example, propagating traces to the client for SSR: Add clientTraceMetadata experimental option to propagate tracing data to the client #64256)

That way, people can, without any complications, implement their own propagation instrumentation logic, without Next.js interfering.

An alternative solution would be for Next.js to instrument and propagate everything (incoming reqs, outgoing http reqs, outgoing fetch reqs, client propagation), but then Next.js has to make guarantees about it.

[dvoytenko]

It might be better to keep outbound instrumentation outside of Next. This is a path we took for @vercel/otel here.

[lforst]

I agree, hence why I originally suggested Next.js should probably not do any propagation. Having thought about it, propagating incoming traces is probably still valuable. 🤔

However, I think Next.js should still propagate in situations where it is impossible for libraries to automatically propagate, like for SSR.

So I think should this PR (#64256) ever be merged, we can probably close this discussion.