Jak podchodzisz do logowania i monitorowania w produkcyjnym Node?

Question

Accepted Answer

**Logowanie** rejestruje, co robi Twoja aplikacja; **monitoring** śledzi jej stan zdrowia i wydajność. Razem dają Ci **obserwabilność** — zdolność do zrozumienia i debugowania działającego systemu produkcyjnego. `console.log` jest niewystarczający do tego; potrzebujesz ustrukturyzowanych logów, metryk i alertów.

## Dlaczego to ważne

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

Używaj strukturyzowanego rejestratora (pino/winston), który wyprowadza **JSON** ze spójnymi polami. Dzienniki JSON są przeszukiwalne i filtrowalne w narzędziach agregacji dzienników, w przeciwieństwie do wolnych `console.log` ciągów. Dołącz kontekst (ID użytkownika, ID żądania) do każdego dziennika.

## Poziomy logowania i co logować

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

## Identyfikatory korelacji śledzą żądanie między usługami

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

**Identyfikator korelacji/żądania** pozwala ci odtworzyć pełną historię pojedynczego żądania, nawet między wieloma usługami — niezbędne do debugowania systemów rozproszonych.

## Scentralizuj dzienniki

```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: metryki, alerty, śledzenie

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

Kluczowe metryki do monitorowania to **"sygnały złote"**: latencja, ruch, błędy i nasycenie. Alertowanie na tych sygnałach wyłapuje problemy, zanim zgłoszą je użytkownicy.

## Dlaczego to ważne

W produkcji nie możesz podłączyć debuggera — **obserwabilność poprzez logowanie i monitoring to sposób, w jaki rozumiesz, debugujesz i obsługujesz** działający system.

Ustrukturyzowane dzienniki JSON z identyfikatorami korelacji sprawiają, że incydenty są diagnozowalne (szczególnie między mikroserwisami); scentralizowana agregacja sprawia, że dzienniki są użyteczne na dużą skalę; a monitoring z metrykami, sprawdzeniami zdrowia, rozproszonym śledzeniem i alertami pozwala ci proaktywnie wykrywać i reagować na problemy zamiast czekać, aż użytkownicy się skarżą.

Wbudowanie tego (a nie dodawanie go po awarii) jest definiującą praktyką uruchamiania niezawodnych produkcyjnych usług Node.