Observability (Metrics/Logs/Traces) Cheat Sheet

The three pillars of observability covering metrics instrumentation, structured logging, distributed tracing, and OpenTelemetry setup.

3 PagesIntermediateApr 14, 2026

OpenTelemetry SDK Setup (Node.js)

Bootstrap traces and metrics export via OTLP to a collector.

javascript

const { NodeSDK } = require('@opentelemetry/sdk-node');const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-grpc');const { OTLPMetricExporter } = require('@opentelemetry/exporter-metrics-otlp-grpc');const { PeriodicExportingMetricReader } = require('@opentelemetry/sdk-metrics');const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');const sdk = new NodeSDK({  traceExporter: new OTLPTraceExporter({ url: 'http://otel-collector:4317' }),  metricReader: new PeriodicExportingMetricReader({    exporter: new OTLPMetricExporter({ url: 'http://otel-collector:4317' }),    exportIntervalMillis: 15000,  }),  instrumentations: [getNodeAutoInstrumentations()],});sdk.start();

Manual Span & Structured Log Correlation

Creating a custom span and emitting a structured log with the trace ID attached.

javascript

const { trace, context } = require('@opentelemetry/api');const tracer = trace.getTracer('checkout-service');async function processOrder(order) {  return tracer.startActiveSpan('process_order', async (span) => {    span.setAttribute('order.id', order.id);    try {      const result = await chargeCard(order);      span.setStatus({ code: 1 }); // OK      return result;    } catch (err) {      span.recordException(err);      span.setStatus({ code: 2, message: err.message }); // ERROR      throw err;    } finally {      span.end();    }  });}// Structured log line with trace correlationfunction logInfo(msg, extra = {}) {  const spanCtx = trace.getSpanContext(context.active());  console.log(JSON.stringify({    level: 'info', msg, trace_id: spanCtx?.traceId, span_id: spanCtx?.spanId, ...extra,  }));}

OpenTelemetry Collector Pipeline

A collector config that fans out traces/metrics/logs to backend systems.

yaml

receivers:  otlp:    protocols:      grpc: {}      http: {}processors:  batch: {}  memory_limiter:    limit_mib: 512exporters:  otlp/tempo:    endpoint: tempo:4317    tls: { insecure: true }  prometheusremotewrite:    endpoint: http://mimir:9009/api/v1/push  loki:    endpoint: http://loki:3100/loki/api/v1/pushservice:  pipelines:    traces:      receivers: [otlp]      processors: [memory_limiter, batch]      exporters: [otlp/tempo]    metrics:      receivers: [otlp]      processors: [memory_limiter, batch]      exporters: [prometheusremotewrite]    logs:      receivers: [otlp]      processors: [memory_limiter, batch]      exporters: [loki]

The Three Pillars — When to Use Each

Quick reference for choosing the right signal for a given question.

Metrics- cheap, aggregated numeric time-series; best for alerting and dashboards (RED/USE method)
Logs- discrete, detailed events; best for post-hoc debugging of a specific incident or request
Traces- causally-linked spans across services; best for finding where latency or errors originate in a request path
RED method- Rate, Errors, Duration — the standard three metrics for any request-driven service
USE method- Utilization, Saturation, Errors — standard metrics for resources like CPU, disk, queues
Exemplars- links from a metric data point directly to a sample trace ID that produced it

Pro Tip

Standardize on OpenTelemetry's semantic conventions (`http.route`, `db.system`, `service.name`) from day one — vendor-specific auto-instrumentation is a trap you'll pay for later when correlating metrics, logs, and traces across a backend migration.

Was this cheat sheet helpful?

Platform Engineering Basics Cheat Sheet

ClickHouse Cheat Sheet