DEV Community: Yuvraj Singh Jadon

Deploying and Scaling OpenTelemetry in Production NextJS Apps

Yuvraj Singh Jadon — Thu, 26 Jun 2025 08:51:48 +0000

Once you’ve instrumented your Next.js app with OpenTelemetry, the next step is getting it into production. Whether you’re shipping via Vercel or running your own infra, the setup has some key differences worth noting.

Option 1: Deploying on Vercel

If you’re using Vercel, good news — OpenTelemetry just works.

As per the Next.js docs, no extra config is needed. Vercel supports OpenTelemetry natively for both Node and Edge runtimes.

Why Vercel works well:

No setup headaches — just deploy and trace
Handles scaling and cold starts for you
Great for hybrid apps (Edge + Node)
Built-in support for observability providers like SigNoz, Datadog, and more

Deploy flow:

vercel deploy

If your instrumentation.ts is set up locally, it’ll work in production too.

Env vars required:

OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.YOUR-REGION.signoz.cloud:443
OTEL_EXPORTER_OTLP_HEADERS=signoz-access-token=your-token

Option 2: Self-Hosting (Docker / K8s)

Prefer full control? Running your app on your own infra with Docker or Kubernetes gives you more power — but also more responsibility.

Why self-host:

Total control over observability data and infra
More flexibility in how you configure the collector
Good for large-scale or compliance-sensitive workloads

What to watch out for:

You’ll manage scaling and HA yourself
Secure your telemetry data pipeline
Set up alerting/monitoring for the collector itself
Allocate ops time — especially if you’re pushing serious traffic

TL;DR

	Vercel	Self-Hosted
Setup	⚡ Super simple	🛠️ Manual infra setup
Scale	📈 Auto (serverless)	📊 You manage it
Observability	🔌 Built-in integrations	🔧 Fully customizable
Best for	Fast-moving teams, hybrid apps	Teams needing full control or compliance

Pick what fits your team’s speed, scale, and infra appetite. Either way, with OpenTelemetry and SigNoz in place, you’re set up to ship and debug confidently in production.

2. Collector vs Direct Exporter

Choosing between an OpenTelemetry Collector and a Direct Exporter setup is one of the most important architectural decisions you’ll make. It affects how flexible, scalable, and robust your observability pipeline is — especially in production.

Collector Approach (Recommended)

This is the most flexible and production-friendly setup. Instead of sending telemetry data straight to your observability backend, your app sends it to an OpenTelemetry Collector. The collector then processes, enriches, and routes it as needed.

Architecture:

Collector-based architecture: Your Next.js app sends telemetry to the OpenTelemetry Collector, which processes and routes data to multiple backends like SigNoz and Prometheus

Why use a Collector?

Vendor-agnostic — Switch observability backends without touching app code
Data processing — Add batching, filtering, sampling, enrichment
Fan-out — Send data to multiple backends at once (e.g., SigNoz + Prometheus)
Better performance — Reduces load on your app by buffering and batching
Centralized auth — Manage credentials and scrub sensitive data in one place
More reliable — Retry and buffer logic during backend downtime

Example Collector Config

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

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  attributes:
    actions:
      - key: environment
        value: production
        action: upsert
  filter:
    spans:
      exclude:
        match_type: regexp
        attributes:
          - key: http.target
            value: "/health.*"

exporters:
  otlp/signoz:
    endpoint: "ingest.YOUR-REGION.signoz.cloud:443"
    headers:
      signoz-access-token: ${SIGNOZ_TOKEN}
  prometheus:
    endpoint: "0.0.0.0:8889"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, attributes, filter]
      exporters: [otlp/signoz]
    metrics:
      receivers: [otlp]
      processors: [batch, attributes]
      exporters: [otlp/signoz, prometheus]

Your Next.js App Config (Collector Setup):

// instrumentation.ts
import { registerOTel } from '@vercel/otel'

export function register() {
  registerOTel({
    serviceName: 'nextjs-production-app',
    endpoint: process.env.OTEL_EXPORTER_OTLP_ENDPOINT || 'http://localhost:4318',
  })
}

Direct Exporter Approach

With this approach, your app sends telemetry data straight to your observability backend — no collector in between.

Architecture

Direct exporter approach: Your Next.js app sends telemetry data straight to SigNoz without any intermediate processing or collector

Pros:

Simpler to set up — fewer moving parts
Lower latency — no intermediate hop
Great for demos or smaller apps

Cons:

No data enrichment, filtering, or custom processing
Hard to route data to multiple platforms
More resource usage inside your app
No retry/buffering logic — dropped data on failure

🔧 Direct Exporter Example:

// instrumentation.ts
import { registerOTel } from '@vercel/otel'
import { OTLPHttpJsonTraceExporter } from '@vercel/otel'

export function register() {
  registerOTel({
    serviceName: 'nextjs-production-app',
    traceExporter: new OTLPHttpJsonTraceExporter({
      url: 'https://ingest.us.signoz.cloud:443/v1/traces',
      headers: {
        'signoz-access-token': process.env.SIGNOZ_INGESTION_KEY || '',
      },
    }),
  })
}

TL;DR - Which One to Choose?

	Collector (Recommended)	Direct Exporter
Vendor flexibility	High	❌ Low
Reliability	Retry + buffer	❌ Risk of drop
Processing	Batch, filter, enrich	❌ None
Infra required	⚠️ Needs extra setup	Minimal
Multi-backend output	Easy fan-out	❌ Not supported
Best for	Prod, large apps	Dev, small projects

In short: use a collector in production if you care about reliability, flexibility, or long-term maintainability. Use direct exporters only for quick setups or demos where speed > control.

Setting Up Alerts

Monitoring without alerts is like a smoke detector without a battery — it might know something’s wrong, but no one hears it.

With SigNoz, you can set up production-grade alerts on latency, errors, external APIs, database health, and more — all powered by auto-generated metrics from your OpenTelemetry traces.

Understanding SigNoz APM Metrics

SigNoz automatically generates structured metrics from your traces. No extra config needed.

Common Metrics You'll Use:

Metric	Description
`signoz_calls_total`	Total number of service calls
`signoz_latency_bucket`	Latency histogram buckets (used for P99, P95, etc)
`signoz_latency_sum/count`	Raw latency values
`signoz_db_latency_sum/count`	Database call timings
`signoz_external_call_latency_sum/count`	External API timings

You can filter any of these by:

service_name
operation (e.g. GET /api/login)
http_status_code
deployment_environment

Alert Example: High P99 Latency

Track if any of your key endpoints cross the 2s P99 threshold — a common user experience red flag.

SigNoz UI Configuration:

Configure P99 latency alerts in SigNoz: Set up alerts on signoz_latency_bucket metric with P99 aggregation and 2000ms threshold

Metric: signoz_latency_bucket
Aggregation: P99
Filter: service.name = nextjs-observability-demo
Group By: operation
Threshold: Above 2000ms for 5 minutes
Severity: Critical

This catches slow endpoints after deployments, during traffic spikes, or when a downstream service misbehaves.

Testing the Alert

Generate alerts manually to verify setup:

# Simulate high latency
curl "http://localhost:3000/api/external?service=slow"

# Simulate 404 errors
for i in {1..20}; do curl -s -o /dev/null -w "%{http_code}\n" http://localhost:3000/not-found; done

# Simulate DB alert (example)
curl http://localhost:3000/api/heavy-database-query

Monitor active alerts in SigNoz: View firing alerts with their severity, status, and notification delivery confirmation

Check:

SigNoz → Alerts → Firing Alerts
Notification channels (Slack, email, PagerDuty)
Auto-resolve when things calm down

Email notification for alert

Maintaining Alert Hygiene

Set it and forget it? Nope. Keep alert fatigue away with regular tuning:

Weekly: Review false positives
Monthly: Adjust thresholds for seasonal traffic
Quarterly: Review what you’re not monitoring
After Incidents: Patch gaps based on what was missed

Tune it:

Raise thresholds if too noisy
Group by operation to reduce clutter
Shorten time windows for fast-reacting alerts

A good alerting setup keeps you ahead of issues — not reacting to user complaints. By wiring up latency, errors, external dependencies, and DB performance, you’ve got a solid first line of defense.

Next time something breaks at 2AM, you’ll already know why.

Sampling Strategy for Production

Once you instrument your app with OpenTelemetry, you’ll quickly realize it can generate a lot of data. That’s where sampling comes in — it lets you retain visibility without flooding your backend (or your bill).

What Sampling Actually Means

Sampling means: “Don’t send every trace, just enough to get the full picture.”

Sampled traces → Get processed and sent to your observability backend
Unsampled traces → Dropped early to save on processing and storage

If you’re getting thousands of requests per second, you probably don’t need all of them to know how your app is doing.

Why You Should Care

Lower costs — Send less data to SigNoz or any observability backend
Less noise — Focus on what's actually interesting (e.g., errors)
Better performance — Reduce tracing overhead on your app
Representative insight — You still see meaningful patterns

When to Use Sampling

Use it if:

You’re seeing 1,000+ traces/sec
Most traffic is routine and low-value
You want to prioritize important traces (errors, latency, critical flows)

Avoid it if:

You have very low traffic
Compliance requires full visibility
You don’t have meaningful sampling rules yet

Head vs Tail Sampling

There are two main ways to decide what gets sampled:

Head Sampling

This makes the decision when the trace starts. Lightweight and works with @vercel/otel.

import { registerOTel } from '@vercel/otel';
import { TraceIdRatioBasedSampler } from '@opentelemetry/sdk-trace-base';

registerOTel({
  serviceName: 'nextjs-app',
  traceSampler: new TraceIdRatioBasedSampler(0.1), // sample 10%
});

Or use environment variables (recommended for production):

OTEL_TRACES_SAMPLER=probabilistic
OTEL_TRACES_SAMPLER_ARG=0.1

Fast
Low overhead
Can’t see the whole trace (might miss errors late in the flow)

Tail Sampling

This happens after the full trace is collected — so it’s smarter, but heavier.

Set up in the OpenTelemetry Collector:

processors:
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: errors
        type: status_code
        status_code: { status_codes: [ERROR] }

      - name: high_latency
        type: latency
        latency: { threshold_ms: 1000 }
        sampling_percentage: 50

      - name: normal_traffic
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }

Smarter decisions
Always catch errors or slow traces
Needs the collector and more infra

Start simple: head sampling via environment variables.

Grow later: add tail sampling when you need more precision.

Review regularly: don’t let old sampling rules hide new problems.

Observability ≠ “log everything” — it’s about getting the right signals. Sampling helps you do that without going broke.

Hiding Sensitive Data

Telemetry can accidentally capture sensitive stuff—emails, tokens, IPs, etc. You’re responsible for making sure that doesn’t happen.

What to Watch For

Common leaks in Next.js apps:

user.email = "john@example.com"
headers.authorization = "Bearer xyz"
http.url = "/reset?token=abc"
process.env.DATABASE_URL

Step 1: Don’t Collect It

registerOTel({
  attributes: {
    'deployment.environment': process.env.NODE_ENV,
    'service.version': process.env.npm_package_version,
    // ❌ Don’t include user emails or IDs
  },
  instrumentationConfig: {
    fetch: {
      ignoreUrls: [/token=/, /session=/],
      dontPropagateContextUrls: [/analytics\./],
      resourceNameTemplate: "{http.method} {http.host}"
    }
  }
})

Step 2: Scrub at the Collector

processors:
  attributes/sanitize:
    actions:
      - key: user.email
        action: delete
      - key: http.request.header.authorization
        action: delete
      - key: http.url.query
        action: delete
  redaction/allowlist:
    allowed_attributes:
      - http.method
      - http.status_code
      - http.route
      - service.name
      - duration

Step 3: Validate No Leaks

# Should return 0
count(rate(traces_total{user_email!=""}[5m]))

# No auth tokens
count(rate(traces_total{http_request_header_authorization!=""}[5m]))

OpenTelemetry unlocks powerful observability, but it’s not magic. You need to be aware of the tradeoffs and plan accordingly. Here’s what to watch out for in real-world Next.js apps.

1. Performance Overhead

OpenTelemetry does introduce overhead. You’re generating spans, propagating context, exporting data—it all costs CPU, memory, and network.

Optimization Strategy

Reduce sampling on high-traffic, low-value routes (e.g., /api/health)
Batch and buffer span exports
Focus tuning on external API routes where the cost is highest

const shouldSample = (route: string) => {
  if (route.includes('/external')) return Math.random() < 0.05;
  if (route.includes('/health')) return Math.random() < 0.01;
  return Math.random() < 0.2;
}

2. Cold Starts (Serverless + Edge)

Cold starts in Vercel functions or edge environments can be amplified by OTel initialization.

Mitigation Techniques

// Lazy init
let tracer = null;
function getTracer() {
  return tracer ??= trace.getTracer('next-app');
}

// HTTP exporter pooling
new OTLPTraceExporter({
  url: OTEL_COLLECTOR_URL,
  keepAlive: true,
});

// Flush before exit (Vercel)
process.on('beforeExit', async () => {
  await trace.getTracerProvider()?.forceFlush();
});

3. Missing Spans

Not everything gets traced automatically.

❌ Common Gaps

