Hoe benader je logging en monitoring in production Node?

Question

Accepted Answer

**Logging** registreert wat je app doet; **monitoring** volgt de gezondheid en prestaties ervan. Samen geven zij je **observability** — het vermogen om een draaiend productiesysteem te begrijpen en fouten op te sporen. `console.log` is ontoereikend hiervoor; je hebt structured logs, metrics en alerting nodig.

## Structured logging (niet console.log)

```js
import pino from "pino";
const logger = pino();

// ✅ structured JSON logs — machine-parseable, searchable, with context
logger.info({ userId: 123, action: "login", ip: req.ip }, "user logged in");
logger.error({ err, requestId }, "failed to process order");
```

Gebruik een structured logger (pino/winston) die **JSON** uitvoert met consistente velden. JSON-logs zijn doorzoekbaar en filterbaar in log-aggregatietools, in tegenstelling tot vrije-vorm `console.log` strings. Voeg context (user id, request id) toe aan elk logbericht.

## Logniveaus en wat je moet loggen

```text
Levels: error > warn > info > debug (configure threshold per environment)
Log:    requests, errors with stack traces, key business events, slow operations
DON'T log: passwords, tokens, PII, full payloads with secrets (security/privacy)
```

## Correlatie-ID's volgen een verzoek over services heen

```js
// attach a unique id per request, include it in EVERY log for that request
app.use((req, res, next) => {
  req.id = crypto.randomUUID();
  res.setHeader("X-Request-Id", req.id);
  next();
});
// now you can filter all logs for one request — vital in microservices
```

Een **correlatie-/verzoek-ID** stelt je in staat het volledige verhaal van een enkel verzoek te reconstrueren, zelfs over meerdere services — onmisbaar voor het debuggen van gedistribueerde systemen.

## Logs centraliseren

```text
Ship logs to a central platform (ELK/Elasticsearch, Datadog, Grafana Loki, CloudWatch)
→ search/aggregate across all instances; don't grep files on individual servers.
```

## Monitoring: metrics, alerts, tracing

```text
Metrics:  request rate, error rate, latency (p50/p95/p99), CPU/memory, event-loop lag
          (often via Prometheus + Grafana, or an APM like Datadog/New Relic)
Health:   /health & /ready endpoints for load balancers and orchestrators
Alerting: notify (PagerDuty/Slack) when error rate spikes or latency degrades
Tracing:  distributed tracing (OpenTelemetry) to follow requests across services
Errors:   error tracking (Sentry) for aggregated exceptions with stack traces & context
```

De sleutelmetrics om in de gaten te houden zijn de **"gouden signalen"**: latency, traffic, errors en saturation. Waarschuwingen hierop vangen problemen op voordat gebruikers ze rapporteren.

## Waarom het belangrijk is

In production kun je geen debugger aanhechten — **observability via logging en monitoring is hoe je** een actief draaiend systeem **begrijpt, debugt en opereert**.

Gestructureerde JSON-logs met correlatie-ID's maken incidenten diagnosticeerbaar (vooral over microservices heen); gecentraliseerde aggregatie maakt logs bruikbaar op schaal; en monitoring met metrics, health checks, gedistribueerde tracing en alerting stelt je in staat problemen proactief op te sporen en te reageren in plaats van nadat gebruikers klagen.

Dit van het begin af aan bouwen (niet later als reactie op een storing) is een bepalende praktijk voor het uitvoeren van betrouwbare production Node-services.