이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 로그, 메트릭, 트레이스를 어떤 순서로 연결하면 장애 원인 후보를 줄일 수 있는가?
- 같은 시간대, 같은 요청, 같은 버전을 묶는 증거는 무엇인가?
- 관측 신호가 서로 모순될 때 어떤 판단을 피해야 하는가?
개요
로그, 메트릭, 트레이스는 따로 보면 각각의 조각이다.
장애 분석에서는 이 조각을 같은 시간대, 같은 요청, 같은 버전으로 묶어야 한다.
메트릭은 영향 범위와 추세를 보여 준다.
로그는 구체적인 사건과 error code를 보여 준다.
트레이스는 요청 경로와 느린 구간을 보여 준다.
세 신호가 연결될 때 원인 후보를 빠르게 줄일 수 있다.
분석 순서
장애가 감지되면 먼저 메트릭으로 범위를 본다.
error rate 증가
latency p95/p99 증가
request volume 변화
DB connection pool saturation
queue size 증가그 다음 로그에서 대표 요청과 error code를 찾는다.
마지막으로 trace에서 느린 span이나 실패 span을 확인한다.
반대로 개별 error log 하나만 보고 전체 장애라고 판단하면 영향 범위를 과대평가할 수 있다.
시간대 맞추기
관측 신호는 시간대가 맞아야 한다.
배포 이벤트, alert 발생, metric 상승, error log, trace sample 시간을 같은 기준으로 본다.
15:02 deploy start
15:05 version 1.8.3 traffic 25%
15:07 p95 latency 상승
15:08 ORDER_DB_TIMEOUT log 증가
15:08 trace slow span: SELECT order_items이런 timeline은 장애 원인과 상관관계를 구분하는 출발점이다.
요청 단위 연결
한 요청을 연결하려면 correlation id와 trace id가 필요하다.
correlation_id=c-7f1
trace_id=4bf92f3577b34da6a3ce929d0e0e4736
endpoint=POST /api/orders
version=1.8.3-abc1234로그에는 correlation id와 trace id가 있어야 한다.
트레이스에는 service, span, error status가 있어야 한다.
메트릭에는 version, endpoint, status 같은 제한된 label이 있어야 한다.
버전 단위 연결
배포 직후 장애에서는 version이 중요하다.
전체 error rate가 아니라 새 version의 error rate가 높은지 봐야 한다.
로그에도 version field가 있어야 하고, /actuator/info로 실제 실행 version을 확인할 수 있어야 한다.
Trace attribute에도 app version이 있으면 old/new version 비교가 쉬워진다.
Version 정보가 없으면 배포와 장애의 관계가 추측으로 남는다.
예시 분석
metric:
http_server_requests p95 POST /api/orders 240ms -> 1200ms
status 5xx 0.1% -> 1.2%
log:
error_code=ORDER_DB_TIMEOUT
correlation_id=c-7f1
trace:
root span POST /api/orders 1800ms
slow span SELECT order_items 1500ms
version:
1.8.3-abc1234이 경우 첫 원인 후보는 controller 자체보다 DB query 또는 connection pool 대기다.
로그만 보면 DB timeout이고, 메트릭만 보면 latency 증가이며, trace까지 봐야 느린 구간이 좁혀진다.
운영 체크리스트
- metric으로 영향 범위와 시작 시간을 먼저 확인했는가?
- log에서 대표 error code와 correlation id를 확보했는가?
- trace에서 느린 span과 error span을 확인했는가?
- service version과 배포 이벤트를 같은 timeline에 올렸는가?
- 로그와 trace가 같은 trace id로 연결되는가?
- metric label이 endpoint/status/version 단위 분석을 지원하는가?
- 분석 결과가 incident report에 재사용 가능한 형태인가?
장애 신호
- metric은 나빠졌는데 관련 log를 찾을 수 없다.
- error log는 많지만 전체 요청 대비 비율을 모른다.
- trace에는 느린 span이 있지만 어떤 version에서 발생했는지 모른다.
- 로그 시간대와 metric dashboard timezone이 다르다.
- correlation id는 있지만 trace id가 없어 경로를 못 찾는다.
- alert에는 metric 이름이 없고 dashboard screenshot만 있다.
안전한 완화 조치
신호가 모순되면 하나의 도구만 믿고 결론내리지 않는다.
Metric과 log의 시간대, query filter, version label을 먼저 맞춘다.
Trace sample이 없으면 같은 증상을 재현하거나 sampling 정책을 확인한다.
장애 중 dashboard를 새로 많이 만들기보다 기존 핵심 지표로 범위를 좁힌다.
분석 중 발견한 누락 field는 장애 후 backlog로 남긴다.
인프라 담당자와 공유할 자료
문제: 주문 생성 latency와 5xx 증가
기간: 2026-07-01 15:07~15:22 KST
version: order-api 1.8.3-abc1234
metric: POST /api/orders p95 240ms -> 1200ms, 5xx 1.2%
log sample: correlation_id=c-7f1, error_code=ORDER_DB_TIMEOUT
trace sample: trace_id=4bf92f..., slow span SELECT order_items 1500ms
가설: DB query plan 또는 connection pool 대기
요청: DB slow query와 pool metric 확인연결 분석 공유는 metric, log, trace를 한 묶음으로 제공해야 한다.
실전 팁
- 먼저 metric으로 규모를 보고, log로 사건을 보고, trace로 경로를 본다.
- 장애 timeline은 같은 timezone으로 맞춘다.
- version field는 배포 직후 분석의 핵심이다.
- Screenshot보다 query와 field 이름을 남긴다.
- 관측 누락은 장애 후 개선 항목으로 반드시 남긴다.
위험 신호!
- 로그 한 줄만 보고 전체 장애 원인을 확정한다.
- 평균 latency만 보고 tail latency를 무시한다.
- trace sample 하나로 전체 영향 범위를 판단한다.
- 배포 version 없이 장애를 분석한다.
- correlation id와 trace id가 서로 연결되지 않는다.
확인 질문
확인 질문
- 장애 분석에서 metric을 먼저 보는 이유는 무엇인가?
- 영향 범위, 시작 시간, 추세를 먼저 알아야 개별 로그나 trace가 전체 문제인지 일부 사례인지 판단할 수 있기 때문이다.
- 로그와 trace를 연결하는 핵심 식별자는 무엇인가?
- correlation id와 trace id이며, 가능하면 service version도 함께 연결해야 한다.
- 관측 신호가 부족할 때 장애 중 피해야 할 대응은 무엇인가?
- 부족한 증거를 추측으로 메우고 원인을 확정하거나, 무리하게 새 설정을 많이 바꿔 기존 증거를 흐리는 대응이다.