Raw fetch() calls (without context propagation)
Database queries using uninstrumented clients
Background jobs (e.g., setTimeout)
Server Components in Next.js
Third-party SDKs (e.g., Stripe, Firebase)

Solutions

Manually wrap spans where needed:

const span = tracer.startSpan('external-call');
try {
  const res = await fetch('https://api.example.com/data');
  span.setAttributes({ 'http.status_code': res.status });
} finally {
  span.end();
}

And ensure context sticks around in async flows:

const ctx = context.active();
setTimeout(() => {
  context.with(ctx, () => {
    processJob();
  });
}, 1000);

Detection Strategy

Add instrumentation coverage checks:

function detectMissingInstrumentation() {
  const span = tracer.startSpan('instrumentation-check');
  if (span.duration > 200 && childSpans.length === 0) {
    span.addEvent('Potential missing spans detected');
  }
}

Or patch key APIs like fetch():

const origFetch = global.fetch;
global.fetch = (...args) => {
  if (!trace.getActiveSpan()) console.warn('Uninstrumented fetch detected');
  return origFetch(...args);
};

Final Thoughts

Observability Changes How You Build

This guide wasn’t just about tracing code—it’s about building smarter systems. You’ve now got:

Real-time visibility into backend and frontend performance
Trace-to-log correlation for fast debugging
Data-driven performance insights
Alerting and dashboards that actually mean something

Mindset Shift

Old World	Observability
Guess where it’s slow	Know where it’s slow
Logs in isolation	Logs + Traces + Metrics
Wait for user reports	Alerts fire first
React after deploy	Optimize before deploy

Key Takeaways

Implementation

Instrument from day one
Use @vercel/otel for fast setup
Correlate logs + traces + metrics via OTel context
Export to SigNoz for unified visibility

Optimization

Smart sampling: 5–25% based on route value
Avoid tracing health checks, bots, noise
SSR routes = low overhead, keep them instrumented
Focus span wrapping on DB, external APIs, and long-running ops

SigNoz Highlights

Built for OpenTelemetry-native apps
Trace + logs + metrics in one UI
Works great for Next.js out of the box
Open-source or managed - your call

Build better. Debug faster. Sleep deeper.

Structured Logging in NextJS with OpenTelemetry

Yuvraj Singh Jadon — Thu, 26 Jun 2025 08:51:46 +0000

Traces tell you what happened and when. Logs tell you why. When something breaks, logs are often your first clue—and if they’re correlated with traces, they can cut debugging time down from hours to minutes.

In this section, we’ll wire up end-to-end structured logging across both server and browser environments in your Next.js app, complete with trace correlation and SigNoz integration.

Why You Need More Than `console.log`

Traditional logging is fine for local development but production needs more:

Structured, searchable logs
Logs tied to specific user actions or trace spans
Server + browser visibility
Centralized analysis and alerting

With OpenTelemetry + SigNoz, you can:

See errors and logs in one place
Correlate logs with spans (traceId, spanId)
Analyze structured metadata (userId, URL, duration, etc.)
Monitor logs from both the client and server

Server-Side Logging with Trace Context

Step 1: Install Required Packages

npm install @opentelemetry/api-logs @opentelemetry/sdk-logs @opentelemetry/exporter-logs-otlp-http pino

Dependency Breakdown:

@opentelemetry/api-logs: Core logging API
@opentelemetry/sdk-logs: SDK for log processing and export
@opentelemetry/exporter-logs-otlp-http: OTLP HTTP exporter for logs
pino: High-performance structured logging library

Step 2: Create the Logs Exporter

This sends structured logs to the OpenTelemetry collector:

// lib/logs-exporter.ts

import { logs } from "@opentelemetry/api-logs";
import {
  LoggerProvider,
  BatchLogRecordProcessor,
} from "@opentelemetry/sdk-logs";
import { OTLPLogExporter } from "@opentelemetry/exporter-logs-otlp-http";
import { Resource } from "@opentelemetry/resources";
import {
  ATTR_SERVICE_NAME,
  ATTR_SERVICE_VERSION,
} from "@opentelemetry/semantic-conventions";
import type { LogEntry } from "./logger";

let isInitialized = false;
let loggerProvider: LoggerProvider | null = null;

export function initializeLogsExporter() {
  if (isInitialized || typeof window !== "undefined") {
    return; // Only initialize on server side
  }

  try {
    // Create resource with service information
    const resource = new Resource({
      [ATTR_SERVICE_NAME]: "nextjs-observability-demo",
      [ATTR_SERVICE_VERSION]: "1.0.0",
    });

    // Create OTLP exporter
    const logExporter = new OTLPLogExporter({
      url: "http://localhost:4318/v1/logs",
      headers: {},
    });

    // Create logger provider
    loggerProvider = new LoggerProvider({
      resource: resource as any,
    });

    // Add batch processor
    loggerProvider.addLogRecordProcessor(
      new BatchLogRecordProcessor(logExporter, {
        maxExportBatchSize: 10,
        scheduledDelayMillis: 5000, // Export every 5 seconds
        exportTimeoutMillis: 30000,
        maxQueueSize: 100,
      })
    );

    // Set global logger provider
    logs.setGlobalLoggerProvider(loggerProvider);
    isInitialized = true;
    console.log(" OpenTelemetry logs exporter initialized");
  } catch (error) {
    console.error("❌ Failed to initialize logs exporter:", error);
  }
}

export function exportLogEntry(entry: LogEntry) {
  if (!isInitialized || !loggerProvider || typeof window !== "undefined") {
    return;
  }

  try {
    const logger = loggerProvider.getLogger("nextjs-observability-demo");

    // Build attributes object
    const attributes: Record<string, any> = {
      ...entry.context,
      "log.level": entry.level,
      "service.name": "nextjs-observability-demo",
    };

    // Add error details if present
    if (entry.error) {
      attributes["error.name"] = entry.error.name;
      attributes["error.message"] = entry.error.message;
      attributes["error.stack"] = entry.error.stack;
    }

    // Convert our log entry to OpenTelemetry log record
    const logRecord = {
      timestamp: Date.now(),
      observedTimestamp: Date.now(),
      severityNumber: getSeverityNumber(entry.level),
      severityText: entry.level.toUpperCase(),
      body: entry.message,
      attributes,
    };

    logger.emit(logRecord);
  } catch (error) {
    console.error("Failed to export log entry:", error);
  }
}

function getSeverityNumber(level: string): number {
  switch (level) {
    case "debug":
      return 5; // DEBUG
    case "info":
      return 9; // INFO
    case "warn":
      return 13; // WARN
    case "error":
      return 17; // ERROR
    default:
      return 9; // Default to INFO
  }
}

export function shutdownLogsExporter(): Promise<void> {
  if (loggerProvider) {
    return loggerProvider.shutdown();
  }
  return Promise.resolve();
}

Step 3: Unified Logger

This is your standard logging API across server and client:

// lib/logger.ts

import { trace } from "@opentelemetry/api";
import { exportLogEntry } from "./logs-exporter";

export interface LogContext {
  traceId?: string;
  spanId?: string;
  userId?: string;
  requestId?: string;
  sessionId?: string;
  [key: string]: any;
}

export interface LogEntry {
  timestamp: string;
  level: "debug" | "info" | "warn" | "error";
  message: string;
  context?: LogContext;
  error?: Error;
}

class Logger {
  private getTraceContext(): { traceId?: string; spanId?: string } {
    try {
      const span = trace.getActiveSpan();
      if (span) {
        const spanContext = span.spanContext();
        return {
          traceId: spanContext.traceId,
          spanId: spanContext.spanId,
        };
      }
    } catch (error) {
      // Ignore trace context errors
    }
    return {};
  }

  private log(
    level: LogEntry["level"],
    message: string,
    context?: LogContext,
    error?: Error
  ) {
    const traceContext = this.getTraceContext();
    const entry: LogEntry = {
      timestamp: new Date().toISOString(),
      level,
      message,
      context: {
        ...traceContext,
        ...context,
      },
      error,
    };

    // Always log to console
    const logMethod =
      level === "error"
        ? console.error
        : level === "warn"
        ? console.warn
        : level === "debug"
        ? console.debug
        : console.log;

    if (error) {
      logMethod(`[${level.toUpperCase()}] ${message}`, entry.context, error);
    } else {
      logMethod(`[${level.toUpperCase()}] ${message}`, entry.context);
    }

    // Export to OpenTelemetry collector (server-side only)
    if (typeof window === "undefined") {
      try {
        exportLogEntry(entry);
      } catch (exportError) {
        console.error("Failed to export log to OTel:", exportError);
      }
    }

    return entry;
  }

  debug(message: string, context?: LogContext) {
    return this.log("debug", message, context);
  }

  info(message: string, context?: LogContext) {
    return this.log("info", message, context);
  }

  warn(message: string, context?: LogContext) {
    return this.log("warn", message, context);
  }

  error(message: string, error?: Error, context?: LogContext) {
    return this.log("error", message, context, error);
  }

  // Convenience methods for common patterns

  request(
    method: string,
    url: string,
    statusCode: number,
    duration: number,
    context?: LogContext
  ) {
    return this.info(`${method} ${url} ${statusCode}`, {
      ...context,
      httpMethod: method,
      httpUrl: url,
      httpStatusCode: statusCode,
      duration,
      type: "request",
    });
  }

  externalCall(
    service: string,
    method: string,
    url: string,
    duration: number,
    success: boolean,
    context?: LogContext
  ) {
    const level = success ? "info" : "error";
    return this.log(level, `External call to ${service}: ${method} ${url}`, {
      ...context,
      externalService: service,
      httpMethod: method,
      httpUrl: url,
      duration,
      success,
      type: "external_call",
    });
  }

  performance(operation: string, duration: number, context?: LogContext) {
    const level = duration > 1000 ? "warn" : "info";
    return this.log(level, `Performance: ${operation} took ${duration}ms`, {
      ...context,
      operation,
      duration,
      type: "performance",
    });
  }

  business(event: string, context?: LogContext) {
    return this.info(`Business event: ${event}`, {
      ...context,
      event,
      type: "business",
    });
  }

  security(event: string, context?: LogContext) {
    return this.warn(`Security event: ${event}`, {
      ...context,
      event,
      type: "security",
    });
  }
}

export const logger = new Logger();

// Convenience functions for quick logging
export const log = {
  debug: (message: string, context?: LogContext) =>
    logger.debug(message, context),
  info: (message: string, context?: LogContext) =>
    logger.info(message, context),
  warn: (message: string, context?: LogContext) =>
    logger.warn(message, context),
  error: (message: string, error?: Error, context?: LogContext) =>
    logger.error(message, error, context),
};

Logs include traceId, spanId, timestamp
Supports levels: debug, info, warn, error
Auto-exports to collector (on server only)

Step 4: High-Performance Pino Logger (Optional)

Use pino for faster logs in production:

// lib/pino-logger.ts

import pino from "pino";
import { trace } from "@opentelemetry/api";
import type { LogContext } from "./logger";

// Pino configuration for different environments
const createPinoConfig = (environment: string = "development") => {
  const baseConfig = {
    name: "nextjs-observability-demo",
    level: environment === "production" ? "info" : "debug",
    timestamp: pino.stdTimeFunctions.isoTime,
    formatters: {
      level: (label: string) => ({ level: label }),
    },
    mixin: () => {
      // Automatically inject trace context into every log
      const span = trace.getActiveSpan();
      const spanContext = span?.spanContext();
      return {
        traceId: spanContext?.traceId,
        spanId: spanContext?.spanId,
        environment,
      };
    },
  };
  return baseConfig;
};

// Create Pino logger instance
export const pinoLogger = pino(createPinoConfig(process.env.NODE_ENV));

// Enhanced Pino logger with additional context methods
export class PinoLogger {
  private logger: pino.Logger;

  constructor(logger: pino.Logger = pinoLogger) {
    this.logger = logger;
  }

  private enrichContext(context: LogContext = {}): LogContext {
    const span = trace.getActiveSpan();
    const spanContext = span?.spanContext();
    return {
      traceId: spanContext?.traceId,
      spanId: spanContext?.spanId,
      timestamp: new Date().toISOString(),
      ...context,
    };
  }

  debug(message: string, context?: LogContext) {
    this.logger.debug(this.enrichContext(context), message);
  }

  info(message: string, context?: LogContext) {
    this.logger.info(this.enrichContext(context), message);
  }

  warn(message: string, context?: LogContext) {
    this.logger.warn(this.enrichContext(context), message);
  }

  error(message: string, error?: Error, context?: LogContext) {
    const enrichedContext = this.enrichContext(context);
    if (error) {
      enrichedContext.error = {
        name: error.name,
        message: error.message,
        stack: error.stack,
      };
    }
    this.logger.error(enrichedContext, message);
  }

  // Specialized logging methods

  logRequest(req: any, context?: LogContext) {
    this.info("HTTP Request", {
      ...context,
      method: req.method,
      url: req.url,
      userAgent: req.headers?.["user-agent"],
      ip: req.headers?.["x-forwarded-for"] || req.connection?.remoteAddress,
    });
  }

  logDbOperation(
    operation: string,
    table: string,
    duration: number,
    context?: LogContext
  ) {
    this.info("Database Operation", {
      ...context,
      operation,
      table,
      duration: `${duration}ms`,
    });
  }

