Why Observability Is More Than Dashboards

A dashboard full of green graphs is comforting right up until the moment it isn’t. Teams often equate “we have Grafana” with “we have observability,” but a dashboard is a summary — it tells you something changed, rarely why.

The three pillars, and what each one is actually for

• Metrics answer “is something wrong, and how bad is it?” — request rate, error rate, latency percentiles, saturation. They’re cheap to store and great for alerting, but they’re aggregates: a p95 latency spike doesn’t tell you which specific requests were slow, or why.
• Logs answer “what exactly happened, on this one request?” — structured, queryable events with enough context (request ID, user ID, service name) to reconstruct a single transaction.
• Traces answer “where, across a dozen services, did the time go?” — a distributed trace turns “the checkout API is slow” into “87% of that latency was a single downstream call to the inventory service.”

The pillars only become observability when they’re correlated — when a spike in a metric lets you jump straight to the traces and logs for the exact requests that caused it, without a manual grep across five services’ log files.

A minimal OpenTelemetry setup

Instrumenting a Node.js service to emit traces alongside your existing metrics is a smaller lift than most teams expect:

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT,
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Auto-instrumentation covers HTTP, database drivers and common frameworks out of the box — you get useful traces before writing a single manual span. Manual spans come later, once you know which specific business logic (a pricing calculation, a fraud check) is worth tracing explicitly.

Where teams get stuck

Almost never on the tooling. The friction is usually organizational: nobody owns the correlation IDs, trace context isn’t propagated across a queue boundary, or the retention window on traces is so short that by the time someone asks “what happened at 2am,” the data is already gone. Observability is a data pipeline with a retention policy, not a dashboard — treat it that way from day one and the tooling problems mostly solve themselves.