이 문서는 서비스 장애가 의심될 때 Grafana(메트릭·로그), Tempo(트레이스)를 이용해 1차 근거를 빠르게 수집하는 절차를 정리한다. 로그는 별도 UI 없이 Grafana Explore에서 데이터소스 Loki로 본다.
초기 목표는 원인을 완전히 확정하는 것이 아니라, 메트릭 문제인지 로그 문제인지 추적 문제인지 먼저 좁히는 것이다.
전후 15분 으로 잡는다.시간 범위를 안 잡고 바로 화면을 열면 unrelated noise가 많이 섞인다.
먼저 아래를 확인한다.
메트릭이 먼저 이상하면 앱 런타임 또는 인프라 문제일 가능성이 높다.
grafana.do4ai.com → Explore → 데이터소스 Loki에서 본다. 조회 기준은 아래다.
{namespace="<서비스>"}{namespace="<서비스>", pod=~"api-.*"}{namespace="<서비스>"} |~ "error|exception|traceback|timeout|connection"로그를 볼 때는 한 줄 에러만 보지 말고 직전/직후 로그까지 같이 읽는다.
추적이 가능한 서비스라면 아래를 확인한다.
trace가 없다고 바로 결론 내리지 말고, 로그와 메트릭에서 이미 충분한 근거가 있는지도 같이 본다.
kubectl 결과와 교차 검증한다sudo kubectl get pods -n <namespace>
sudo kubectl logs deploy/<deploy-name> -n <namespace> --tail=100
관측 도구 화면과 live 상태가 같은 방향을 가리키는지 확인한다.
아래 중 하나면 즉시 운영 채널에 근거와 함께 공유한다.
온보딩 트랙 3부. 관측과 SRE
이전: 트레이싱 - OpenTelemetry와 Tempo · 다음: Alerta 사용법 (Manual) · 전체 경로: 시작하기: 신입 온보딩