  logExternalCall(
    url: string,
    method: string,
    statusCode: number,
    duration: number,
    context?: LogContext
  ) {
    this.info("External API Call", {
      ...context,
      url,
      method,
      statusCode,
      duration: `${duration}ms`,
    });
  }
}

export const serverLogger = new PinoLogger(pinoLogger);

Client-Side Logging with Auto-Export

Step 5: Create Browser Logger

// lib/browser-logger.ts
"use client";

import { trace } from "@opentelemetry/api";
import type { LogContext } from "./logger";

export interface BrowserLogEntry {
  level: "debug" | "info" | "warn" | "error";
  message: string;
  context?: LogContext;
  timestamp: string;
  url?: string;
  userAgent?: string;
  error?: {
    name: string;
    message: string;
    stack?: string;
  };
}

class BrowserLogger {
  private logs: BrowserLogEntry[] = [];
  private maxLogs = 1000;
  private flushInterval = 10000; // 10 seconds
  private collectorUrl = "/api/logs";

  constructor() {
    if (typeof window !== "undefined") {
      this.setupGlobalErrorHandlers();
      this.startPeriodicFlush();
    }
  }

  private enrichContext(context: LogContext = {}): LogContext {
    const span = trace.getActiveSpan();
    const spanContext = span?.spanContext();

    return {
      traceId: spanContext?.traceId || "no-trace",
      spanId: spanContext?.spanId || "no-span",
      url: window.location.href,
      userAgent: navigator.userAgent,
      sessionId: this.getSessionId(),
      ...context,
    };
  }

  private getSessionId(): string {
    let sessionId = sessionStorage.getItem("session-id");
    if (!sessionId) {
      sessionId = crypto.randomUUID();
      sessionStorage.setItem("session-id", sessionId);
    }
    return sessionId;
  }

  private createLogEntry(
    level: BrowserLogEntry["level"],
    message: string,
    context?: LogContext,
    error?: Error
  ): BrowserLogEntry {
    const entry: BrowserLogEntry = {
      level,
      message,
      context: this.enrichContext(context),
      timestamp: new Date().toISOString(),
      url: window.location.href,
      userAgent: navigator.userAgent,
    };

    if (error) {
      entry.error = {
        name: error.name,
        message: error.message,
        stack: error.stack,
      };
    }

    return entry;
  }

  debug(message: string, context?: LogContext) {
    const entry = this.createLogEntry("debug", message, context);
    this.addLog(entry);
    console.debug(`[BROWSER DEBUG] ${message}`, entry.context);
  }

  info(message: string, context?: LogContext) {
    const entry = this.createLogEntry("info", message, context);
    this.addLog(entry);
    console.info(`[BROWSER INFO] ${message}`, entry.context);
  }

  warn(message: string, context?: LogContext) {
    const entry = this.createLogEntry("warn", message, context);
    this.addLog(entry);
    console.warn(`[BROWSER WARN] ${message}`, entry.context);
  }

  error(message: string, error?: Error, context?: LogContext) {
    const entry = this.createLogEntry("error", message, context, error);
    this.addLog(entry);
    console.error(`[BROWSER ERROR] ${message}`, entry.context, error);
  }

  // Specialized logging methods

  logNavigation(from: string, to: string) {
    this.info("Navigation", {
      event: "navigation",
      from,
      to,
      timing: performance.now(),
    });
  }

  logUserInteraction(action: string, element?: string, context?: LogContext) {
    this.info("User Interaction", {
      ...context,
      event: "user_interaction",
      action,
      element,
      timing: performance.now(),
    });
  }

  logApiCall(
    url: string,
    method: string,
    status: number,
    duration: number,
    context?: LogContext
  ) {
    const level = status >= 400 ? "error" : status >= 300 ? "warn" : "info";
    this[level](`API Call: ${method} ${url}`, {
      ...context,
      event: "api_call",
      url,
      method,
      status,
      duration,
    });
  }

  private addLog(entry: BrowserLogEntry) {
    this.logs.push(entry);
    // Keep only the most recent logs
    if (this.logs.length > this.maxLogs) {
      this.logs = this.logs.slice(-this.maxLogs);
    }
  }

  private setupGlobalErrorHandlers() {
    // Unhandled JavaScript errors
    window.addEventListener("error", (event) => {
      this.error("Unhandled Error", event.error, {
        event: "unhandled_error",
        filename: event.filename,
        lineno: event.lineno,
        colno: event.colno,
      });
    });

    // Unhandled promise rejections
    window.addEventListener("unhandledrejection", (event) => {
      this.error("Unhandled Promise Rejection", event.reason, {
        event: "unhandled_rejection",
        reason: event.reason?.toString(),
      });
    });
  }

  private startPeriodicFlush() {
    setInterval(() => {
      this.flush();
    }, this.flushInterval);

    // Flush on page unload
    window.addEventListener("beforeunload", () => {
      this.flush();
    });
  }

  async flush() {
    if (this.logs.length === 0) return;

    const logsToSend = [...this.logs];
    this.logs = [];

    try {
      const response = await fetch(this.collectorUrl, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
        },
        body: JSON.stringify(logsToSend),
      });

      if (!response.ok) {
        console.error("Failed to send logs to server:", response.statusText);
        // Re-add logs if send failed
        this.logs.unshift(...logsToSend);
      }
    } catch (error) {
      console.error("Error sending logs:", error);
      // Re-add logs if send failed
      this.logs.unshift(...logsToSend);
    }
  }

  getLogs(): BrowserLogEntry[] {
    return [...this.logs];
  }

  clearLogs() {
    this.logs = [];
  }
}

export const browserLogger = new BrowserLogger();

// Convenience exports
export const browserLog = {
  debug: (message: string, context?: LogContext) =>
    browserLogger.debug(message, context),
  info: (message: string, context?: LogContext) =>
    browserLogger.info(message, context),
  warn: (message: string, context?: LogContext) =>
    browserLogger.warn(message, context),
  error: (message: string, error?: Error, context?: LogContext) =>
    browserLogger.error(message, error, context),
  navigation: (from: string, to: string) =>
    browserLogger.logNavigation(from, to),
  userInteraction: (
    action: string,
    element?: string,
    context?: LogContext
  ) => browserLogger.logUserInteraction(action, element, context),
  apiCall: (
    url: string,
    method: string,
    status: number,
    duration: number,
    context?: LogContext
  ) => browserLogger.logApiCall(url, method, status, duration, context),
  flush: () => browserLogger.flush(),
  getLogs: () => browserLogger.getLogs(),
  clearLogs: () => browserLogger.clearLogs(),
};
j

Buffers logs in memory
Adds browser metadata (URL, userAgent, sessionId)
Automatically flushes logs to server every 10s

Step 6: API Route to Receive Logs

// app/api/logs/route.ts

import { NextRequest, NextResponse } from "next/server";
import { logger } from "@/lib/logger";
import { initializeLogsExporter } from "@/lib/logs-exporter";

// Ensure logs exporter is initialized for API routes
initializeLogsExporter();

export async function POST(request: NextRequest) {
  try {
    const logs = await request.json();

    if (!Array.isArray(logs)) {
      return NextResponse.json(
        { error: "Invalid logs format" },
        { status: 400 }
      );
    }

    console.log(`🔄 Processing ${logs.length} browser logs...`);

    // Process each log entry from the browser
    for (const log of logs) {
      const { level, message, context, error } = log;

      // Add browser-specific context
      const enrichedContext = {
        ...context,
        source: "browser",
        userAgent: request.headers.get("user-agent"),
        referer: request.headers.get("referer"),
      };

      // Forward to server logger (which also exports to OTel)
      switch (level) {
        case "debug":
          logger.debug(message, enrichedContext);
          break;
        case "info":
          logger.info(message, enrichedContext);
          break;
        case "warn":
          logger.warn(message, enrichedContext);
          break;
        case "error":
          const errorObj = error ? new Error(error.message) : undefined;
          if (errorObj && error.stack) {
            errorObj.stack = error.stack;
          }
          logger.error(message, errorObj, enrichedContext);
          break;
        default:
          logger.info(message, enrichedContext);
      }
    }

    return NextResponse.json({
      success: true,
      processed: logs.length,
    });

  } catch (error) {
    console.error("❌ Failed to process browser logs:", error);
    logger.error("Failed to process browser logs", error as Error);
    return NextResponse.json(
      { error: "Failed to process logs" },
      { status: 500 }
    );
  }
}

This route receives browser logs and sends them to the collector with trace context.

Instrumentation Hook

Step 7: Add to `instrumentation.ts`

import { registerOTel } from "@vercel/otel";
import { initializeLogsExporter } from "./lib/logs-exporter";

export function register() {
  registerOTel({
    serviceName: "nextjs-observability-demo",
    instrumentationConfig: {
      fetch: {
        // Propagate context to all external URLs to enable proper tracing
        propagateContextUrls: [
          /jsonplaceholder\.typicode\.com/,
          /httpbin\.org/,
          /api\.openweathermap\.org/,
          // Add more external domains as needed
        ],
        // Don't ignore any URLs - we want to trace all external calls
        ignoreUrls: [],
        // Enable resource naming for better span identification
        resourceNameTemplate: "{http.method} {http.host}{http.target}",
      },
    },
  });

  // Initialize logs exporter for OpenTelemetry
  initializeLogsExporter();
}

Logs Demo Page

Step 8: Create `logs-demo/page.tsx`

Create a page that lets you trigger logs from browser and server:

Simulate API calls, slow requests, errors
Generate and view structured logs
Verify export to collector and SigNoz

View Logs in SigNoz

Step 9: Explore Your Logs

Go to SigNoz → Logs
Filter by source: source="browser" or source="server"

Filter logs by source (browser/server) and view structured log entries with trace context in SigNoz
Click any log to view trace metadata

Navigate between logs and traces seamlessly in SigNoz
Correlate with full request trace via traceId

Click 'Inspect in Trace' to jump from logs to the full distributed trace view with all spans and timing information

The real power of working with logs and traces in SigNoz comes from correlation - click "Inspect in Trace" or the trace ID to jump directly to the corresponding trace when checking a log or "Go to related logs" from any trace details page.

Next: Production Deployment and Scaling

With instrumentation, metrics, and logging in place, you're ready for production. In the next article, we'll cover deploying your instrumented Next.js app, choosing between collector vs direct exporter setups, implementing smart sampling strategies, and setting up production-grade alerting.

Tracking Web Vitals & Widget Performance in Next.js with OpenTelemetry

Yuvraj Singh Jadon — Thu, 26 Jun 2025 08:47:59 +0000

Web vitals are critical to understanding real-world user experience. Metrics like loading time, layout stability, and interactivity directly impact how users perceive your app—and they influence SEO rankings too.

By capturing these metrics with OpenTelemetry and visualizing them in a tool like SigNoz, you get a complete view of frontend performance, tightly correlated with backend traces.

Metric	What It Measures	Good	Needs Improvement	Poor
LCP	Load time for main content	≤ 2.5s	2.5–4.0s	> 4.0s
INP	Interaction responsiveness	≤ 200ms	200–500ms	> 500ms
CLS	Layout shift stability	≤ 0.1	0.1–0.25	> 0.25
FCP	First visible render	≤ 1.8s	1.8–3.0s	> 3.0s
TTFB	Time until first byte received	≤ 800ms	800ms–1.8s	> 1.8s

Use these metrics to set baselines, identify regressions, and drive performance improvements where they actually matter: in the user’s browser.

1. Install Dependencies

npm install @opentelemetry/exporter-metrics-otlp-http \
            @opentelemetry/resources \
            @opentelemetry/sdk-metrics \
            @opentelemetry/semantic-conventions \
            web-vitals

Dependencies Explained:

@opentelemetry/exporter-metrics-otlp-http: Exports metrics to collector via HTTP
@opentelemetry/resources: Defines service resource information
@opentelemetry/sdk-metrics: Core metrics SDK for browser
@opentelemetry/semantic-conventions: Standard attribute names
web-vitals: Google’s web vitals measurement library

2. Create `lib/web-vitals.ts`

"use client";
import { MeterProvider, PeriodicExportingMetricReader } from "@opentelemetry/sdk-metrics";
import { OTLPMetricExporter } from "@opentelemetry/exporter-metrics-otlp-http";
import { Resource } from "@opentelemetry/resources";
import { metrics } from "@opentelemetry/api";
import { ATTR_SERVICE_NAME } from "@opentelemetry/semantic-conventions";
import { onLCP, onINP, onCLS } from "web-vitals";

let isInitialized = false;
export function initializeWebVitals() {
  if (typeof window === "undefined" || isInitialized) return;

  const resource = new Resource({
    [ATTR_SERVICE_NAME]: "nextjs-app-frontend",
  });

  const reader = new PeriodicExportingMetricReader({
    exporter: new OTLPMetricExporter({ url: "http://localhost:4318/v1/metrics" }),
    exportIntervalMillis: 10000,
  });

  const meterProvider = new MeterProvider({ resource, readers: [reader] });
  metrics.setGlobalMeterProvider(meterProvider);
  const meter = metrics.getMeter("web-vitals");

  const lcp = meter.createHistogram("web_vitals_lcp", { unit: "ms" });
  const inp = meter.createHistogram("web_vitals_inp", { unit: "ms" });
  const cls = meter.createUpDownCounter("web_vitals_cls", { unit: "1" });

  const record = (metric: any) => {
    const attrs = {
      page: window.location.pathname,
      rating: metric.rating,
    };
    if (metric.name === "LCP") lcp.record(metric.value, attrs);
    else if (metric.name === "INP") inp.record(metric.value, attrs);
    else if (metric.name === "CLS") cls.add(metric.value, attrs);
  };

  onLCP(record);
  onINP(record);
  onCLS(record);
  isInitialized = true;
}

