Comment approchez-vous la journalisation et la surveillance en production Node?

Question

Accepted Answer

**La journalisation** enregistre ce que fait votre application ; **la surveillance** suit sa santé et ses performances. Ensemble, elles vous donnent une **observabilité** — la capacité à comprendre et déboguer un système de production en cours d'exécution. `console.log` est insuffisant pour cela ; vous avez besoin de journaux structurés, de métriques et d'alertes.

## Journalisation structurée (pas 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");
```

Utilisez un logger structuré (pino/winston) qui génère du **JSON** avec des champs cohérents. Les journaux JSON sont recherchables et filtrables dans les outils d'agrégation de journaux, contrairement aux chaînes `console.log` de format libre. Incluez le contexte (id utilisateur, id requête) dans chaque journal.

## Niveaux de journal et ce qu'il faut enregistrer

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

## Les IDs de corrélation tracent une requête à travers les services

```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 **ID de corrélation/requête** vous permet de reconstituer l'historique complet d'une seule requête, même à travers plusieurs services — indispensable pour déboguer les systèmes distribués.

## Centralisez les journaux

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

## Surveillance : métriques, alertes, traçage

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

Les métriques clés à surveiller sont les **"signaux dorés"** : latence, trafic, erreurs et saturation. Les alertes sur celles-ci détectent les problèmes avant que les utilisateurs les signalent.

## Pourquoi c'est important

En production, vous ne pouvez pas connecter un débogueur — **l'observabilité par la journalisation et la surveillance est la façon de comprendre, déboguer et exploiter** un système en direct.

Les journaux JSON structurés avec des IDs de corrélation rendent les incidents diagnostiquables (en particulier sur les microservices) ; l'agrégation centralisée rend les journaux exploitables à l'échelle ; et la surveillance avec métriques, vérifications de santé, traçage distribué et alertes vous permet de détecter et de répondre aux problèmes de manière proactive plutôt qu'après les plaintes des utilisateurs.

Construire cela dès le départ (et non le rajouter après une panne) est une pratique déterminante pour exploiter des services Node en production fiables.