Hvordan nærmer du deg logging og monitoring i produksjon Node?

Question

Accepted Answer

**Logging** registrerer hva appen din gjør; **monitoring** sporer dens helse og ytelse. Sammen gir de deg **observability** — evnen til å forstå og feilsøke et kjørende produksjonssystem. `console.log` er utilstrekkelig for dette; du trenger strukturerte logger, metrics og alerting.

## Strukturert 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");
```

Bruk en strukturert logger (pino/winston) som skriver ut **JSON** med konsistente felt. JSON-logger er søkbare og filtrerbare i loggaggregeingsverktøy, ulikt fritt formaterte `console.log`-strenger. Inkluder kontekst (bruker-id, forespørsels-id) på hver logg.

## Log-nivåer og hva du skal logge

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

## Korrelasjon-IDer sporer en forespørsel på tvers av 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
```

En **korrelasjon/forespørsels-ID** lar deg rekonstruere hele historien til en enkelt forespørsel, selv på tvers av flere tjenester — uunnværlig for feilsøking av distribuerte systemer.

## Sentraliser logger

```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 viktigste metrikene å overvåke er **"golden signals"**: latency, traffic, errors og saturation. Alerting på disse fanger problemer før brukere rapporterer dem.

## Hvorfor det er viktig

I produksjon kan du ikke knytte en debugger — **observability gjennom logging og monitoring er hvordan du forstår, feilsøker og driver** et live system.

Strukturerte JSON-logger med korrelasjon-IDer gjør hendelser diagnosiserbare (spesielt på tvers av microservices); sentralisert aggregering gjør logger brukbare i stor skala; og monitoring med metrics, healthchecks, distribuert tracing og alerting lar deg oppdage og reagere på problemer proaktivt i stedet for etter at brukere klager.

Å bygge dette inn (ikke legge det til etter et strømbrudd) er en definerende praksis for å kjøre pålitelige produksjon Node-tjenester.