3. Add WebVitalsProvider

// components/web-vitals-provider.tsx
"use client";
import { useEffect } from "react";
import { initializeWebVitals } from "@/lib/web-vitals";

export function WebVitalsProvider({ children }: { children: React.ReactNode }) {
  useEffect(() => {
    initializeWebVitals();
  }, []);
  return <>{children}</>;
}

4. Use in Your Layout

// app/layout.tsx
import { WebVitalsProvider } from "@/components/web-vitals-provider";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <WebVitalsProvider>{children}</WebVitalsProvider>
      </body>
    </html>
  );
}

5. Enable CORS for the Collector

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
        cors:
          allowed_origins:
            - "http://localhost:3000"
          allowed_headers: ["*"]

6. Visualize in SigNoz

Navigate to Metrics
Look for metrics like web_vitals_lcp, web_vitals_inp, and web_vitals_cls

View Web Vitals metrics in SigNoz - track LCP, INP, and CLS performance over time with page-level breakdowns
Create a dashboard to track these over time

Create custom dashboards in SigNoz to monitor Web Vitals trends and identify performance regressions across different pages

Quick Tips

Reduce exportIntervalMillis in production to lower overhead
Sample metrics if your traffic is high
Avoid sending user-identifiable data in metric attributes

With just a few lines, you now get real user performance data streaming into your observability stack.

Tracking Third-Party Widget Performance

Third-party widgets—chatbots, analytics, ads, support tools—bring useful functionality, but also unpredictable performance baggage. A slow widget can tank your LCP, stall interactivity, or wreck your layout—and because it’s not your code, debugging becomes a guessing game.

You can’t instrument inside a third-party <iframe> or <script>, but you can measure its impact on your app.

The Strategy: Wrap and Measure

Use OpenTelemetry’s manual instrumentation to wrap the widget with a custom span:

// components/ThirdPartyWidget.tsx
"use client";
import { useEffect } from "react";
import { trace } from "@opentelemetry/api";

export function ThirdPartyWidget() {
  useEffect(() => {
    const tracer = trace.getTracer("widget-load-tracer");
    const span = tracer.startSpan("load_intercom_widget");

    const script = document.createElement("script");
    script.src = "https://widget.example.com/widget.js";
    script.async = true;

    script.onload = () => {
      span.end(); // Marks load completion
    };

    document.body.appendChild(script);
  }, []);

  return null;
}

This span tracks how long the widget takes to load and reports it to your tracing backend (e.g., SigNoz). Repeat this pattern for other widgets as needed.

Why It’s Worth Doing

Find Slow Widgets: Know exactly which scripts are hurting UX

Back Up Decisions: Use data to lazy-load, replace, or remove costly widgets

Vendor Accountability: Quantify impact when negotiating SLAs

Improve CWV Scores: Clean up your LCP/INP by ditching bloated embeds

Third-party performance isn’t a black box anymore. If it runs on your page, you should be tracking it.

Next: Structured Logging with Trace Correlation

While metrics tell you what is happening, logs tell you why. In the next article, we'll implement structured logging across both server and browser environments—with full trace correlation so you can jump from a performance spike directly to the relevant log entries.

NextJS OpenTelemetry Use Cases - Monitoring 404s, External APIs, Exceptions & More

Yuvraj Singh Jadon — Thu, 26 Jun 2025 08:29:23 +0000

Let’s talk about one of the most powerful features of SigNoz enabled via OpenTelemetry: Query Builder.

Whether you’re tracking 404s, debugging API latency, or monitoring business metrics from your NextJS application, the Query Builder lets you slice your telemetry data—traces, metrics, logs—without learning a new query language.

Let’s walk through a practical example: monitoring 404 errors in production.

Tracking 404 Errors by Route

404s are often ignored—until broken links start affecting SEO or users drop off at checkout. SigNoz makes it easy to proactively monitor and surface route-level 404 issues.

Step-by-Step: Setup 404 Monitoring

1. Open Traces → Explorer

In the SigNoz UI, head to Traces > Explorer.

2. Apply Filters

service.name = nextjs-observability-demo
http.status_code = 404

Set your time range to “Last 1 day” or any relevant window.

You’ll now see a breakdown of which routes are returning 404s and how often.

Filter and analyze 404 errors in SigNoz: Use the Traces Explorer to identify which routes are returning 404s and track their frequency over time

What You Can Uncover

/auth/missing-profile – broken login flow?
/api/v1/deprecated-endpoint – old mobile app still hitting deprecated APIs?
/static/dead-banner.webp – CDN issue or asset removed?

You can also switch to the Time Series view to see trends—are 404s spiking after a deploy?

Monitor 404 error trends: Switch to time series view in SigNoz to detect spikes in 404 errors after deployments or identify patterns in broken links

Save and Visualize

Need to query the same thing again? You’ve got options:

Save the View

Give it a name like 404 Error Monitor, save it for reuse.
Add to Dashboard

Choose the visual that fits:

- **List** – See raw 404 traces
- **Time Series** – Trend of 404s per hour
- **Table** – Routes with highest 404s

