Production debugging becomes complicated when your application is distributed across multiple services.

A request starts in Next.js, reaches a Node.js API, queries a database, and eventually returns an error. You might have logs in one tool, traces in another, and errors somewhere else.

The challenge is connecting all these signals to understand what actually happened.

OpenTelemetry provides a vendor-neutral standard for collecting traces, metrics and logs across distributed applications.

In this tutorial, we'll implement OpenTelemetry across a practical production stack:

• Next.js frontend
• Node.js / Express backend
• Distributed tracing
• Trace-correlated logs
• Kubernetes OpenTelemetry Collector
• Telemetry filtering and sensitive-data scrubbing

1. Configure OpenTelemetry resource attributes

Start by defining consistent service attributes.

OTEL_SERVICE_NAME=checkout-api

OTEL_RESOURCE_ATTRIBUTES=service.namespace=storefront,service.version=1.42.0,deployment.environment.name=production

OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.observability.svc.cluster.local:4318

OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

These attributes help identify which service generated the telemetry.

A useful practice is to populate service.version from your Git SHA or release tag.

2. Instrument Next.js

Install the OpenTelemetry integration:

npm install @vercel/otel @opentelemetry/api

Create instrumentation.ts:

import { registerOTel } from '@vercel/otel';

export function register() {
  registerOTel({
    serviceName: process.env.OTEL_SERVICE_NAME ?? 'web-frontend',
  });
}

This provides instrumentation for supported server-side Next.js operations.

You can also create custom spans around important application operations.

import { trace } from '@opentelemetry/api';

const tracer = trace.getTracer('web-frontend');

export async function getRecommendations(userId: string) {
  return tracer.startActiveSpan(
    'getRecommendations',
    async (span) => {
      try {
        span.setAttribute('app.recommendation.source', 'ml-service');

        return await fetchRecommendations(userId);
      } catch (error) {
        span.recordException(error as Error);
        throw error;
      } finally {
        span.end();
      }
    }
  );
}

Avoid putting sensitive user information into span attributes.

3. Instrument Node.js and Express

Install the SDK and auto-instrumentation packages:

npm install \
  @opentelemetry/sdk-node \
  @opentelemetry/api \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-http \
  @opentelemetry/exporter-metrics-otlp-http \
  @opentelemetry/sdk-metrics

Create instrumentation.js:

const { NodeSDK } = require('@opentelemetry/sdk-node');

const {
  getNodeAutoInstrumentations
} = require('@opentelemetry/auto-instrumentations-node');

const {
  OTLPTraceExporter
} = require('@opentelemetry/exporter-trace-otlp-http');

const {
  OTLPMetricExporter
} = require('@opentelemetry/exporter-metrics-otlp-http');

const {
  PeriodicExportingMetricReader
} = require('@opentelemetry/sdk-metrics');

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter(),

  metricReader: new PeriodicExportingMetricReader({
    exporter: new OTLPMetricExporter(),
    exportIntervalMillis: 30000,
  }),

  instrumentations: [
    getNodeAutoInstrumentations({
      '@opentelemetry/instrumentation-fs': {
        enabled: false,
      },
    }),
  ],
});

sdk.start();

process.on('SIGTERM', () => {
  sdk.shutdown().finally(() => process.exit(0));
});

Load instrumentation before your application

This is critical for auto-instrumentation.

Start your application using:

node --require ./instrumentation.js server.js

For Docker:

CMD ["node", "--require", "./instrumentation.js", "server.js"]

If instrumentation loads after application modules, some libraries might not be instrumented correctly.

4. Correlate logs with traces

Traces explain the execution path. Logs provide additional application context.

The goal is to include trace_id and span_id in relevant log records.

For example:

{
  "msg": "checkout started",
  "cartSize": 3,
  "trace_id": "4bf92f...",
  "span_id": "00f067..."
}

You can collect application logs through stdout using a log collector or export them directly using OTLP.

The important part is preserving the active trace context.

5. Deploy the OpenTelemetry Collector on Kubernetes

Instead of sending telemetry directly from every application to your backend, introduce an OpenTelemetry Collector.

It provides a central place to:

• Filter unnecessary telemetry.
• Remove sensitive attributes.
• Batch records.
• Manage exporters.
• Apply consistent processing policies.

Example Collector configuration:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 25

  filter/healthchecks:
    error_mode: ignore
    traces:
      span:
        - 'attributes["url.path"] == "/healthz"'
        - 'attributes["url.path"] == "/readyz"'

  attributes/scrub:
    actions:
      - key: http.request.header.authorization
        action: delete
      - key: http.request.header.cookie
        action: delete
      - key: user.email
        action: hash

  batch:
    send_batch_size: 8192
    timeout: 5s

exporters:
  otlphttp:
    endpoint: https://YOUR-OTLP-BACKEND:4318

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors:
        - memory_limiter
        - filter/healthchecks
        - attributes/scrub
        - batch
      exporters: [otlphttp]

    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]

    logs:
      receivers: [otlp]
      processors: [memory_limiter, attributes/scrub, batch]
      exporters: [otlphttp]

Replace the exporter endpoint with your backend's actual OTLP endpoint.

For production, validate the filtering rules and scrubbing policies against your actual telemetry schema.

6. Verify your setup

Generate application traffic and verify:

• Every service has the correct service.name.
• Frontend and backend requests appear in distributed traces.
• Logs contain the corresponding trace IDs.
• Health-check spans are filtered.
• Sensitive headers aren't exported.
• SDKs flush telemetry during graceful shutdown.

Common issues:

7. From telemetry collection to incident resolution

Collecting telemetry is only the first step.

When a production incident occurs, engineers still need to correlate errors, logs, traces, user sessions and deployment changes to identify the root cause.

This is the problem Modulis is designed to address.

Modulis is an AI-powered engineering intelligence and incident-resolution platform.

It:

• Correlates logs, traces, errors, sessions and Git context.
• Runs inside the customer's own cloud.
• Uses the customer's own AI model key.
• Identifies likely root causes.
• Opens PR-ready fixes for engineers to review and merge.

Rather than just showing another dashboard, the goal is to move from production incident to a reviewable fix.

You can explore Modulis at https://modulis.ai.

Conclusion

OpenTelemetry gives engineering teams a consistent foundation for understanding distributed applications.

For teams running Next.js, Node.js and Kubernetes, start with consistent resource attributes, instrument your applications, correlate logs and traces, and introduce a Collector to manage telemetry.

The next challenge is making all that collected information useful when production breaks.

That's where engineering intelligence and automated incident resolution become important.

Original guide: https://modulis.ai/blog/opentelemetry-nextjs-nodejs-setup-guide/