Logs, Metrics, Traces — 셋 다 못 하면 이 순서로
관찰 가능성 3종을 한꺼번에 못 깔 때, 실제로 어디부터 손대야 하는지 정리.
셋 다 한다는 건 거짓말
스택 새로 세울 때마다 “o11y 완전체 구축” 계획이 나온다. OpenTelemetry Collector, Prometheus, Jaeger, 중앙 로그 집계까지 한 스프린트 안에. 막상 2주 지나면 Collector 설정 YAML 만 커지고 실제로 쓰는 건 kubectl logs -f 한 줄이다.
솔직히 말하면 세 가지를 동시에 잘 운영하는 팀은 많지 않다. 우선순위 없이 시작하면 셋 다 어중간하게 남는다.
우선순위: Logs → Metrics → Traces
1순위 — Logs
- 장애 첫 5분, 실제로 여는 건 로그다.
- 구조화(JSON)만 지켜도 grep → jq 로 웬만한 건 판독 가능.
- 최소 요건: timestamp / level / service / trace_id(없어도 우선 OK) / message.
- 2026년 기준 CloudWatch Logs Insights, Loki 둘 다 JSON 이면 쿼리 비용 차이가 꽤 난다. 비정형 로그는 나중에 후회한다.
2순위 — Metrics
- 로그는 “무슨 일”을 알려주고, 메트릭은 “언제부터 이상했는지”를 알려준다.
- RED(Rate / Errors / Duration) 세 개만 먼저. USE는 인프라 여유 생기면 추가.
- Prometheus scrape interval 15s, 보존 15일이면 초반엔 충분하다. 더 늘리다 디스크 사고 난 적 있음.
- 알림은 메트릭 붙고 나서. 로그 기반 알림은 noise 비율이 높다.
3순위 — Traces
- 분산 시스템 아니면 솔직히 급하지 않다.
- 모놀리스 + RDS 조합이면 slow query log + p99 latency 메트릭으로 대부분 해결된다.
- traces 가 진짜 빛나는 순간: 서비스 3개 이상 걸치는 요청, DB 아닌 외부 API 병목, 비동기 큐 구간 추적. 그 전에 붙이면 overhead 만 생긴다.
- 붙일 때는 처음부터 trace_id 를 로그에도 박아 두면 나중에 logs ↔ traces 연결이 공짜로 된다.
다음 한 가지
이번 주 로그에 trace_id 필드 하나 추가한다 — traces 없어도 나중을 위해.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.