![SigNoz dashboard creation interface showing query builder with visualization options for 404 monitoring](https://signoz.io/img/blog/2025/06/opentelemetry-nextjs-use-cases-image%201.webp)

Build custom 404 monitoring dashboards: Use SigNoz Query Builder to create reusable views with list, time series, or table visualizations for tracking 404 errors

404s aren’t just noise. They can mean a broken user journeys or missed conversions when a page fails silently.

Monitoring Third-Party APIs in SigNoz

Modern apps are built on top of other people's APIs. Payments, weather data, analytics, social logins - chances are your Next.js app talks to at least a handful of external services.

And when one of those APIs slows down, fails, or changes behavior, your app takes the hit.

That’s where SigNoz’s External API Monitoring comes in. It gives you visibility into how those dependencies perform, without needing custom code or wrappers.

A Sample Setup

To show this in action, let’s take a basic example where a Next.js API route calls a few external services:

// app/api/external/route.ts

export async function GET(request: NextRequest) {
  const results = await Promise.allSettled([
    fetch('https://jsonplaceholder.typicode.com/posts/1'),
    fetch('https://httpbin.org/json'),
    fetch('https://httpbin.org/delay/2'), // Simulates latency
    fetch('https://api.openweathermap.org/data/2.5/weather?q=London'),
  ]);

  return NextResponse.json({ success: true, results });
}

This endpoint hits multiple APIs—including one that’s intentionally slow, and another that returns a 401 (since we’re skipping the API key).

Let’s wire this up so SigNoz can track and visualize every call.

Configuring `instrumentation.ts` for External API Monitoring

Add the following config to your instrumentation.ts:

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

export function register() {
  registerOTel({
    serviceName: 'nextjs-observability-demo',
    instrumentationConfig: {
      fetch: {
        propagateContextUrls: [
          /jsonplaceholder\.typicode\.com/,
          /httpbin\.org/,
          /api\.openweathermap\.org/,
        ],
        ignoreUrls: [],
        resourceNameTemplate: '{http.method} {http.host}{http.target}',
      },
    },
  });
}

What this does:

propagateContextUrls ensures context is passed with the fetch call, so traces remain connected.
ignoreUrls: [] means everything gets traced.
resourceNameTemplate makes spans readable in dashboards.
Behind the scenes, Vercel’s OpenTelemetry wrapper adds the right span metadata (http.url, net.peer.name, etc.), which SigNoz needs to automatically recognize these calls.

Where to See the Magic

Once this is in place and you start making requests, go to the “External API” tab in SigNoz. You’ll see:

SigNoz’s External API Dashboard

External API Overview

Every external domain your app touches
Avg latency, error rates, call volumes
Last seen timestamps

Per-Service Metrics

Call breakdowns by HTTP status codes
Rate and latency over time
Error spike trends

Endpoint-Level Insights

/json on httpbin.org
/weather on openweathermap.org
Full visibility down to the path level

Don’t See Your APIs?

If nothing shows up in the dashboard, check:

You’re hitting the external service in a real request
You restarted the app after editing instrumentation.ts
You’re using @vercel/otel with fetch instrumentation enabled
The domains are included in propagateContextUrls

Still nothing? Open the SigNoz Traces explorer and check if spans are being created. That’s your debugging starting point.

Why This Matters

Third-party APIs are a hidden bottleneck in many apps. You can’t control them—but you can track them:

Spot external slowdowns before they become user-facing
Understand which pages or flows depend on which APIs
Catch breaking changes early (like status code changes or timeouts)
Build alerts for degradation in external service reliability

And you can do it without adding custom wrappers, proxies, or more tooling. It’s just part of your OpenTelemetry flow—with SigNoz doing the visualization heavy lifting.

Exception Monitoring for NextJS with OpenTelemetry

Exceptions are where the real debugging begins. Your logs might tell you something crashed, but tracing why it crashed—and how it impacted the rest of the system—is where SigNoz shines.

By default, OpenTelemetry can auto-capture some exceptions in your Next.js app. But if you want full context, clean groupings, and proper error analysis, you’ll want to take control and manually record exceptions into your spans.

Why Record Exceptions Manually?

Good observability is about context. Manual exception recording lets you:

Attach custom attributes like user ID, error category, or failed operation
Control how errors are grouped (validation vs. auth vs. DB errors)
Link stack traces to actual traces (no jumping between systems)
Make sure failed spans are marked as such—so you’re not staring at 200 OKs that actually blew up halfway

Example: Creating Failing Endpoints

Let’s wire up some fake endpoints to simulate common exceptions in a Next.js API route:

// app/api/errors/route.ts
import { trace, SpanStatusCode } from '@opentelemetry/api';

export async function GET(request: NextRequest) {
  const type = new URL(request.url).searchParams.get('type') || 'generic';
  const span = trace.getActiveSpan();

  try {
    switch (type) {
      case 'validation':
        throw new Error('Invalid user input: email format is incorrect');
      case 'database':
        throw new Error('Database connection failed: timeout');
      case 'network':
        throw new Error('External API call failed: 503 Service Unavailable');
      default:
        throw new Error('Something went wrong');
    }
  } catch (err) {
    if (span) {
      span.recordException(err);
      span.setStatus({ code: SpanStatusCode.ERROR, message: err.message });
    }

    return new Response(
      JSON.stringify({ error: err.message, type }),
      { status: 500 }
    );
  }
}

What this does:

Records the exception inside the current span
Marks the span as an error with a human-readable message
Returns a friendly JSON response for the frontend (or test script)

See it in Action

Let’s hammer the endpoint a few times with different error types:

curl http://localhost:3000/api/errors?type=validation
curl http://localhost:3000/api/errors?type=database
curl http://localhost:3000/api/errors?type=network

Or you can automate it.

Where This Shows Up in SigNoz

Once OpenTelemetry records the exceptions, SigNoz groups them in the Exceptions tab:

Monitor exceptions in SigNoz: Group and analyze errors by service, type, and message to identify recurring issues and root causes

You’ll see:

Groupings by service (nextjs-observability-demo)
Exception types (Error, TypeError, etc.)
Message groupings for recurring issues
Frequency, first seen, last seen

Click into any error, and you get:

Inspect exceptions in SigNoz: Click into any exception to see the full stack trace, span metadata, and trace ID to pinpoint the root cause

Full stack trace
Span metadata (e.g., which database call or API route it happened in)
Trace ID to pivot into the full request flow

Other Common Use Cases

Beyond 404s, third-party APIs, and exceptions, there’s a lot more you can monitor with OpenTelemetry in Next.js. Here’s a quick hit list of useful observability patterns you can add with minimal effort.

Database Query Monitoring

Track slow queries, failures, or just see what your app is hammering the most.

const span = trace.getActiveSpan();
span?.setAttributes({
  'db.system': 'postgresql',
  'db.statement': 'SELECT * FROM users WHERE id = $1',
  'db.execution_time': queryDuration,
});

What to monitor:

Query durations (especially P95/P99)
Connection pool usage
Query failure patterns
Slow queries by route or function

Referrer + User Journey Tracing

Set custom attributes in your spans to see where users come from and how they move through the app:

span?.setAttributes({
  'user.referrer': request.headers.referer,
  'user.agent': request.headers['user-agent'],
  'page.route': '/product/[id]',
  'user.source': 'organic',
});

Use cases:

Funnel drop-off analysis
Attribution (search vs. social vs. direct)
Detect dead-end pages
Campaign effectiveness

Background Job Monitoring

Even async work should leave traces.

const span = tracer.startSpan('emailQueue.process');
span.setAttributes({
  'job.type': 'email',
  'job.queue_depth': queue.length,
});
await processEmails();
span.end();

Useful for:

Failed job tracking
Queue spikes and backlog detection
Job retries and runtime anomalies

Cache Hit/Miss Analysis

Caches help, but only if they’re hitting.

const span = trace.getActiveSpan();
span?.setAttributes({
  'cache.type': 'redis',
  'cache.key': key,
  'cache.hit': !!cached,
});

What this tells you:

Hit ratio by endpoint or operation
TTL expiration patterns
Cache vs. DB response time deltas

Strategy TL;DR

You don’t need a new tool for each metric. Stick to this:

Start a span where logic matters
Tag it with helpful context
Visualize it in SigNoz with dashboards or queries
Add alerts where failure hurts

These are just a few ideas to spark implementation. The key takeaway?

If it matters to your app, wrap it in a span.

Next: Tracking Web Vitals & Widget Performance in Next.js with OpenTelemetry

In the upcoming articles, we'll explore how to actually use SigNoz to track web vitals and widget performance in Next.js.

Monitor NextJS with OpenTelemetry - Complete Tutorial

Yuvraj Singh Jadon — Thu, 26 Jun 2025 07:09:35 +0000

Vercel gives you some observability out of the box for your NextJS application: function logs, perf insights, basic metrics. But as your app grows, the cracks start showing.

Where Vercel Falls Short

No End-to-End Traces: You get function-level timings, but not the full request lifecycle across middleware, DB calls, and third-party APIs.
Locked In: Logs and metrics stay tied to Vercel. Want to move infra or test locally? Too bad.
Zero Custom Instrumentation: Can’t trace auth flow timing, cache performance, or business-critical logic.
No Service Correlation: Can’t trace calls across microservices, queue workers, or even a database hop.
Weak Debug Context: No slow query breakdowns. No cache hit/miss metrics. No idea why stuff is slow.

At this point, you’ll likely explore Jaeger or Datadog. But:

Jaeger: Great for tracing, useless for metrics and logs.
Datadog: Full-featured—but don’t blink, or your bill will triple.

This guide walks through how to instrument a Next.js app using OpenTelemetry, explains Jaeger’s limits, and shows how SigNoz gives you a complete observability pipeline—without breaking the bank.

Why Even Bother Instrumenting Next.js?

You might think: “My app’s just pages and API routes. Why trace anything?”

But Next.js isn’t simple. It just looks simple.

The Hidden Complexity

Next.js runs on multiple layers:

Multiple environments - Node? Edge? Browser? each with its own quirks.
Hybrid rendering: SSR, SSG, ISR—each with different bottlenecks.
Middleware: Runs on every request.
API routes: Mini backends.
Client/server boundaries: Blurred, dynamic, often hard to trace.

Without instrumentation, you're flying blind.

Real Scenarios Where Tracing Saves Hours

The Mysterious Slow Page Load

User says: “The dashboard is slow.”

Without tracing: Stare at server logs. Hope for a clue.

With tracing: 50ms render + 3s wait on a third-party API. Case closed.

The Intermittent 500

API crashes randomly.

Without tracing: Try to reproduce locally. Maybe cry.

With tracing: DB timeout after 12 retries—problem found.

The Deployment Regression

Site feels slower after latest deploy.

Without tracing: Play “spot the difference” in DevTools.

With tracing: New query in Server Component adds 200ms—roll it back or optimize.

Bottom line: Instrumentation turns debugging from guesswork into precision diagnosis.

Setup a Real App

Let’s start with something non-trivial. We'll use the official with-supabase example - it’s got real user auth, DB reads/writes, and third-party API usage. Exactly the kind of app where observability shines.

Create the App

npx create-next-app@latest nextjs-observability-demo --example with-supabase
cd nextjs-observability-demo

Add Environment Config

cp .env.example .env.local

Update .env.local:

NEXT_PUBLIC_SUPABASE_URL=your_supabase_url
NEXT_PUBLIC_SUPABASE_ANON_KEY=your_supabase_anon_key

Test it Locally

npm run dev

Output should look like:

▲ Next.js 15.3.3 (Turbopack)
- Local:        http://localhost:3000
✓ Ready in 855ms
GET /auth/sign-up 200 in 491ms
GET /protected 200 in 665ms

Open http://localhost:3000 and test signup, login, and protected routes.

What This App Gives Us

Auth system: Signup, login, password reset, session flow
Mixed rendering: SSR, SSG, API routes, Client Components
Real DB operations: Auth, user management
External APIs: Supabase
Middleware: You can add some, we’ll instrument it later

This isn’t “hello world.” It’s mimics production-grade complexity—ideal for tracing, metrics, and debugging in the real world.

Note: In this guide, we will be using different ports (3000, 3001) across the sections. Ensure you are using the port as per your system.

Setting Up OpenTelemetry in Next.js

Time to wire up OpenTelemetry into your app. We'll follow the official Next.js guide and use @vercel/otel, which is the preferred path for most setups.

It supports both Node and Edge runtimes, comes with sane defaults, and is maintained by the Next.js team, so no need to reinvent the wheel unless you really want to

1. Install `@vercel/otel`

npm install @vercel/otel

2. Create `instrumentation.ts`

Create a file named instrumentation.ts at the root of your project (or the src folder if you are using it):

import { registerOTel } from '@vercel/otel'

export function register() {
  registerOTel({ serviceName: 'nextjs-observability-demo' })
}

This hook auto-registers tracing across your entire app - including API routes, page rendering, and fetch calls.

The serviceName shows up in your tracing backend (Jaeger, SigNoz, etc.) and helps separate services in a distributed system

Update `next.config.mjs` to include `instrumentationHook`

This step is only needed when using NextJS 14 and below:

// next.config.ts - This config flag is deprecated
const nextConfig = {
  experimental: {
    instrumentationHook: true, // 🔴 Only include when using NextJS 14 or Below
  },
}

Why Use `@vercel/otel`?

Because it just works—with minimal boilerplate.

Benefits:

Auto-detects Node.js vs Edge environments
Pre-configured with smart defaults
Maintained by the Next.js team
Simple to install, easy to maintain

What If You Want Full Control?

Then go manual:

// For advanced users
export async function register() {
  if (process.env.NEXT_RUNTIME === 'nodejs') {
    await import('./instrumentation.node.ts')
  }
}

This gives you full access to the OpenTelemetry Node SDK, but you’ll be responsible for configuring everything—exporters, propagators, batching, etc by creating your own instrumentation.node.ts file as explained in the official documentation

3. Run It and Verify

Start your dev server:

npm run dev

You should see something like:

✓ Compiled instrumentation Node.js in 157ms
✓ Compiled instrumentation Edge in 107ms
✓ Ready in 1235ms

Trigger a trace:

curl http://localhost:3001/protected

What Gets Instrumented Automatically?

Next.js comes with solid OpenTelemetry support out of the box. Once you enable instrumentation, it automatically generates spans for key operations—no manual code required.

According to the official docs, here’s what you get by default:

Span Conventions

All spans follow OpenTelemetry’s semantic conventions and include custom attributes under the next namespace:

Attribute	Meaning
`next.span_type`	Internal operation type
`next.span_name`	Duplicates span name
`next.route`	Matched route (e.g. `/[id]/edit`)
`next.rsc`	Whether it's a React Server Component
`next.page`	Internal identifier for special files

Default Span Types

HTTP Requests

Type: BaseServer.handleRequest

What you get: method, route, status, total duration

Route Rendering

Type: AppRender.getBodyResult

Tells you: how long server-side rendering took

API Route Execution

Type: AppRouteRouteHandlers.runHandler

Covers: custom handlers in app/api/

Fetch Requests

Type: AppRender.fetch

Covers: any fetch() used during rendering

Tip: disable with NEXT_OTEL_FETCH_DISABLED=1

Metadata Generation

Type: ResolveMetadata.generateMetadata

Tracks: SEO-related dynamic metadata costs

Component Loading

Types:

clientComponentLoading
findPageComponents
getLayoutOrPageModule

Insight: Which modules are loaded, how long it takes

Server Response Start

Type: NextNodeServer.startResponse

Why it matters: measures TTFB (Time to First Byte)

Pages Router Support (legacy)

Still using getServerSideProps or getStaticProps? Next.js instruments those too.

Why This Matters

Without writing a single line of tracing code, you now get:

Request and route-level performance
Server rendering + metadata overhead
External API call timings
Component/module load times
TTFB and response latency

It’s a solid start—but you still need somewhere better than Jaeger to actually work with these traces at scale.

Debugging with Env Variables

Need to see more detail?

export NEXT_OTEL_VERBOSE=1

You’ll get verbose span logs in the terminal—useful when debugging instrumentation issues.

Next: These traces are only local for now. Let’s plug in a collector and pipe them to something visual - starting with Jaeger.

Running a Collector Locally and Testing Traces

You’ve got instrumentation. Now it’s time to capture those traces with an OpenTelemetry Collector and ship them to something visual like Jaeger.

We’ll use Vercel’s dev setup which comes pre-bundled with:

OpenTelemetry Collector
Jaeger
Zipkin
Prometheus
Pre-wired Docker Compose config

1. Clone and Start the Collector Stack

git clone https://github.com/vercel/opentelemetry-collector-dev-setup.git
cd opentelemetry-collector-dev-setup

2. Update the Collector Config (Important)

The default config may be outdated. Replace otel-collector-config.yaml with the following updated version:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
    const_labels:
      label1: value1
  debug:
    verbosity: basic
  zipkin:
    endpoint: "http://zipkin-all-in-one:9411/api/v2/spans"
    format: proto
  otlp/jaeger:
    endpoint: jaeger-all-in-one:14250
    tls:
      insecure: true

processors:
  batch:

extensions:
  health_check:
  pprof:
    endpoint: :1888
  zpages:
    endpoint: :55679

service:
  extensions: [pprof, zpages, health_check]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, zipkin, otlp/jaeger]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, prometheus]

Replaces deprecated exporters
Adds support for latest collector version
Sends traces to both Jaeger and Zipkin

3. Start the Collector Stack

export OTELCOL_IMG=otel/opentelemetry-collector-contrib:latest
export OTELCOL_ARGS=""
docker compose up -d

4. Confirm It’s Running

docker compose ps

You should see:

OpenTelemetry Collector (ports 4317, 4318)
Jaeger UI: http://localhost:16686
Zipkin UI: http://localhost:9411
Prometheus: http://localhost:9090

Configure Next.js to Export Traces

Add this to your .env.local:

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4318/v1/traces
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf
OTEL_LOG_LEVEL=debug
NEXT_OTEL_VERBOSE=1

Then restart:

npm run dev

You should see logs like:

✓ Compiled instrumentation Node.js in 157ms
✓ Compiled instrumentation Edge in 107ms
@vercel/otel/otlp: onSuccess 200 OK

Test It

Send a few requests:

curl http://localhost:3000
curl http://localhost:3000/protected
curl http://localhost:3000/auth/login

Check collector logs:

docker compose logs otel-collector --tail=10

Look for:

info  Traces  {"resource spans": 2, "spans": 23}

View Traces in Jaeger

Go to http://localhost:16686
Select nextjs-observability-demo in the dropdown
Click Find Traces
Click any trace to view its full request flow

Troubleshooting

Problem	Likely Cause	Fix
Collector keeps restarting	Bad YAML config	Run `docker compose logs otel-collector` and fix `otel-collector-config.yaml`
`onError` in Next.js console	Collector unreachable	Use `0.0.0.0:4318`, not `localhost:4318` in collector config
No traces in Jaeger	Missing env vars	Check `.env.local` for correct `OTEL_EXPORTER_OTLP_...` values
Docker doesn’t start	Docker Desktop not running	`open -a Docker` (macOS) or start it manually

Now that traces are flowing and visualized, we’ll look at how to interpret them—what each span tells you, and how to drill into performance issues in your Next.js stack using real trace data.

Useful Jaeger Features

Trace comparison — spot regressions
Dependency map — visualize service call flow
Direct links — share traces with teammates
Export support — for deeper analysis

But Here's the Catch

Jaeger is great—until it isn’t.

What It Does Well	❌ What It Lacks
Visualize request flow	No dashboards
Drill into trace timings	No metrics or alerts
Debug route/API latency	No log correlation
Understand call dependencies	No business KPI visibility

We need more than just a trace viewer. In production, you want:

Metrics + alerting
Logs + trace correlation
Dashboards for teams
Advanced filters and KPIs

Next up: how to plug SigNoz into your setup to get full-stack observability—without leaving OpenTelemetry.

Let’s go.

Sending Data to SigNoz: Production-Ready Observability

Jaeger is great for local debugging—but when you move to production, you need more: metrics, logs, alerting, dashboards. That’s where SigNoz comes in.

Why SigNoz Over Jaeger?

Capability	Jaeger	SigNoz
Distributed tracing	✅	✅
Metrics dashboard	❌	✅
Log aggregation + correlation	❌	✅
Real-time alerting	❌	✅
Long-term storage	❌	✅
Custom dashboards / KPIs	❌	✅

You get everything Jaeger does, plus actual production monitoring.

Updating the Collector to Send Data to SigNoz

Let's update the existing otel-collector setup to export traces and metrics to SigNoz Cloud - while keeping Jaeger for local use.

Step 1: Add SigNoz Config

Update your .env file in opentelemetry-collector-dev-setup:

