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?

So if someone builds an OTel consumer for these channels, they've only have two options: skip the boundaries they have no convention for, or define their own namespaced spans for them. This is what existing frameworks already do, like Next.js.

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