Come affronti il logging e il monitoring nella production Node?

Question

Accepted Answer

**Logging** registra ciò che la tua app fa; **monitoring** traccia la sua salute e performance. Insieme ti danno **observability** — la capacità di comprendere e debuggare un sistema production in esecuzione. `console.log` è inadeguato per questo; hai bisogno di log strutturati, metriche e alerting.

## Structured logging (non 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");
```

Usa un logger strutturato (pino/winston) che emette **JSON** con campi consistenti. I log JSON sono ricercabili e filtrabili negli strumenti di aggregazione dei log, a differenza delle stringhe `console.log` in formato libero. Includi contesto (user id, request id) su ogni log.

## Log levels e cosa loggare

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

## I Correlation IDs tracciano una richiesta attraverso i servizi

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

Un **correlation/request ID** ti permette di ricostruire la storia completa di una singola richiesta, anche tra più servizi — indispensabile per debuggare sistemi distribuiti.

## Centralizza i log

```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: metriche, alert, 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
```

Le metriche chiave da monitorare sono i **"golden signals"**: latency, traffic, errors e saturation. Gli alert su questi catturano i problemi prima che gli utenti li segnalino.

## Perché è importante

In production non puoi allegare un debugger — **l'observability attraverso logging e monitoring è il modo in cui comprendi, debuggi e operi** un sistema live.

I log JSON strutturati con correlation ID rendono gli incidenti diagnosticabili (soprattutto nei microservizi); l'aggregazione centralizzata rende i log utilizzabili in scala; e il monitoring con metriche, health check, distributed tracing e alerting ti permette di rilevare e rispondere ai problemi in modo proattivo piuttosto che dopo i reclami degli utenti.

Costruire questo (non aggiungerlo dopo un'interruzione) è una pratica distintiva del funzionamento di servizi Node production affidabili.