Wie gehst du in einer Produktionsumgebung Node bei Logging und Monitoring vor?

Question

Accepted Answer

**Logging** erfasst, was deine Anwendung tut; **Monitoring** verfolgt ihre Gesundheit und Leistung. Zusammen geben sie dir **Observability** — die Fähigkeit, ein laufendes Produktionssystem zu verstehen und zu debuggen. `console.log` ist dafür unzureichend; du benötigst strukturierte Logs, Metriken und Alarme.

## Strukturiertes Logging (nicht 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");
```

Verwende einen strukturierten Logger (pino/winston), der **JSON** mit konsistenten Feldern ausgibt. JSON-Logs sind in Log-Aggregationstools durchsuchbar und filterbar, im Gegensatz zu frei formatierten `console.log`-Strings. Füge zu jedem Log Kontext ein (Benutzer-ID, Request-ID).

## Log-Level und was zu loggen ist

```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-IDs verfolgen einen Request über Services hinweg

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

Eine **Korrelations-/Request-ID** ermöglicht es dir, die vollständige Geschichte eines einzelnen Requests zu rekonstruieren, sogar über mehrere Services hinweg — unverzichtbar zum Debuggen verteilter Systeme.

## Logs zentralisieren

```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: Metriken, 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
```

Die wichtigsten zu überwachenden Metriken sind die **"Golden Signals"**: Latenz, Traffic, Fehler und Sättigung. Alerts auf diese erfassen Probleme, bevor Nutzer sie melden.

## Warum es wichtig ist

In der Produktion kannst du keinen Debugger anschließen — **Observability durch Logging und Monitoring ist die Möglichkeit, ein live System zu verstehen, zu debuggen und zu betreiben.**

Strukturierte JSON-Logs mit Korrelations-IDs machen Incidents diagnostizierbar (besonders über Microservices); zentralisierte Aggregation macht Logs skalierbar; und Monitoring mit Metriken, Health Checks, Distributed Tracing und Alerts ermöglicht es dir, proaktiv Probleme zu erkennen und darauf zu reagieren, statt nach Nutzerbeschwerden zu warten.

Dies von Anfang an einzubauen (statt es nach einem Ausfall nachzurüsten) ist eine definierende Praxis beim Betrieb zuverlässiger produktiver Node-Services.