Hogyan közelít meg a naplózást és monitorozást a production Node-ban?

Question

Accepted Answer

**Naplózás** rögzíti, hogy az alkalmazás mit csinál; **monitorozás** nyomon követi az egészségét és teljesítményét. Együtt **megfigyelhetőséget** biztosítanak — képességet egy futó production rendszer megértésére és hibakeresésére. A `console.log` ehhez nem megfelelő; strukturált naplók, metrikák és riasztások szükségesek.

## Strukturált naplózás (nem 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");
```

Használjon strukturált naplózót (pino/winston), amely konzisztens mezőkkel **JSON**-t ad ki. A JSON naplók kereshetők és szűrhetők naplóösszesítő eszközökben, ellentétben az ingyenes `console.log` stringekkel. Tartalmazzon kontextust (user id, request id) minden naplóbejegyzésben.

## Naplózási szintek és mit naplózzon

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

## A korrelációs ID-k nyomon követik a kérést a szolgáltatások között

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

Egy **korrelációs/kérés ID** lehetővé teszi egy kérés teljes történetének rekonstruálását, még több szolgáltatás között is — elengedhetetlen az elosztott rendszerek hibakeresésében.

## Központosítsa a naplókat

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

## Monitorozás: metrikák, riasztások, nyomkövetés

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

A figyelt fő metrikák a **"arany jelzések"**: késleltetés, forgalom, hibák és telítettség. Az ezekre vonatkozó riasztások a problémákat a felhasználók bejelentése előtt észlelik.

## Miért fontos

Production környezetben nem csatlakoztathat hibakeresőt — **a megfigyelhetőség naplózáson és monitorozáson keresztül az a módja annak, hogy megértsék, hibakereséseket végezzenek és üzemeltetsenek** egy futó rendszert.

Strukturált JSON naplók korrelációs ID-kkel diagnosztizálhatóvá teszik az incidenseket (különösen mikroszolgáltatások között); a központosított aggregáció használható naplókat tesz skálán; és a monitorozás metrikákkal, egészség-ellenőrzésekkel, elosztott nyomkövetéssel és riasztásokkal lehetővé teszi a problémák proaktív észlelését és reagálást ahelyett, hogy a felhasználók panaszkodnának.

Enneka felépítése (nem később, egy kimaradás után) a megbízható termelési Node-szolgáltatások futtatásának meghatározó gyakorlata.