DEV Community: Modulis

Your Observability Bill Is Growing Faster Than Traffic. Here's How to Audit It.

Modulis — Mon, 09 Nov 2026 09:49:09 +0000

Your application traffic is growing steadily. Your infrastructure is scaling as expected. Nothing particularly unusual is happening in production.

But your observability bill keeps increasing.

This is a problem many engineering teams encounter as their systems grow. More services produce more telemetry. Debugging changes increase log volume. Additional infrastructure introduces more hosts and spans. At the same time, teams often add separate tools for monitoring, error tracking, session replay and product analytics.

Eventually, the cost of understanding your own system becomes a significant operational expense.

The interesting part is that this increase doesn't always reflect an equivalent increase in customer traffic or business activity.

1. Observability pricing has multiple dimensions

Observability vendors use different pricing models. Common billing dimensions include:

Log ingestion: How many gigabytes of logs are collected.
Traces and spans: How much tracing data is ingested or retained.
Infrastructure hosts: How many hosts or monitored resources are covered.
Seats: How many engineers or users access the platform.

These models can make costs difficult to forecast.

Consider a team that adds several backend services. Each service introduces more logs and traces. The team also increases log verbosity while investigating a production issue.

The application may be serving roughly the same number of requests, but the volume of telemetry being collected has changed.

The monitoring bill reflects that change.

This is one reason engineering teams should treat observability spend as an architectural consideration rather than simply another SaaS subscription.

2. Tool sprawl makes the problem harder

The problem is not always one expensive monitoring platform.

A typical engineering stack may include:

Infrastructure monitoring and APM
Error tracking
Session replay
Product analytics
Log management

Each tool may have its own billing model, retention policy and contract.

This creates two types of cost.

Direct cost: Separate subscriptions and usage-based charges across multiple vendors.

Operational cost: Engineers switching between tools, matching timestamps, correlating trace IDs and trying to understand an incident using disconnected information.

The second cost is easy to overlook.

Even when every individual tool seems reasonably priced, maintaining the complete stack can become expensive.

3. Cutting telemetry is not always the answer

When an observability bill becomes difficult to justify, teams often consider reducing log retention, disabling instrumentation or collecting fewer traces.

Sometimes that is necessary. But blindly reducing telemetry can create another problem.

The information removed to reduce costs may be exactly what engineers need during the next production incident.

The objective should not be to collect as little data as possible.

It should be to understand what data is being collected, why it is being collected, what it costs and how useful it is during investigation.

4. Start with a cost audit

Before switching vendors or redesigning your observability stack, understand where the current spend comes from.

Here is a practical starting point.

Step 1: List every observability product.

Include infrastructure monitoring, APM, logs, traces, error tracking, session replay and analytics.

Step 2: Identify the billing unit.

For each tool, understand whether the primary cost is based on ingestion volume, hosts, spans, seats, retention or a combination.

Step 3: Compare cost against workload growth.

Look at monthly telemetry volume alongside application growth, new services, deployment frequency and instrumentation changes.

This helps distinguish genuine workload growth from changes in how much data the system emits.

Step 4: Review the value of collected data.

Ask whether teams actively use the signals being stored. Review retention requirements and whether the same operational questions are being answered across multiple products.

Step 5: Calculate the total cost of ownership.

Include subscriptions, infrastructure, storage and the engineering time spent maintaining and reconciling the tools.

The invoice is only part of the cost.

5. Think about pricing predictability

There isn't one pricing model that is automatically best for every engineering team.

Usage-based pricing can make sense for smaller workloads where telemetry volume is low and predictable.

As workloads grow, however, a per-GB, per-host or per-span model can make forecasting more difficult.

A flat subscription model offers a different trade-off: the subscription is determined by a plan tier rather than increasing with every unit of telemetry.

For example, Modulis uses a flat monthly subscription per plan tier, with unlimited ingestion on paid tiers subject to fair use. It combines observability, error monitoring, session replay, product analytics and AI-assisted resolution in one platform.

There are still costs to account for.

With its Bring Your Own Cloud (BYOC) model, the customer pays their cloud provider separately for the infrastructure used by the platform. With Bring Your Own Key (BYOK), AI inference is separately billed by the model provider.

That means a meaningful comparison should include the subscription, cloud infrastructure and AI inference rather than comparing subscription prices alone.

6. Make observability cost part of engineering ownership

Observability is essential. Production systems need logs, metrics, traces and error visibility.

But collecting more data should not automatically mean accepting an unpredictable bill.

Engineering and platform teams should understand the cost implications of their instrumentation decisions just as they understand their compute and storage decisions.

A useful observability strategy should balance three things:

Visibility into production systems.
The ability to investigate incidents without unnecessary friction.
A cost model that can be forecast as the system grows.

The goal is not to become blind to production problems to save money.

It is to build a system where visibility remains useful, connected and financially sustainable.

Disclosure: This article is published by Modulis, an engineering observability and production-resolution platform.

Originally published at: https://modulis.ai/blog/monitoring-bill-grows-faster-than-traffic/

OpenTelemetry with Next.js, Node.js and Kubernetes: A Practical Production Setup

Modulis — Thu, 05 Nov 2026 11:46:17 +0000

When a production issue occurs, finding the actual cause can be harder than fixing it.

A request might start in a Next.js frontend, pass through multiple Node.js services, hit a database, and eventually fail somewhere along the way.

You might have logs in one place, traces in another, and error reports somewhere else.

Without proper instrumentation and correlation, debugging becomes a manual exercise.

This is where OpenTelemetry (OTel) becomes useful.

OpenTelemetry provides a vendor-neutral way to collect traces, metrics, and logs from your applications. Once your applications are instrumented, you can change telemetry backends without rewriting your instrumentation.

In this guide, we'll set up OpenTelemetry for a practical production stack:

Next.js frontend
Node.js / Express backend
Distributed tracing
Logs connected to traces
Kubernetes OpenTelemetry Collector
Filtering and sensitive-data scrubbing

By the end, you'll have a foundation for understanding what's happening across your services.

1. Start with consistent service naming

Before installing any packages, establish consistent naming across your services.

OpenTelemetry uses resource attributes to describe which service is generating telemetry.

Here are four attributes worth configuring:

Attribute	Example	Purpose
`service.name`	`checkout-api`	Identifies the service
`service.namespace`	`storefront`	Groups related services
`service.version`	`1.42.0`	Connects errors with deployments
`deployment.environment.name`	`production`	Separates production and staging

Set these through environment variables:

OTEL_SERVICE_NAME=checkout-api

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

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

OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

A useful practice: Set service.version to your Git SHA or release tag through your CI/CD pipeline.

When an error starts appearing after a deployment, you'll have a much easier time connecting the incident to the relevant release.

2. Instrument your Next.js application

Next.js supports OpenTelemetry through its instrumentation file.

One straightforward approach is using @vercel/otel. Despite the package name, it also works when running Next.js on your own infrastructure.

Install the dependencies:

npm install @vercel/otel @opentelemetry/api

Create an instrumentation.ts file in your project root (or inside src/ if your application uses that directory).

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

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

This provides instrumentation for:

Incoming requests
Server-side rendering
Route handlers
Server-side fetch calls

The exporter uses the standard OTEL_EXPORTER_OTLP_* environment variables configured earlier.

Add custom spans

Automatic instrumentation is useful, but sometimes you need additional context around specific business operations.

For example, consider a recommendation service:

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

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

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

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

This creates a custom span around the operation and records exceptions when something goes wrong.

Important: Avoid adding sensitive or high-cardinality values such as raw user IDs to span attributes unless there is a justified reason and appropriate data handling.

Also remember that server-side instrumentation and browser-side tracing are separate concerns. Edge runtime instrumentation has limitations, so consider your runtime requirements when designing the setup.

3. Instrument your Node.js / Express API

For a Node.js service, the OpenTelemetry Node SDK and auto-instrumentation packages provide a practical starting point.

They can automatically instrument supported libraries such as HTTP clients, Express, database clients, Redis and gRPC.

Install:

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

Create an instrumentation.js file:

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

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

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

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

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

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

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

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

sdk.start();

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

Load instrumentation before your application

This is one of the most important implementation details.

OpenTelemetry auto-instrumentation needs to initialize before the application modules load. Otherwise, it might not correctly hook into Express, database clients or other libraries.

For a CommonJS application, start your service like this:

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

In your Dockerfile:

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

For a zero-code approach, the auto-instrumentation package can also register itself:

node --require @opentelemetry/auto-instrumentations-node/register server.js

If you're using ES modules ("type": "module"), check the OpenTelemetry JavaScript documentation for the appropriate ESM loader configuration.

4. Connect logs with traces

Collecting traces and logs independently is useful.

Connecting them is much more powerful.

Imagine an API request that takes several seconds to complete.

Your trace tells you which operation was slow, but your application logs might contain the actual error or business context.

The goal is to have every relevant log line carry the trace_id of the request that generated it.

For example, with Pino:

const pino = require('pino');

const logger = pino();

app.post('/checkout', async (req, res) => {
  logger.info(
    { cartSize: req.body.items.length },
    'checkout started'
  );
});

