Add host information to the default OpenTelemetry span.

[RoysyLee]

Goals

1. Enable domain-based separation in monitoring.

Non-Goals

No response

Background

In a SaaS environment, each customer may have a different domain. However, with the current OpenTelemetry setup, it is not possible to separate or distinguish requests based on domain information in the traces.

https://nextjs.org/docs/app/guides/open-telemetry#default-spans-in-nextjs

We attempted to add a custom span tag in the middleware to include domain details. However, in version 15.3, it appears that span tags cannot be added from middleware, making this approach unfeasible.

As a result, OpenTelemetry cannot be effectively used with Next.js in a SaaS context, since domain-based trace separation is essential for observability across multiple tenants.

Our service is not deployed via Vercel, but instead uses Docker-based deployment on a cloud environment. Therefore, we need a more flexible and production-grade observability setup that works outside the Vercel ecosystem.

Proposal

Allow adding custom span tags within Next.js middleware.
This would enable us to inject dynamic information such as the request's domain or tenant identifier at an early stage in the request lifecycle.

Include host (domain) information in the default OpenTelemetry span.
This would allow domain-level trace separation out of the box, without requiring custom instrumentation in middleware or handlers.

[GaneshVarma1]

Hi @RoysyLee 👋 — great question! You can already achieve domain-based trace separation today using OpenTelemetry’s built-in HTTP instrumentation.

Here’s how:

---

✅ Option 1: Add Domain Info via requestHook (Best for SaaS)

Use OpenTelemetry's HttpInstrumentation to tag the incoming HTTP span with the tenant’s domain (host). These spans sit at the top of the trace and work perfectly for multi-tenant filtering.

// otel-register.ts (run with `node --require ./otel-register`)
import { diag, DiagConsoleLogger, DiagLogLevel } from '@opentelemetry/api';
import { NodeSDK } from '@opentelemetry/sdk-node';
import { HttpInstrumentation } from '@opentelemetry/instrumentation-http';
import { registerInstrumentations } from '@opentelemetry/instrumentation';

diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.ERROR);

registerInstrumentations({
  instrumentations: [
    new HttpInstrumentation({
      requestHook: (span, reqInfo) => {
        const host = reqInfo?.request?.headers?.host ??
                     reqInfo?.options?.headers?.host;
        if (host && span) {
          span.setAttribute('app.tenant_domain', host);
        }
      },
    }),
    // add other instrumentations here if needed
  ],
});

const sdk = new NodeSDK();
sdk.start();

💡 Be sure to run this file using:

node --require ./otel-register.js node_modules/.bin/next start

Now every trace will contain a app.tenant_domain attribute for filtering and observability.

---

✅ Option 2: Tag Span Inside Next.js Middleware

You can also tag the active span directly in middleware (works in Next.js 15.3+), before any await:

// middleware.ts
import { NextResponse } from 'next/server';
import { trace, context } from '@opentelemetry/api';

export function middleware(req: Request) {
  const span = trace.getSpan(context.active());
  if (span) {
    span.setAttribute('app.tenant_domain', req.headers.get('host') ?? 'unknown');
  }
  return NextResponse.next();
}

🧠 Note: This only works if you read trace.getSpan(context.active()) before any await. If you await anything first, the context may be lost.

---

💡 Why a Core Change Might Not Be Needed

• The incoming HTTP span already includes attributes like url.host, and now you can enhance it with custom attributes like app.tenant_domain.
• This gives you domain-level trace filtering without requiring changes to the Next.js core or render spans.
• Tools like Datadog, Jaeger, SigNoz, etc., can use these tags for tenant-aware dashboards today.

---

✅ TL;DR

• Use HttpInstrumentation’s requestHook or middleware to inject domain info.
• You'll get rich, domain-aware spans across traces.
• This solution works now — no need to wait for framework support.

Let me know if you want help wiring this up in your setup! 🔧🚀