로그·메트릭·트레이스, 셋 다 못 하면 이 순서로
관찰 가능성 3종을 동시에 못 깔 때 어디서 시작할지 실전 우선순위.
셋 다 하겠다고 했다가
처음엔 늘 그렇다. OpenTelemetry 도입 회의, Grafana 대시보드 설계, 트레이싱 샘플링 전략… 2주 후엔 아무것도 운영에 안 붙어 있다.
막상 해보면 시간은 늘 부족하고 엔지니어는 한 명이다. 그래서 순서를 정했다.
내가 쓰는 순서
1순위: 로그
- 코드 변경 없이 붙일 수 있다
- 장애 당일 “뭐가 일어났나” 재현에 유일한 증거
- 최소 조건: structured JSON, timestamp UTC, request_id
- 3줄짜리 winston/pino 설정이면 다음날부터 쓸 수 있음
2순위: 메트릭
- 로그는 사건을 설명하고, 메트릭은 추세를 잡는다
- p95 응답시간이 서서히 올라가는 건 로그로 못 잡는다
- Prometheus + Grafana 초기 세팅 4시간. 그 이후로는 알림이 먼저 깨워준다
- 대시보드 욕심 금지. 처음엔 에러율·지연·처리량 세 개만
3순위: 트레이스
- 분산 시스템 아니면 솔직히 급하지 않다
- 서비스 2개짜리 구조에서 트레이싱 먼저 깔다가 로그도 없는 상황 실제로 봤음
- 마이크로서비스 3개 이상, 또는 “어느 서비스에서 느린지 모르겠다” 소리가 나올 때 도입
왜 이 순서냐
로그 없이 장애 보고서를 쓴 적 있다. 기억과 추측으로. 다시는 안 한다.
메트릭 없이 배포하면 “느려진 것 같은데?”가 채널에 먼저 뜬다. 같은 상황 두 번 겪은 뒤 Prometheus 달았다.
트레이스는 없어도 버텼다. 있으면 편하지만 없다고 밤에 호출받지는 않는다.
한 줄 원칙: 재현 가능성 → 추세 인지 → 경로 추적 순으로.
다음 한 가지
이번 분기 안에 로그에 trace_id 필드 하나 추가한다. 트레이스 없어도 로그끼리 묶이면 절반은 된다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.