프로덕션 Node에서 로깅과 모니터링에 어떻게 접근하나요?

Question

Accepted Answer

**로깅**은 앱이 하는 일을 기록하고, **모니터링**은 앱의 상태와 성능을 추적합니다. 둘이 합쳐져 **관측 가능성(observability)** — 실행 중인 프로덕션 시스템을 이해하고 디버깅하는 능력 — 을 제공합니다. `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");
```

일관된 필드를 가진 **JSON**을 출력하는 구조화된 로거(pino/winston)를 사용하세요. 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(correlation 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
```

주시할 핵심 메트릭은 **"golden signals"**입니다. 지연 시간(latency), 트래픽, 에러, 포화도(saturation)입니다. 이들에 대해 알림을 설정하면 사용자가 보고하기 전에 문제를 잡습니다.

## 왜 중요한가

프로덕션에서는 디버거를 붙일 수 없습니다. **로깅과 모니터링을 통한 관측 가능성이 실행 중인 시스템을 이해하고 디버깅하고 운영하는 방법**입니다.

상관관계 ID가 있는 구조화된 JSON 로그는 (특히 마이크로서비스 전반에서) 사고를 진단 가능하게 만들고, 중앙 집계는 로그를 규모에 맞게 사용 가능하게 하며, 메트릭/헬스 체크/분산 추적/알림을 통한 모니터링은 사용자가 불평하기 전에 문제를 능동적으로 감지하고 대응하게 합니다.

이를 (장애 후 덧붙이는 것이 아니라) 처음부터 구축하는 것은 신뢰할 수 있는 프로덕션 Node 서비스를 운영하는 핵심 관행입니다.