Hvordan tilgår du logging og monitorering i produktion Node?

Question

Accepted Answer

**Logging** registrerer, hvad din app gør; **monitorering** sporer dens sundhed og ydeevne. Sammen giver de dig **observerbarhed** — evnen til at forstå og debugge et kørende produktionssystem. `console.log` er utilstrækkeligt til dette; du skal bruge strukturerede logs, metrikker og alarmer.

## Struktureret logging (ikke 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");
```

Brug en struktureret logger (pino/winston), der udsender **JSON** med konsistente felter. JSON-logs er søgbare og filtrerbare i log-aggregeringsværktøjer, i modsætning til frit formaterede `console.log`-strenge. Inkluder kontekst (bruger-id, anmodnings-id) i hvert log.

## Log-niveauer og hvad der skal logges

```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)
```

## Korrelations-id'er sporer en anmodning på tværs af tjenester

```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
```

Et **korrelations-/anmodnings-id** giver dig mulighed for at rekonstruere hele historien om en enkelt anmodning, selv på tværs af flere tjenester — uundværligt til debugging af distribuerede systemer.

## Centralisér logs

```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.
```

## Monitorering: metrikker, alarmer, sporing

```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 vigtigste metrikker at overvåge er **"gyldne signaler"**: latens, trafik, fejl og mætning. Alarm på disse registrerer problemer, før brugere rapporterer dem.

## Hvorfor det betyder noget

I produktion kan du ikke tilknytte en debugger — **observerbarhed gennem logging og monitorering er hvordan du forstår, debugger og betjener** et live-system.

Strukturerede JSON-logs med korrelations-id'er gør hændelser diagnosticerbare (især på tværs af microservices); centraliseret aggregering gør logs brugbar i skala; og monitorering med metrikker, sundhedskontroller, distribueret sporing og alarmer giver dig mulighed for at opdage og reagere på problemer proaktivt i stedet for efter brugerklagsmål.

At bygge dette ind (i stedet for at bolte det på efter et nedbrud) er en definerende praksis for at køre pålidelige produktions-Node-tjenester.