Como você aborda logging e monitoramento em Node em produção?

Question

Accepted Answer

**Logging** registra o que seu aplicativo faz; **monitoring** rastreia sua saúde e desempenho. Juntos, eles lhe dão **observabilidade** — a capacidade de entender e depurar um sistema de produção em execução. `console.log` é inadequado para isso; você precisa de logs estruturados, métricas e alertas.

## Logging estruturado (não 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");
```

Use um logger estruturado (pino/winston) que produza **JSON** com campos consistentes. Logs em JSON são pesquisáveis e filtráveis em ferramentas de agregação de logs, diferentemente de strings `console.log` livres. Inclua contexto (ID de usuário, ID de solicitação) em cada log.

## Níveis de log e o que registrar

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

## IDs de correlação rastreiam uma solicitação entre serviços

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

Um **ID de correlação/solicitação** permite que você reconstrua a história completa de uma única solicitação, mesmo entre vários serviços — indispensável para depurar sistemas distribuídos.

## Centralize os logs

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

## Monitoramento: métricas, alertas, rastreamento

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

As métricas-chave a observar são os **"sinais de ouro"**: latência, tráfego, erros e saturação. Alertar sobre esses sinais detecta problemas antes que os usuários os relatem.

## Por que isso importa

Em produção você não pode anexar um depurador — **observabilidade através de logging e monitoramento é como você entende, depura e opera** um sistema ao vivo.

Logs JSON estruturados com IDs de correlação tornam os incidentes diagnósticáveis (especialmente entre microsserviços); agregação centralizada torna os logs utilizáveis em escala; e monitoramento com métricas, verificações de saúde, rastreamento distribuído e alertas permite que você detecte e responda a problemas de forma proativa em vez de aguardar reclamações dos usuários.

Construir isso (em vez de implementar após uma interrupção) é uma prática definidora de operação de serviços Node em produção confiável.