Cum abordezi logging-ul și monitorizarea în Node în producție?

Question

Accepted Answer

**Logging** înregistrează ce face aplicația ta; **monitoring** urmărește starea sa de sănătate și performanța. Împreună, îți dau **observabilitate** — capacitatea de a înțelege și depana un sistem de producție în curs de execuție. `console.log` este inadecvat pentru aceasta; ai nevoie de jurnale structurate, metrici și alerte.

## Logging structurat (nu 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");
```

Folosește un logger structurat (pino/winston) care produce **JSON** cu câmpuri consistente. Jurnalele JSON sunt căutabile și filtrabile în instrumentele de agregare a jurnalelor, spre deosebire de șiruri `console.log` libere. Include context (ID utilizator, ID cerere) la fiecare jurnal.

## Niveluri de jurnal și ce să înregistrezi

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

## ID-urile de corelație urmăresc o cerere între servicii

```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 corelație/cerere** îți permite să reconstruiești povestea completă a unei singure cereri, chiar și între mai multe servicii — indispensabil pentru depanarea sistemelor distribuite.

## Centralizează jurnalele

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

## Monitorizare: metrici, alerte, urmărire

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

Metricile cheie de urmărit sunt **"semnalele de aur"**: latență, trafic, erori și saturație. Alertarea pe baza acestor semnale surprinde problemele înainte ca utilizatorii să le raporteze.

## De ce este important

În producție nu poți atașa un depanator — **observabilitatea prin logging și monitoring este modul în care înțelegi, debuguezi și operezi** un sistem live.

Jurnalele JSON structurate cu ID-uri de corelație fac incidentele diagnosticabile (mai ales între microservicii); agregarea centralizată face jurnalele utilizabile la scară; și monitorizarea cu metrici, verificări de sănătate, urmărire distribuită și alerte îți permite să detectezi și să răspunzi la probleme în mod proactiv, mai degrabă decât să aștepți plângerile utilizatorilor.

Constructori aceasta în (și nu o adăugi după o întrerupere) este o practică definitorie a funcționării serviciilor Node fiabile în producție.