Post

some pretty cool things are coming for nuxt v5 + o11y 👀

Please please please have the verbose off by default. So many tools are throwing all this on by default and it makes for a bad day 1 experience when you're part of a much wider system. Using this for local development, or if you're the only part of the ecosystem, is amazing though.

This PR is using tracing channels, the example shows every possible span when an APM subscribes to all channels. So by default, even if enabled, Nuxt won't emit anything unless an APM subscribes to every single channel, so I think the noise-control lever should exist there. Does that make sense?

I've assumed OpenTelemetry here, not APM tools. Maybe that isn't correct?

Ah, I understand your concern now. Luckily, this isn't OTel 😁 it's a telemetry agnostic API. It doesn't produce telemetry on its own, the APM has to do it.

I would assume that nuxt is producing a first part otel integration though? Based on this API. Thats the real value these days, not APM tools.

the idea would be that by emitting via tracing channel, you can easily 'catch' that data via an otel integration/plugin, but it's not opinionated tracing channels are agnostic and cross-runtime

"Someone" will need to build that otel receiver, which we're increasingly relying on authors of frameworks to build those out as they're the ones that know where attributes come from etc. The hope is that if the author is the one doing it, then the telemetry available is standards compliant.

Have you done any validation to ensure that you're emitting enough information to be otel compliant?

This PR builds on the tracing channels in h3, srvx, and unstorage (which Nitro sits on). Those expose everything OTel's HTTP and storage conventions need to derive compliant spans. What this PR adds is channels for boundaries OTel has no convention for to be "compliant" with.

I _think_ all we'd have to do to expose these nuxt-specific spans to otel would be a nitro plugin like this