Как вы подходите к логированию и мониторингу в production Node?

Question

Accepted Answer

**Логирование** записывает, что делает ваше приложение; **мониторинг** отслеживает его здоровье и производительность. Вместе они дают вам **наблюдаемость** — способность понимать и отлаживать работающую production-систему. `console.log` недостаточен для этого; вам нужны структурированные логи, метрики и алерты.

## Структурированное логирование (не 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");
```

Используйте структурированный логгер (pino/winston), который выводит **JSON** с согласованными полями. JSON-логи поддаются поиску и фильтрации в инструментах агрегации логов, в отличие от свободных строк `console.log`. Включайте контекст (ID пользователя, ID запроса) в каждый лог.

## Уровни логирования и что логировать

```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 корреляции отслеживают запрос через сервисы

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

**ID корреляции/запроса** позволяет вам восстановить полную историю одного запроса, даже через несколько сервисов — необходимо для отладки распределённых систем.

## Централизуйте логи

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

## Мониторинг: метрики, алерты, трейсинг

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

Ключевые метрики для отслеживания — это **"золотые сигналы"**: latency, traffic, errors и saturation. Алертинг на этих сигналах перехватывает проблемы до того, как их сообщат пользователи.

## Почему это важно

В production вы не можете подключить отладчик — **наблюдаемость через логирование и мониторинг — это способ понимать, отлаживать и управлять** работающей системой.

Структурированные JSON-логи с ID корреляции делают инциденты диагностируемыми (особенно через микросервисы); централизованная агрегация делает логи масштабируемыми; мониторинг с метриками, проверками здоровья, распределённым трейсингом и алертами позволяет вам проактивно обнаруживать и реагировать на проблемы, а не дожидаться жалоб пользователей.

Встроить это с самого начала (а не добавлять после сбоя) — определяющая практика запуска надёжных production-сервисов Node.