How to scale OTEL instrumentation in Deno without opinionated defaults?

[andreasteich]

Hi everyone, especially @lucacasonato

I'm currently integrating OpenTelemetry (OTEL) in Deno and have a question regarding the current approach.

From my perspective, I’m struggling to understand how this implementation is meant to scale in the long run. It seems that there are no opinionated defaults, leaving it entirely up to the developer to define and manage everything manually.

When a trace is started, I can modify the name and add values globally on the middleware level. However, when Deno makes sub-requests within that trace, these do not automatically inherit meaningful names or status information—they remain undefined unless explicitly set by the developer. This makes me wonder how one is supposed to scale instrumentation properly—would I need to manually update every single sub-request span myself? Or is this actually the intended way to use OTEL in Deno?

Personally, I think it would make sense to provide at least some opinionated defaults, such as setting the span name to something like METHOD /pathname. Since Deno already tracks sub-requests, why not also set the status and a reasonable default name automatically? These pieces of information should already be available, so it feels like an unnecessary burden to require developers to handle them manually.

Since I’m a newbie when it comes to OTEL, I’d really appreciate some clarification. Thanks in advance! 😊

[lucacasonato]

Hey!

We do try to provide reasonable defaults where possible. For example, for the incoming HTTP span we set the method name and record all information we reasonably can on the span. We do the same for outbound fetch - it does include the http.status attribute.

As for the span name, we follow OTEL guidance here:

HTTP span names SHOULD be {method} {target} if there is a (low-cardinality) target available. If there is no (low-cardinality) {target} available, HTTP span names SHOULD be {method}.

https://opentelemetry.io/docs/specs/semconv/http/http-spans/#name

We unfortunately can not automatically determine a low cardinality target, as this is only something the application knows. We can't use a pathname, because it's high cardinality.

For this reason, we set the span name to {method} by default, and then provide a way to override the span name in the HTTP server. For the HTTP client, you can not yet override the span name or add http.route yet, but this will come later.

We expect that for inbound HTTP, your (middleware) framework will (automatically) augment the spans with a better name, it's error events, and a http.route attribute.

For outbound HTTP, API libraries such as octokit, or the AWS SDK should set the span name and attributes for you automatically. If you are manually calling fetch, you would have to set these yourself.