관측성 3종(Kiali·Jaeger·Grafana), 왜 셋 모두 필요한가
Kiali·Jaeger·Grafana가 담당하는 지도·트레이스·지표 역할 분담과 장애 대응 순서
결론 요약
운영 장애 대응에서 관측성은 “많이 보는 것”이 아니라 올바른 순서로 보는 것이다.
Kiali는 의심 구간을 좁히는 지도, Jaeger는 요청 단위의 이동 경로, Grafana는 시스템 상태의 시간축을 담당한다.
메트릭·트레이스·토폴로지는 서로 대체 불가능하다.
로그만으로는 “어디서 문제가 시작됐는지”를 알 수 없다.
헤더 전파(context propagation)가 없으면 분산 추적은 성립하지 않는다.
셋을 동시에 쓰는 이유는 기능이 겹쳐서가 아니라 판단 단계가 다르기 때문이다.
장애 대응 기본 루틴 (순서)
결론
지도 → 현미경 → 계기판 순서를 지키지 않으면 대응 속도가 급격히 느려진다.
- Kiali: 전체 서비스 관계에서 “이상한 구간”을 찾는다
- Jaeger: 해당 구간의 요청 하나를 잡아 실제 경로를 추적한다
- Grafana: 그 현상이 언제부터, 어느 정도로 퍼졌는지 확인한다
이 순서를 거꾸로 하면 “지표는 많은데 결론이 없는 상태”에 빠진다.
Kiali로 보는 것 (토폴로지 / 트래픽 흐름)
결론
Kiali는 문제의 위치를 좁히는 도구다.
Kiali가 보여주는 핵심:
- 서비스 간 호출 관계(토폴로지)
- 요청량, 오류율, 지연 시간의 상대 비교
- 특정 엣지(서비스 간 링크)에서의 이상 징후
Kiali에서의 판단 질문:
- “느린 게 한 서비스인가, 한 연결인가?”
- “특정 경로에서만 오류가 나는가?”
- “배포 이후 패턴이 바뀌었는가?”
👉 여기서 ‘어디를 파야 할지’ 결정한다.
Jaeger로 보는 것 (트레이스 / 헤더 전파)
결론
Jaeger는 요청 하나가 실제로 밟은 발자국을 보여준다.
왜 context propagation(헤더 전파)이 필수인가
분산 시스템에서 요청은 여러 서비스를 거친다.
이때 공통 trace-id가 헤더로 전파되지 않으면:
- 서비스 A의 로그
- 서비스 B의 로그
- 서비스 C의 로그
를 하나의 요청으로 묶을 수 없다.
즉,
헤더 전파가 없으면
“분산 추적”이 아니라 “분산 로그 열람”이다.
Jaeger에서 확인하는 것:
- 어느 서비스에서 지연이 발생했는가
- 네트워크 vs 애플리케이션 지연
- 재시도/타임아웃이 중첩됐는가
Grafana로 보는 것 (지표 / 경보 관점)
결론
Grafana는 문제가 ‘언제부터·얼마나’ 퍼졌는지를 판단하는 도구다.
대표 지표 범주:
- 지연(Latency): p50 / p95 / p99
- 오류율(Error Rate): 4xx / 5xx
- 트래픽(Traffic): RPS, 요청 수
- 포화(Saturation): CPU, 메모리, 큐 길이
Grafana의 역할:
- 단발성 문제인지, 추세 문제인지 판단
- 알람 기준선 설정
- 재발 가능성 평가
시나리오 1: 특정 요청만 느려짐
1단계 — Kiali (관측 데이터)
- 전체 서비스는 정상
- A → B 경로만 지연 상승
판단
- 특정 서비스가 아니라 특정 호출 경로 문제
2단계 — Jaeger (관측 데이터)
- 동일 요청에서 B 호출 구간만 응답 지연
- 재시도 2회 발생
판단
- B의 응답 지연 + 재시도 증폭
3단계 — Grafana (관측 데이터)
- B 서비스의 p95 지연이 배포 이후 상승
- 트래픽은 동일
다음 액션
- B 서비스 최근 배포 롤백 또는 설정 수정
- 재시도 정책 완화
시나리오 2: 오류율 급증
1단계 — Kiali (관측 데이터)
- 전체 오류율 상승
- C 서비스로 들어가는 모든 경로에서 오류
판단
- 단일 병목 서비스 의심
2단계 — Jaeger (관측 데이터)
- C에서 mTLS 핸드셰이크 실패 다수
판단
- 인증서/정책 문제
3단계 — Grafana (관측 데이터)
- 오류율 급증 시점이 정책 변경 시점과 일치
다음 액션
- AuthorizationPolicy / 인증서 설정 롤백
- Control Plane 설정 전파 상태 확인
실무에서 가장 흔한 착각 5개
- 로그만 보면 된다
- 지표가 정상이면 문제 없다
- 느리면 서버 스펙 문제다
- 트레이스는 성능 튜닝용이다
- 관측 도구는 하나면 충분하다
→ 모두 장애 대응 속도를 늦추는 착각이다.
흔한 오해 3개 + 교정
오해: Kiali = 모니터링 도구
교정: 문제 위치를 좁히는 지도다.오해: Jaeger는 있으면 좋은 옵션
교정: 헤더 전파 없이는 분산 시스템을 이해할 수 없다.오해: Grafana는 대시보드 장식
교정: 장애의 시간적 맥락을 판단하는 핵심 도구다.
재학습 체크리스트
- 장애 시 확인 순서가 정해져 있는가?
- 토폴로지로 문제 범위를 줄일 수 있는가?
- 트레이스 헤더가 모든 서비스에 전파되는가?
- 재시도/타임아웃이 추적에 보이는가?
- p95/p99 지연을 해석할 수 있는가?
- 오류율과 배포 시점을 함께 보는가?
- 로그·지표·트레이스를 구분해서 쓰는가?
- “다음 액션”이 항상 도출되는가?