SIGNOZ_ENDPOINT=ingest.us.signoz.cloud:443       # change 'us' if needed
SIGNOZ_INGESTION_KEY=your-signoz-key-here

Note: Create an account on SigNoz Cloud and get the ingestion key and region from the settings page.

Step 2: Modify `otel-collector-config.yaml`

Add SigNoz to the list of exporters:

exporters:
  otlp/signoz:
    endpoint: "${SIGNOZ_ENDPOINT}"
    headers:
      signoz-access-token: "${SIGNOZ_INGESTION_KEY}"
    tls:
      insecure: false

service:
  pipelines:
    traces:
      exporters: [debug, zipkin, otlp/jaeger, otlp/signoz]
    metrics:
      exporters: [debug, prometheus, otlp/signoz]

Step 3: Update `docker-compose.yaml`

Pass SigNoz credentials as environment vars:

environment:
  - SIGNOZ_ENDPOINT=${SIGNOZ_ENDPOINT}
  - SIGNOZ_INGESTION_KEY=${SIGNOZ_INGESTION_KEY}

Step 4: Restart Collector

docker compose down
docker compose up -d

Check logs to verify export:

docker compose logs otel-collector | grep signoz

You should see:

Successfully exported trace data to SigNoz

Generate Traffic to Test

curl http://localhost:3001/
curl http://localhost:3001/protected
curl http://localhost:3001/auth/login
curl http://localhost:3001/nonexistent

View in SigNoz

Head to your SigNoz dashboard
Check Services – you should see nextjs-observability-demo
Go to Traces and Select one to visualize it

Alternatively: Direct Export to SigNoz

You can send traces directly from the app (skip collector), but it’s not ideal for production:

import { registerOTel, OTLPHttpJsonTraceExporter } from '@vercel/otel'

export function register() {
  registerOTel({
    serviceName: 'nextjs-observability-demo',
    traceExporter: new OTLPHttpJsonTraceExporter({
      url: 'https://ingest.us.signoz.cloud/v1/traces',
      headers: {
        'signoz-access-token': process.env.SIGNOZ_INGESTION_KEY || ''
      }
    })
  })
}

Why Stick with the Collector?

Works with multiple backends (SigNoz + Jaeger)
Better reliability and batching
Local debugging + remote monitoring

Troubleshooting Common Issues

Problem	Fix
❌ No data in SigNoz	Check collector logs for trace export failures
❌ Wrong region	Update `SIGNOZ_ENDPOINT` to match your region
❌ No environment variables	Verify `.env` is loaded correctly
❌ Missing ingestion key	Copy it from SigNoz Cloud settings

Exploring the Out-of-the-Box APM in SigNoz

Now that your Next.js app is streaming traces to SigNoz, you’ll notice something right away: this isn’t just a Jaeger clone with better UI.

SigNoz ships with full-blown APM (Application Performance Monitoring) capabilities out of the box - without you having to write a single custom metric.

That means no YAML spelunking, no manual dashboard setups—just useful insights, right there, from the moment traces start flowing.

What Makes SigNoz APM Actually Useful?

Most APMs either overload you with graphs or bury useful data behind paywalls. SigNoz hits the sweet spot: high-fidelity insights derived directly from OpenTelemetry traces, backed by high performing columnar database for blazing-fast queries and dashboards that update in near real-time.

You get:

Latency breakdowns (P50, P90, P99)
Request rate, error rate, Apdex
Database and external API performance
Auto-discovered endpoints

No extra config. No magic wrappers. Just signal.

From Spikes to Spans in 3 Clicks

Let’s say you see a latency spike around 2:45 PM. Instead of guessing, you:

Click the spike on the chart
SigNoz filters down to relevant traces
You spot a rogue DB query eating 2.1 seconds

No guesswork. No slow log tailing. Just trace → span → fix.

"spans": [
  { "name": "GET /auth/login", "duration": "2.3s" },
  { "name": "supabase_auth", "duration": "150ms" },
  { "name": "db.query.getUser", "duration": "2.1s" }  // 💥
]

External API + DB Visibility, No Extra Setup

If your app calls Supabase, Stripe, or any third-party API, you’ll see how long those calls take, how often they fail, and where they sit in your request timeline.

Same goes for your database queries: SigNoz shows frequency, duration, and highlights outliers as slow queries—without needing a separate DB monitoring solution.

Next: Visualizing + Building Dashboards in SigNoz

In the upcoming articles, we'll explore how to actually use SigNoz to:

Find slow endpoints
Track API performance
Alert on spikes or failures
Create dashboards for your team

Let’s observe!

Docker Compose Commands: Understanding 'up -d' vs 'up --build'

Yuvraj Singh Jadon — Thu, 15 Aug 2024 18:04:07 +0000

As developers, we often work with Docker to containerize our applications. Docker Compose is a tool that helps us define and manage multi-container Docker applications. In this post, we'll explore two common Docker Compose commands and their use cases: docker-compose up -d and docker-compose up --build.

The Basics: What These Commands Do

Before we dive into the details, let's quickly outline what these commands do:

docker-compose up -d: Starts containers in detached mode
docker-compose up --build: Rebuilds images before starting containers

Now, let's break down each command and explore when to use them.

docker-compose up -d: Quick Starts in the Background

The -d flag in docker-compose up -d stands for "detached" mode. Here's what you need to know:

Background Operation: This command starts your containers in the background, freeing up your terminal for other tasks.
Uses Existing Images: It uses pre-built images if they're available locally.
Pulls if Necessary: If an image isn't found locally, it pulls from the registry.
No Rebuilding: It doesn't rebuild images, even if their Dockerfiles have changed.

When to Use It:

When you want to quickly start your services without any changes
For production environments where images are pre-built
When you need to run services in the background

docker-compose up --build: Ensuring Fresh Builds

The --build flag forces Docker Compose to rebuild your images. Key points:

Forced Rebuild: It rebuilds all images defined with a build context in your docker-compose.yml file.
Foreground Operation: By default, this runs in the foreground (attached mode).
Incorporates Changes: Ensures your containers use the latest version of your code and Dockerfile instructions.

When to Use It:

After making changes to your Dockerfile
When you've updated your application code
In development environments where you frequently iterate on your containers

Combining the Commands

You're not limited to using these flags separately. You can combine them for different effects:

docker-compose up -d --build

This command rebuilds your images and then starts the containers in detached mode. It's useful when you want to ensure you're running the latest version of your services in the background.

Best Practices

Development Workflows: Use --build frequently in development to ensure you're testing the latest changes.
CI/CD Pipelines: Incorporate --build in your continuous integration processes to catch build issues early.
Production Deployments: Use -d for production deployments where images are pre-built and validated.
Documentation: Clearly document in your project README which command developers should use and when.

Conclusion

Understanding the nuances between docker-compose up -d and docker-compose up --build can significantly improve your Docker workflow. By choosing the right command for your situation, you can save time, ensure consistency, and avoid potential issues caused by outdated images.

Remember, the key is to use -d when you need quick, background starts of existing services, and --build when you need to incorporate recent changes into your containers.

What's your experience with these Docker Compose commands? Do you have any tips or tricks to share? Let us know in the comments below!

How to Fix "Docker: No Space Left on Device" Error

Yuvraj Singh Jadon — Tue, 30 Jul 2024 16:42:36 +0000

The "Docker: No Space Left on Device" error is a common roadblock for developers using Docker containers. This error occurs when Docker runs out of available disk space, halting your containerization efforts. Let's dive into the causes of this error and explore effective solutions to get your Docker environment back on track.

Understanding the "No Space Left on Device" Error in Docker

The "No Space Left on Device" error in Docker indicates that the filesystem where Docker stores its data has run out of free space. Docker uses disk space to store images, containers, volumes, and other data in the /var/lib/docker directory by default. When this directory fills up, Docker operations—such as pulling images, creating containers, or writing to volumes—fail.

Docker's space usage can quickly balloon due to:

Accumulated unused images and containers
Orphaned volumes
Build cache from image creation
Logs and other operational data

This error significantly impacts Docker operations, preventing you from creating new containers, pulling images, or even running existing containers in some cases.

Quick Fix: Freeing Up Space in Docker

To quickly resolve the "No Space Left on Device" error, use these commands to clean up Docker resources:

Remove unused Docker objects:



docker system prune

This command removes all stopped containers, unused networks, dangling images, and build cache.

Remove unused images:



docker image prune

Clean up volumes:



docker volume prune

After running these commands, restart the Docker service:



sudo systemctl restart docker

Monitoring Docker Disk Usage

To prevent future space issues, regularly monitor your Docker disk usage:

Check overall disk space:



df -h

View Docker-specific usage:



docker system df

Set up alerts for low disk space and implement a regular maintenance schedule to keep your Docker environment healthy.

Root Causes of Docker Space Issues

Understanding the root causes helps in long-term prevention:

Accumulation of unused resources: Over time, unused images, containers, and volumes consume significant space.
Large or numerous Docker volumes: Data-heavy applications can quickly fill up volumes.
Default storage location limitations: The partition containing /var/lib/docker may be too small.
System-wide disk space shortage: Your entire system might be running low on space, affecting Docker operations.

Advanced Solutions for Docker Space Management

For more robust space management:

Configure a different storage driver: Some drivers are more space-efficient. Research options like overlay2 or devicemapper.
Move Docker's data directory: Relocate to a larger partition:



   # Stop Docker
   sudo systemctl stop docker

   # Move the data
   sudo mv /var/lib/docker /path/to/new/location

   # Update Docker's configuration
   sudo nano /etc/docker/daemon.json
   # Add: {"data-root": "/path/to/new/location"}

   # Restart Docker
   sudo systemctl start docker

Implement image lifecycle policies: Automatically remove old or unused images based on age or usage patterns.
Use Docker Compose: Better manage resources across multiple containers and services.

Optimizing Dockerfiles for Space Efficiency

Efficient Dockerfiles lead to smaller images and reduced space usage:

Use multi-stage builds: Separate build-time dependencies from runtime dependencies.
Minimize layer size:
- Combine RUN commands
- Clean up in the same layer where files are added
Leverage .dockerignore: Exclude unnecessary files from the build context.
Choose appropriate base images: Use slim or alpine versions when possible.

Preventing Future "No Space Left" Errors

Implement these strategies to avoid recurring space issues:

Set up regular cleanup cron jobs:



   0 0 * * * docker system prune -af --volumes

Use disk space monitoring tools: Consider tools like Prometheus with node_exporter for comprehensive monitoring.
Educate team members: Share Docker best practices across your development team.
Consider container orchestration: Solutions like Kubernetes can help with resource allocation and management.

Key Takeaways

The "No Space Left on Device" error often stems from Docker's storage management.
Regular cleanup and monitoring are crucial for preventing space issues.
Advanced solutions involve reconfiguring Docker's storage setup.
Optimizing Dockerfiles and implementing best practices can significantly reduce space usage.

FAQs

How often should I run Docker cleanup commands?

Run cleanup commands weekly or bi-weekly, depending on your Docker usage. For high-traffic environments, daily cleanups might be necessary.

Can I move Docker's data directory without losing my containers and images?

Yes, if you follow the correct procedure of stopping Docker, moving the data, updating the configuration, and restarting Docker.

What's the difference between docker system prune and docker image prune?

docker system prune removes unused data including stopped containers, unused networks, dangling images, and build cache. docker image prune only removes dangling images.

How do I increase Docker's default storage limit on Windows?

On Windows, you can increase Docker's storage limit through the Docker Desktop settings. Navigate to Settings > Resources > Advanced and adjust the "Disk image size" slider.

Resources

Enabling Hot Reloading for Next.js in Docker

Yuvraj Singh Jadon — Fri, 19 Jul 2024 16:56:15 +0000

As developers, we're always looking for ways to streamline our workflow and boost productivity. One of the most powerful tools in our arsenal is hot reloading - the ability to see our changes reflected in real-time without manually restarting our application. But what happens when we throw Docker into the mix? In this post, we'll walk through the process of enabling hot reloading for a Next.js application running inside a Docker container.

Why Docker?

Docker has become an essential tool in modern web development. It allows us to create consistent development environments, simplify deployment processes, and ensure that our application runs the same way across different machines. However, running a Next.js application in Docker can sometimes feel like we're sacrificing the rapid feedback loop we're used to in local development.

The Challenge

By default, when you run a Next.js application in a Docker container, changes to your local files aren't automatically reflected in the running application. This is because the container is isolated from your local file system. To bridge this gap and enable hot reloading, we need to make some specific configurations.

The Solution

To enable hot reloading for Next.js in Docker, we need to make changes to three key files: the Dockerfile, the Docker Compose file, and the Next.js configuration file. Let's break down each of these changes.

1. Updating the Dockerfile

First, we need to modify our Dockerfile to run Next.js in development mode:

FROM node:18-alpine

WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci

COPY . .
COPY next.config.mjs ./next.config.mjs

EXPOSE 3000

CMD ["npm", "run", "dev"]

The key changes here are:

We're not running npm run build anymore.
We've changed the CMD to npm run dev to start Next.js in development mode.

2. Modifying the Docker Compose File

Next, we need to update our Docker Compose file to enable volume mounting:

