Kaip jūs žiūrite į registravimą ir stebėjimą gamybiniame Node?

Question

Accepted Answer

**Registravimas** fiksuoja, ką daro jūsų programa; **stebėjimas** seka jos sveikatą ir efektyvumą. Kartu jie suteikia **stebėjimą** — gebėjimą suprasti ir derinti veikiantį gamybinį sistemą. `console.log` tam nepakanka; jums reikalingi struktūriniai žurnalai, metrika ir perspėjimai.

## Struktūrinis registravimas (ne 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");
```

Naudokite struktūrinį žurnalo įrankį (pino/winston), kuris išveda **JSON** su nuosekliais laukais. JSON žurnalai yra paieškomi ir filtruojami log agregavimo įrankyje, skirtingai nei laisvos formos `console.log` eilutės. Įtraukite kontekstą (vartotojo ID, prašymo ID) į kiekvieną žurnalą.

## Žurnalo lygiai ir ką registruoti

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

## Koreliacijos ID sekia prašymą per paslaugas

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

**Koreliacijos/prašymo ID** leidžia jums atkurti pilną vieno prašymo istoriją, netgi keliose paslaugose — neatkeičiamybė suderinti paskirstytas sistemas.

## Centralizuoti žurnalus

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

## Stebėjimas: metrika, perspėjimai, sekimas

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

Pagrindinė metrika, kurią reikia stebėti, yra **"auksiniai signalai"**: latencija, srautas, klaidos ir sodrumas. Perspėjimai apie tai pagauna problemas prieš nei vartotojai jas pranešti.

## Kodėl tai svarbu

Gameyboje negalite prijungti derintuvo — **stebėjimas per registravimą ir stebėjimą yra jūsų būdas suprasti, derinti ir valdyti** veikiantį sistemą.

Struktūriniai JSON žurnalai su koreliacijos ID suteikia incidentams diagnostiką (ypač kelių mikroservisų atveju); centralizuota agregacija padaro žurnalus naudingus dideliu mastu; o stebėjimas su metrika, sveikatos patikromis, paskirstytu sekimu ir perspėjimais leidžia proaktyviai aptikti ir reaguoti į problemas, o ne po to, kai vartotojai skundžiasi.

Šio sukūrimas iš pradžių (o ne prieš išsiveržimą) yra apibrėžiantis patikimo gamybinio Node paslaugų eksploatavimo praktika.