With the appropriate OpenTelemetry log instrumentation and request context, the resulting log record can include:

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

There are two practical ways to collect these logs:

Continue writing logs to stdout and let a log collector, such as the OpenTelemetry Collector's filelog receiver, collect them.
Export logs directly through OTLP from the SDK.

Either approach can work.

The important part is maintaining trace context so that you can move from a trace to its corresponding logs.

5. Deploy an OpenTelemetry Collector on Kubernetes

Your applications can export telemetry directly to a backend.

However, putting an OpenTelemetry Collector between your applications and the backend gives you much better control over the telemetry pipeline.

A Collector allows you to:

Filter noisy health-check traffic.
Remove sensitive attributes before export.
Batch telemetry.
Retry exports when a backend becomes temporarily unavailable.
Change telemetry backends without modifying every application.

For Kubernetes deployments, you can use the OpenTelemetry Helm chart or OpenTelemetry Operator.

The following is a starting configuration using the otelcol-contrib distribution.

Collector configuration

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

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

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

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

  batch:
    send_batch_size: 8192
    timeout: 5s

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

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

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

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

Replace the exporter endpoint with your actual backend endpoint.

Why this configuration matters

Memory limiter

Helps protect the Collector from excessive memory usage. It should be placed early in each pipeline.

Health-check filtering

Removes /healthz and /readyz spans from the trace pipeline.

Sensitive-data scrubbing

Removes authorization and cookie headers and hashes selected user attributes before export.

Batch processing

Groups telemetry records before exporting them.

One important consideration: filtering and scrubbing policies should be reviewed against your application's actual data and security requirements.

Additional improvements

Once the basic setup is working, consider adding:

Tail sampling to retain important error and slow traces while sampling healthy traffic.
The k8sattributes processor to enrich telemetry with Kubernetes pod, namespace and deployment metadata.

These additions can help make the telemetry pipeline more useful as your infrastructure grows.

6. Verify that your instrumentation works

Don't assume that a running Collector means your instrumentation is correct.

Generate some application traffic and check the following:

[ ] Every service appears with its actual service.name.
[ ] A request through Next.js and the API appears as one distributed trace.
[ ] Log lines contain the same trace_id.
[ ] Health-check spans are filtered out.
[ ] Authorization headers and raw emails are not present in exported span attributes.

Common problems

Symptom	Likely cause	What to check
`unknown_service`	Service name missing	Set `OTEL_SERVICE_NAME`
No Express or database spans	Instrumentation loaded too late	Use `--require`
Traces split between services	Context propagation failure	Check `traceparent`
Increasing telemetry costs	High-cardinality attributes	Remove unnecessary IDs and full URLs from metric attributes
Data missing during shutdown	SDK not flushed	Call `sdk.shutdown()` on SIGTERM
Collector restarts	Memory pressure	Configure `memory_limiter` early in pipelines

If traces are breaking between services, check whether the outgoing request is using an instrumented client and whether an intermediate proxy is preserving the traceparent header.

7. What happens after OpenTelemetry is configured?

At this point, you have established the telemetry foundation:

Your applications emit traces and metrics.
Logs carry trace context.
The Collector filters and processes telemetry.
Sensitive attributes are handled before export.
Your backend receives correlated signals.

But collecting telemetry is only one part of production debugging.

When an incident occurs, engineers still need to connect the relevant error, trace, logs, user session and deployment context to understand what actually happened.

This is where having correlated engineering signals becomes valuable.

Connecting your OpenTelemetry setup to Modulis

Modulis is an engineering intelligence and incident-resolution platform built on OpenTelemetry.

It runs inside your own cloud and correlates production errors, traces, logs, session replays and Git metadata.

Once your application is instrumented, you can connect your Collector to the Modulis OTLP endpoint provided during setup.

Add the following resource attribute:

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

If modulis.application isn't configured, Modulis falls back to service.namespace.

With the telemetry connected, Modulis brings the related engineering context together. Its AI resolution workflow uses your own model key to identify likely root causes and open PR-ready fixes for your engineers to review and merge.

The deployment runs in your own cloud, and AI resolution uses your own model key.

You can explore the platform at modulis.ai.

Final thoughts

OpenTelemetry provides a solid foundation for understanding what happens across distributed applications.

For teams running Next.js, Node.js and Kubernetes, a well-configured setup can make production debugging considerably more structured.

Start with consistent resource attributes, instrument your applications, connect logs to traces, and introduce a Collector to control the telemetry pipeline.

Most importantly, verify the entire request path instead of assuming that individual services are correctly instrumented.

Collecting telemetry is the first step. Making it useful during an actual production incident is the real goal.

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