이 문서는 운영 상태를 읽는 기본 도구인 메트릭, 로그, 트레이스를 어떤 관점으로 써야 하는지 설명하는 가이드다.
운영 장애는 한 화면만 보고 판단하기 어렵다.
얼마나 나빠졌는가를 보여준다.무슨 일이 있었는가를 보여준다.어디서 느려지거나 실패했는가를 보여준다.즉 observability는 단일 도구가 아니라, 서로 다른 근거를 조합해 상태를 읽는 방식이다.
| 관점 | 주로 보는 것 |
|---|---|
| 메트릭 | CPU, 메모리, 재시작, 에러율, latency |
| 로그 | 예외, 인증 실패, DB 연결 실패, 외부 API 실패 |
| 트레이스 | 요청이 어느 구간에서 느려지거나 끊기는지 |
초보자는 아래 순서로 보는 습관을 들이면 된다.
| 오해 | 실제로는 |
|---|---|
| 로그만 보면 원인이 다 보인다 | 증상은 보여도 범위와 영향도는 메트릭이 더 잘 보여준다 |
| 메트릭만 정상이면 문제 없다 | 특정 사용자 흐름 오류는 로그나 트레이스가 먼저 잡을 수 있다 |
| 트레이스는 성능 문제에만 쓴다 | 외부 호출 실패나 특정 구간 오류 위치를 찾는 데도 유용하다 |
운영자는 도구 이름보다 질문 순서를 먼저 가져가야 한다.
이 질문에 따라 메트릭, 로그, 트레이스를 엮어 보는 것이 observability의 핵심이다.
이 문서는 어떤 도구를 왜 보는가를 설명한다.
아래 같은 작업은 Manual 에서 다룬다.