NestJS 배포와 관측성

모니터링과 로깅 시스템 구축: SLI, 로그, trace 연결

관측 시스템은 화면을 예쁘게 만드는 일이 아니라 판단 시간을 줄이는 일입니다. 지표, 로그, trace가 같은 장애 질문에 답하는지 봅니다.

requestId 한 장애 질문 metrics logs trace alert SLO 임계값 runbook 복구 판단
01

SLI와 로그 필드 맞추기

latency, error rate, saturation, throughput을 endpoint/service 단위로 정의하고 로그 필드와 trace attribute 이름을 맞춥니다.

SLI
02

exporter와 transport 배치

Prometheus metrics, OpenTelemetry trace, structured logger transport를 Nest middleware/interceptor에서 수집해 module별 소유자를 남깁니다.

collector
03

알림 공백과 노이즈 재현

5xx spike, DB latency, queue backlog, log ingestion 중단을 만들어 알림 누락과 과다 알림을 각각 확인합니다.

alert
04

장애 판단 자료 묶기

대시보드, 알림 규칙, trace sample, 로그 검색 쿼리를 runbook에 연결해 장애 중 어떤 화면을 볼지 정합니다.

runbook
지표
모니터링 목표는 SLI와 SLO 이름으로 표현 API latency p95, error rate, DB pool usage처럼 사용자가 체감하는 지표와 시스템 포화 지표를 분리합니다.
SLI/SLO
수집
로그와 trace는 requestId로 합류해야 한다 Logger transport, interceptor, OpenTelemetry context가 같은 id를 써야 한 요청의 controller, provider, DB 호출을 이어 볼 수 있습니다.
trace id
알림
Error Budget 검증은 알림 임계값과 연결 SLO가 깨지는 속도에 맞춰 경고/긴급 알림을 나누고, silence와 escalation 기록까지 남깁니다.
알림 규칙

SLI 로그 trace 증거

대시보드 신호 latency, error, saturation, traffic이 서비스/endpoint 단위로 보이고 최근 배포 버전과 함께 비교됩니다.
로그 검색 requestId나 userId로 structured log와 trace를 같이 열어 느린 provider나 실패한 dependency를 찾습니다.
알림 품질 장애 리허설에서 알림이 너무 늦거나 너무 자주 오지 않는지 확인하고 임계값 변경 기록을 남깁니다.

SLI 로그 trace 관측 점검

질문: SLI, structured log, trace가 같은 requestId로 장애 질문에 답하는가
순서: 지표 정의 -> Nest interceptor/logger/trace 수집 -> 알림 임계값과 runbook 리허설
위험: 대시보드만 있고 로그/trace가 연결되지 않으면 장애 중 어느 provider가 느린지 찾는 시간이 길어집니다.