version: '3'
services:
  # ... other services ...

  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile
    ports:
      - "3000:3000"
    environment:
      - BACKEND_URL=http://backend:8000
    volumes:
      - ./frontend:/app
      - /app/node_modules
    depends_on:
      - backend

The crucial additions here are:

We've added volumes to mount the local frontend directory to /app in the container.
We've included a volume for node_modules to prevent it from being overwritten by the local mount.

3. Adjusting the Next.js Configuration

Finally, we need to modify our Next.js configuration to enable file watching in Docker:

/** @type {import('next').NextConfig} */
const nextConfig = {
  // ... other configurations ...

  webpackDevMiddleware: config => {
    config.watchOptions = {
      poll: 1000,
      aggregateTimeout: 300,
    }
    return config
  },
}

export default nextConfig;

The added webpackDevMiddleware configuration enables polling for file changes, which is necessary for hot reloading to work in Docker.

Putting It All Together

With these changes in place, you can now run your Docker setup with hot reloading enabled. Use the following command to start your containers:

docker-compose up --build

Now, when you make changes to your Next.js application code, you should see those changes reflected almost immediately in your browser, just as if you were running Next.js directly on your host machine.

Conclusion

Enabling hot reloading for Next.js in Docker might seem like a small change, but it can significantly improve your development experience. It combines the consistency and isolation of Docker with the rapid feedback loop we've come to expect in modern web development.

Remember, the first time you run this setup, it might take a while to install all the dependencies. Subsequent runs should be much faster.

By following this guide, you've supercharged your Next.js development environment in Docker. Happy coding!

Is it Possible to Use Grafana Without Prometheus?

Yuvraj Singh Jadon — Mon, 10 Jun 2024 17:50:03 +0000

Grafana is widely known for its powerful data visualization capabilities, often used in conjunction with Prometheus for monitoring and metrics collection. However, many users wonder if it is possible to use Grafana without Prometheus. The answer is yes! Grafana's versatility allows it to support a wide range of data sources, making it a flexible tool for various use cases.

In this article, we will explore the possibility and benefits of using Grafana without Prometheus, and provide a step-by-step guide on setting up Grafana with MySQL as the data source.

Understanding Grafana

Grafana is an open-source platform for monitoring and observability that excels in visualizing data from a variety of sources. It offers a highly customizable dashboarding experience, allowing users to create, explore, and share dashboards that display data from different systems.

Common Data Sources Supported by Grafana

Grafana supports numerous data sources out-of-the-box, including:

MySQL
InfluxDB
Elasticsearch
PostgreSQL
Prometheus
Graphite
Cloudwatch
Azure Monitor

These integrations enable users to visualize data from various databases and services, making Grafana a versatile tool for many applications.

Benefits of Using Grafana Without Prometheus

Flexibility in Data Source Selection: Grafana's support for multiple data sources means you can choose the one that best fits your needs, whether it's a SQL database, a time-series database, or a cloud service.
Simplified Architecture: By using Grafana with a data source like MySQL, you can simplify your monitoring architecture, which might be beneficial for specific use cases.
Cost Savings: Depending on your requirements, using a single data source can reduce complexity and costs associated with managing multiple monitoring tools.

Practical Example: Setting Up Grafana with MySQL

Let's dive into a practical example of setting up Grafana with MySQL as the data source.

Step 1: Install Grafana

Download and install Grafana from the official website. Follow the installation instructions for your operating system.

Step 2: Set Up MySQL and Create a Sample Database

Install MySQL on your system if it's not already installed.
Create a sample database and table for storing your data:

CREATE DATABASE sample_db;
USE sample_db;
CREATE TABLE metrics (
  id INT AUTO_INCREMENT PRIMARY KEY,
  metric_name VARCHAR(255) NOT NULL,
  value FLOAT NOT NULL,
  timestamp DATETIME DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO metrics (metric_name, value) VALUES ('cpu_usage', 23.5), ('memory_usage', 55.1);

Step 3: Configure Grafana to Connect to MySQL

Open Grafana in your browser (default URL is http://localhost:3000).
Log in with the default credentials (admin/admin, you an read detailed guide to login here).

Navigate to Configuration > Data Sources and click Add data source.

Select MySQL from the list of data sources.
Enter the necessary connection details (e.g., host, database name, user, and password) and click Save & Test to verify the connection.
- Host URL will be likely localhost:3306
- Database Name: sample_db
- Add your database username and password in the authentication.

Step 4: Create a Simple Dashboard Using MySQL Data

Navigate to Create > Dashboard and click Add new panel.

Select your MySQL data source.
Write a simple SQL query to fetch data from your sample table:

SELECT
  UNIX_TIMESTAMP(timestamp) as time_sec,
  value as value,
  metric_name as metric
FROM metrics

Customize the visualization as needed and save your dashboard.

Real-World Use Cases

Many organizations leverage Grafana with data sources other than Prometheus to meet specific needs:

Web Application Monitoring: Using MySQL or PostgreSQL to track user interactions and performance metrics.
Business Analytics: Visualizing data from SQL databases to monitor KPIs and other business metrics.
IoT Data Visualization: Utilizing InfluxDB to collect and visualize sensor data.

Conclusion

Grafana is a versatile tool that can be used with a variety of data sources beyond Prometheus. This flexibility allows users to tailor their monitoring and visualization setup to their specific needs, simplifying architecture and potentially reducing costs.

For a deeper comparison between Prometheus and Grafana, you can check out this comprehensive article.

Have you used Grafana with a data source other than Prometheus? Share your experiences and questions in the comments below.

What Happens When You Run a Computer Program?

Yuvraj Singh Jadon — Thu, 31 Dec 2020 13:54:11 +0000

Introduction

How do you run a computer program?

You may double click the icon.

You may run it through a terminal if you happened to be a programmer.

In both cases the Operating System launches the program after performing some operations and hand it to the CPU to execute it.

Let us look at the journey of a program from sitting in the hard disk to being executed by the processor.

What is a Computer Program?

A computer program is an executable version of the source file written by a programmer that contains a list of instructions.

A computer program is stored on a hard disk until requested to be executed by a user, therefore it is known as a passive entity.

The moment you request the execution of a computer program, The Operating System(OS) comes into play. It is the job of OS to transform the passive program into an active entity that can be run by a processor.

Process: Transformation of a Program

The OS transforms the passive program into an active entity by:

Copying all the instructions into random-access memory(RAM), this is known as **loading **the program.
Allocating computer resources such as:
- Call Stack: Memory to store function parameters, local variables, and return address.
- Data Sections: Memory to store global variables.
- Heap: Memory that is dynamically allocated during run time.
- The current Activity of the process is represented by the processor's registers' values such as Program Counter that stores the address of the next instruction to be executed.

This active form of a computer program is known as a process.

One thing to note is - if you run the same program multiple times, for instance, you open chrome twice you will be creating two different processes from one program. Although both processes will contain the same instructions in text segment, their data may be different.

Diagrammatic Representation of a process in memory:

From Memory to CPU

Now our computer program has reached the memory and is waiting for its turn to be executed by CPU.

Once, Its turn arrives, the OS directs the CPU to begin running at the first instruction in the process's text segment in memory.

Then Its CPU's job to execute our program instruction by instruction.

These instructions are in machine code(binary) and are extremely simple like adding two numbers or deciding if a number is equal to zero or not.

Saying that a CPU can execute 2 billion operations per second means that CPU can execute 2 billion lines of machine code per second.

CPU runs this instruction using a fetch/execute cycle:

Fetch instruction from memory.
Decode the instruction.

We need to decode the instruction because each binary sequence in instruction corresponds to a particular operation depending on the CPU design.

For Example: In 0 001 0000 0010 0100 the second sequence of 3 bit 001 may mean to add the number at address (referred by the last three sequences of 4 bits) to the value already stored in instructions.

Fetch Operand if necessary, this means that if there is another value required to operate fetch it from its address in memory, in the previous example our operand address was 0000 0010 0100.
Execute - Finally, execute the operation by performing the required logic in the CPU.

Termination

A program may be terminated because of the following reason:

Program Exists Normally.
Program Stuck/Infinite Loop - Abnormal Exit.
Running out of memory.
Memory Access Error - When the program tries to access the memory of another program the OS kills it.

After termination, the OS will reclaim the memory provided to the program to run.

Takeaways

A computer program is a passive entity sitting in the hard disk.
A process is an active entity in RAM that stores the program code and has associated resources.
CPU runs the instructions in the process text segment line by line.
The OS keeps everything organized.

References

Operating System Concepts - Book by Avi Silberschatz
Stanford cs101

Hope you found this article helpful and interesting, if you have any feedback please comment down below!

Do You Understand the Internet?

Yuvraj Singh Jadon — Thu, 31 Dec 2020 13:51:58 +0000

We use the internet on a daily basis. Our phones, laptops, computers, all connected to the internet. But how the internet works?

In this blog, we are going to find the answers to these questions -

What is the internet?
What is a network?
What are IP addresses?
What happens when you search on Google?
What are the rules of the Internet?
Where is Google’s server located?
What devices hold the internet together?

Fasten your seat belts for a ride over routers...

What is the Internet?

The Internet is the global system of interconnected computer networks that uses the Internet protocol suite (TCP/IP) to communicate between networks and devices.
It is a network of networks.
- Several collections of computers together make the internet.
It is used for sharing various resources such as web pages, emails, file sharing.
To understand the internet, we first need to understand what a network is?

What is a Network?

A network is a collection of computers, servers, mainframes, network devices, peripherals, or other devices connected to one another to allow the sharing of data.
Consider an example of a network: your home network -
- You have a router in your home.
- This router connects to the Internet.
- You pay your isp for this connection - Airtel, Jio, etc.
- Other devices connect to the router with cables or wifi.

What are IP addresses?

Every device on the internet has an IP address that allows other computers to talk to it.
It is of the form: #.#.#.#
- Four numbers separated by dots of the values 0-255.
- This version of IP addresses is called IPv4.
Like postal addresses, they uniquely identify computers on the internet.
ISPs assign an IP address to your router.
- Earlier, it is used to be physically configured.
- Today, it is assigned automatically using a DHCP Server that lives in ISP.
But, if your ISP only assigns one address to the router, how are you able to connect multiple devices to the internet?
- That’s because your router assigns private IP addresses to the devices.
- This private IP address is free and reserved for this use only.
- These are the private IP address ranges:
- 10.0.0.0 – 10.255.255.255
- 172.16.0.0 – 172.31.255.255
- 192.168.0.0 – 192.168.255.255

What Happens When You Search on Google?

With an IP address assigned to us, we are officially on the internet. Now we can communicate with other devices on the internet. So, let's try to talk with Google Servers.

We will open software called a browser (like chrome) and enter a query to search with Google’s search engine. The browser will do the job of converting our normal query to a proper HTTP request to google.

Suppose we searched for cats, our request will look like:

GET /search?q=cats HTTP/1.1

Computers communicate by sending packets, which are like virtual envelopes sent between computers. (Ultimately still 0s and 1s).

So we will place this request inside an envelope (as an analogy). On the envelope, we need to mention the destination and source address.

We know our IP address.
But we don’t know the IP address of Google…?

But we do know the domain name of Google - www.google.com. To convert a domain name to its corresponding IP address, we use a Domain Name System(DNS) server.

A request will be sent to the ISP’s DNS server for Google’s IP address.

If the ISP’s DNS server doesn’t know a website’s IP address, it has been configured to ask another DNS server.
There exist root servers that know where to look to for an IP address if it exists.

We have assumed our IP to be 1.2.3.4 and google’s 5.6.7.8. After sending the request off, we’ll get a response some milliseconds later. The result will be sent back in one or more packets.

If the result is too large for a single envelope, sending it in one packet could take up the internet traffic.
To solve this, Google will divide the result into smaller fragments (say 4).
- Put the fragments into different envelopes.
- Write information on the envelopes:
- Return address: Google IP address
- Delivery address: Our IP address.
- List the number of packets on each envelope (1 of 4, 2 of 4, …).

What if one of the packets goes missing?

We can logically infer which packet is missing based on the ones received. For this, we will need another protocol called TCP (Transmission control protocol) which ensures packets can get to their destination.

It supports sequence numbers that help data get to its destination.

When missing a packet, a computer can make a request for the missing packet.
The computer will put packets together to get a whole file.

This protocol also includes conventions for requesting services (port identifiers).

To make sure Google knows we’re requesting a web page and not an email or other service.

If 5.6.7.8 is Google’s IP address, 5.6.7.8:80 (port 80) specifies that we want a webpage.

80 means HTTP (Hypertext transfer protocol).
- The language web servers speak.
Emails use port 25 - SMTP.
Secure connection use 443 - HTTPS.

Therefore, on the envelope we previously saw, we must have mentioned the port as well before sending it.

What are the Rules of the Internet?

We have used the term protocols multiple times till now. Protocols are just sets of rules.

Humans use these all the time, such as the protocol for meeting people: handshakes. (pre-corona times!!)

Internet uses these protocols to standardize all communication.

HTTP, FTP, TCP/IP, etc.

There is one more protocol called UDP (User datagram protocol) that can be used instead of TCP.

It doesn’t guarantee delivery.
Used for video conferencing.
- Packets can be dropped for the sake of keeping the conversation flowing.
Used anytime you want to keep data coming without waiting for a buffer to fill.

Where is Google's Server Located?

When we sent our envelope, our laptop didn’t know where is the Google’s server located. We knew the IP address of the server but we didn’t have a map to decide which direction to go to and we certainly cannot use Google maps 😅.

This again is the job of routers:

Routers have a big table with IP addresses and where data should be routed to get to that destination. Often, the data is routed to the next router.

The router’s purpose is to send data in the direction of a destination. The next router will send it to another until it reaches a destination.

The routing decisions are made using certain routing algorithms such as Dijkstra’s shortest path algorithm or distance vector routing algorithm.

We can use a program called traceroute that sends packets to each router on a path to a destination, reporting the time it takes to reach that router:

It took us 13 jumps to get to google finding our way through routers.
Also, Now we can see Google’s IP address is not 5.6.7.8 but 142.250.67.68.
It took us only 42.130 ms to get to Google!!!

What Devices Hold the Internet Together?

Undersea Cables: A submarine communications cable is a cable laid on the sea bed between land-based stations to carry telecommunication signals across stretches of ocean and sea.

Check out this video to see the network of undersea cables around the world:

%[https://youtu.be/IlAJJI-qG2k]

Cable Modems: A cable modem is a hardware device that allows your computer to communicate with an Internet service provider over a landline connection. It converts an analog signal to a digital signal for the purpose of granting access to broadband Internet.
- Coaxial cable to plug into the wall.
- Phone jacks (RJ11) as many services are bundled together these days.
- Four jacks for ethernet cables (RJ45).
- Devices can plug into these for internet connectivity.

Switch: A network switch is networking hardware that connects devices on a computer network by using packet switching to receive and forward data to the destination device.

Router: A router is a networking device that forwards data packets between computer networks. Routers perform the traffic directing functions on the Internet. Home routers can have wifi, firewall, and switching capabilities.

Thanks For Reading 😊

If you found this article helpful, please like and share!
Feedbacks are welcome in the comments.

Modern C++ Features

Yuvraj Singh Jadon — Thu, 31 Dec 2020 13:49:55 +0000

C++ is not just C with classes, it is a very powerful language that comes with many features that are provided by languages like Python and JavaScript.

In this article, I have shown a few features that you may know from Python or JavaScript that you can use in C++ too!!

This article is for people with a basic understanding of C++

Templates
Auto
Variable Argument Function
Standard Template Library
Range Based For Loop
Lambda Expressions

Templates

Suppose you want to write a function with the same operations on different data types.

This is straightforward in Python as the same variable can point to different objects of different types. So you can reuse the same code for all types.

Now, in C++ one solution is to overload the function with different types but that will require you to write a lot of code that basically does the same thing. Here comes the use of templates.

Instead of writing functions with different types yourself, you can have the compiler generate them for you by using templates. The compiler knows which functions to generate based on the parameter provided.

Let's see an example:

A template function for getting the maximum of two values, the value can be of any data type.

  #include <iostream>

  template <typename type>  // Creating a template
  type max(type first, type second)
  {
      return first > second ? first : second;
  }

  int main()
  {
      std::cout << max<int>(2, 3) << "\n";          // 3
      std::cout << max(3.4f, 4.2f) << "\n"; // 4.2
      std::cout << max('C', 'S') << "\n";       // S

      return 0;
  }

The first call will tell the compiler to create a function with type replaced by int
Similarly, the second and third calls will create a function with type replaced by float and char.
In the first call we have explicitly told the compiler that type is int with <type> notation.

You can similarly create templates for classes.

To learn more about templates in C++, checkout this article

Auto

You can deduce the type of a variable at compile time using the auto keyword.

This is useful when a variable has a complicated type.

Here is an example of auto

#include <iostream>
#include <string>

int main()
{
    auto an_int = 50;
    auto a_float = 10.5f;
    auto a_double = 100.12;
    auto a_char = 'S';
    auto a_string = "String";

    std::cout << an_int << "\n";        // 50
    std::cout << a_float << "\n";       // 10.5
    std::cout << a_double << "\n";      // 100.12
    std::cout << a_char << "\n";        // S
    std::cout << a_string << "\n";      // String

    return 0;
}

To learn more about auto in C++, read this article

Variable Argument Functions

If you know Python then you must have used * for creating a function with a variable number of arguments.

You can do the same in C++ using Ellipsis and variadic templates.

Let us understand this with an example -

#include <iostream>

template <typename type>
int sum(type n)
{
    return n;
}

template <typename first, typename... types>    // Packing Arguments
int sum(first n, types ...args)     // Expanding Arguments
{
    return n + sum(args...);    
}

int main()
{
    int sum3 = sum(1,2,3);
    std::cout << sum3 << "\n";      // 6
    int sum5 = sum(1,2,3,4,5);
    std::cout << sum5 << "\n";      // 15

    return 0;
}

Here, ... after typename is packing all the arguments passed when calling into types, and then we are unpacking them again with ... before args.

Then we have used recursion to call a function with arguments one less than the original.

Similarly you can create a print function that takes any number of arguments -

#include <iostream>

template <typename First>
void print(First first)
{
    std::cout << first << "\n";
}

template <typename First, typename ... Types>
void print(First first, Types ... args)
{
    std::cout << first << " ";
    print(args...);
}

int main()
{
    print("One", "Two");
    print("One", "Two", "Three", "Four");

    return 0;
}

Learn more about ellipsis and variadic templates in this article

Standard Template Library

In C++, only a few primitive data types are available inbuilt, unlike Python which provides a dynamic list, dictionary, set and tuples, etc.

Standard template library(STL) is a software library for C++, which provides these kinds of data structures and algorithms.

STL provides the following four components:

Algorithms: searching, sorting, etc.
Containers: Sequences such as vector, list. Queue, stack, map, set, etc.
Functions
Iterators

It is called a template library because it uses the C++ template feature discussed above.

Let's see one example of a container: vector.

Vector

The STL vector class is a class template for sequence containers.

It stores elements of a given type in a linear order and allows fast random access to any element. Sounds like an array? Yes, it is an array but it is dynamic means its size can change when needed.

This example shows how to create and use a vector:

#include <iostream>
#include <vector>   // STL Header file for vector class

int main()
{
    std::vector<int> numbers{1, 2, 3, 4, 5};

    for (int i = 0; i < numbers.size(); i++)
        std::cout << numbers[i] << " ";
    std::cout << "\n";  // OUTPUT: 1 2 3 4 5

    std::vector<char> alphabets;    // Empty vector
    alphabets.push_back('a');   // adding an element to back of vector
    alphabets.push_back('b');
    alphabets.push_back('c');

    std::cout << alphabets[1] << "\n";  // OUTPUT: b

    return 0;
}

To learn more about STL, checkout this article

Range Based For Loop

In the previous example, we used a simple for loop to iterate over our vector. We can do the same with the better range-based for loop.

Syntax:

for (for-range-declaration : expression)
    statement

So this is how we can change the previous code with a range based for loop:

// For printing the numbers vector
for (int x : numbers)
    std::cout << x << " ";

// For printing the alphabets vector
for (auto ch : alphabets)   // Notice the use of auto - Recommended
    std::cout << ch << " ";

for (auto i : {1, 2, 3})
        std::cout << i << " ";  // 1 2 3

int arr[] = {4, 5, 6};
for (auto j : arr)
    std::cout << j << " ";  // 4 5 6

Here x will point to an individual element in numbers one by one.

To learn more about range-based loops, read this article

Lambda Expressions

A lambda expression is a convenient way of defining an anonymous function.

Lambdas are used to encapsulate a few lines of code that are passed to algorithms and other functions.

Syntax:

capture clause: Specifies which variables are captured from the surrounding scope and whether the capture is by value or by reference.

Variables prefixed with & are accessed by reference other by value.
Empty clause [ ] indicates that the lambda body has no access to variables in the enclosing scope.
[&] means all variables are captured by reference.
[=] means all variables are captured by value.

parameter list (optional): A lambda can accept input parameters just like a normal function. It is optional and you can leave the parenthesis empty in case of no parameters.
mutable specification (optional): mutable keyword allows us to modify a value captured in the lambda body. (Usage is shown in the example below).
exception-specification (optional): You can use the noexcept exception specification to indicate that the lambda expression does not throw any exceptions.
trailing-return-type (optional): Just like normal function a lambda also have a return type. You can omit the return-type part of a lambda expression if the lambda body contains just one return statement or the expression does not return a value.
lambda body: A lambda body can contain anything that a normal function's body can contain.

These are a few examples of lambda functions:

Here we have used a lambda function that finds the square of a number. The type of the lambda is automatically deduced using auto and it is stored in an identifier square.

The return type is automatically deduced to int.

  #include <iostream>

  int main()
  {
      auto square = [](int n) {
        return n * n;  
      };

      std::cout << "Square of 2 = " << square(2) << "\n";
      // Square of 2 = 4

      return 0;
  }

Here, we have shown the usage of the mutable keyword, without using it we would have received an error saying outer is read-only.

Moreover, the value of the outer is unchanged outside lambda as it was captured by value [=].

  #include <iostream>

  int main()
  {
      int outer = 50;

      auto fn = [=]() mutable {
          outer = 100;    // OK, because of mutable
          std::cout << "Outer = " << outer << "\n";   // Outer = 100
      };

      fn();
      std::cout << "Outer = " << outer << "\n";   // Outer = 50

      return 0;
  }

Here, we have used lambda to pass a function to the for_each algorithm.

  #include <iostream>
  #include <algorithm>
  #include <vector>

  int main()
  {
      std::vector<int> nums{1, 2, 3, 4, 5, 6};

      for (auto x : nums) // 1 2 3 4 5 6 
          std::cout << x << " ";
      std::cout << "\n";

      // Square every number
      std::for_each(begin(nums), end(nums), [](int& n) {n = n * n;}); 

      for (auto x : nums) // 1 4 9 16 25 36 
          std::cout << x << " ";
      std::cout << "\n";

      return 0;
  }

To learn more about lambda functions, checkout this article

EndNote

This article was only supposed to introduce you to some modern powerful features provided by the C++ language.

If you want to learn more about these features, you may check out the links provided for each topic. The best way to learn these is by using it.

C++ has more amazing and modern features contrary to the belief that it is an old and outdated language.

Share your opinion in the comments.

DEV Community: Yuvraj Singh Jadon

Deploying and Scaling OpenTelemetry in Production NextJS Apps

Option 1: Deploying on Vercel

Option 2: Self-Hosting (Docker / K8s)

TL;DR

2. Collector vs Direct Exporter

Collector Approach (Recommended)

Architecture:

Why use a Collector?

Example Collector Config

Your Next.js App Config (Collector Setup):

Direct Exporter Approach

Architecture

Pros:

Cons:

🔧 Direct Exporter Example:

TL;DR - Which One to Choose?

Setting Up Alerts

Understanding SigNoz APM Metrics

Alert Example: High P99 Latency

Testing the Alert

Maintaining Alert Hygiene

Sampling Strategy for Production

What Sampling Actually Means

Why You Should Care

When to Use Sampling

Head vs Tail Sampling

Head Sampling

Tail Sampling

Hiding Sensitive Data

What to Watch For

Step 1: Don’t Collect It

Step 2: Scrub at the Collector

Step 3: Validate No Leaks

1. Performance Overhead

Optimization Strategy

2. Cold Starts (Serverless + Edge)

Mitigation Techniques

3. Missing Spans

❌ Common Gaps

Solutions

Detection Strategy

Final Thoughts

Observability Changes How You Build

Mindset Shift

Key Takeaways

Implementation

Optimization

SigNoz Highlights

Structured Logging in NextJS with OpenTelemetry

Why You Need More Than console.log

Server-Side Logging with Trace Context

Step 1: Install Required Packages

Step 2: Create the Logs Exporter

Step 3: Unified Logger

Step 4: High-Performance Pino Logger (Optional)

Client-Side Logging with Auto-Export

Step 5: Create Browser Logger

Step 6: API Route to Receive Logs

Instrumentation Hook

Step 7: Add to instrumentation.ts

Logs Demo Page

Step 8: Create logs-demo/page.tsx

View Logs in SigNoz

Step 9: Explore Your Logs

Next: Production Deployment and Scaling

Tracking Web Vitals & Widget Performance in Next.js with OpenTelemetry

1. Install Dependencies

2. Create lib/web-vitals.ts

3. Add WebVitalsProvider

4. Use in Your Layout

5. Enable CORS for the Collector

6. Visualize in SigNoz

Quick Tips

Tracking Third-Party Widget Performance

The Strategy: Wrap and Measure

Why It’s Worth Doing

Next: Structured Logging with Trace Correlation

NextJS OpenTelemetry Use Cases - Monitoring 404s, External APIs, Exceptions & More

Tracking 404 Errors by Route

Why You Need More Than `console.log`

Step 7: Add to `instrumentation.ts`

Step 8: Create `logs-demo/page.tsx`

2. Create `lib/web-vitals.ts`

Configuring `instrumentation.ts` for External API Monitoring

1. Install `@vercel/otel`

2. Create `instrumentation.ts`

Update `next.config.mjs` to include `instrumentationHook`

Why Use `@vercel/otel`?

Step 2: Modify `otel-collector-config.yaml`

Step 3: Update `docker-compose.yaml`