Observability 운영 가이드

이 문서는 운영 상태를 읽는 기본 도구인 메트릭, 로그, 트레이스를 어떤 관점으로 써야 하는지 설명하는 가이드다.

Observability를 왜 따로 보나

운영 장애는 한 화면만 보고 판단하기 어렵다.

• 메트릭은 얼마나 나빠졌는가를 보여준다.
• 로그는 무슨 일이 있었는가를 보여준다.
• 트레이스는 어디서 느려지거나 실패했는가를 보여준다.

즉 observability는 단일 도구가 아니라, 서로 다른 근거를 조합해 상태를 읽는 방식이다.

연구실 운영에서의 기본 도구 관점

관점	주로 보는 것
메트릭	CPU, 메모리, 재시작, 에러율, latency
로그	예외, 인증 실패, DB 연결 실패, 외부 API 실패
트레이스	요청이 어느 구간에서 느려지거나 끊기는지

초보자는 아래 순서로 보는 습관을 들이면 된다.

1. 메트릭으로 장애 범위를 본다.
2. 로그로 실제 오류 메시지를 본다.
3. 트레이스로 병목 위치를 본다.

자주 생기는 오해

오해	실제로는
로그만 보면 원인이 다 보인다	증상은 보여도 범위와 영향도는 메트릭이 더 잘 보여준다
메트릭만 정상이면 문제 없다	특정 사용자 흐름 오류는 로그나 트레이스가 먼저 잡을 수 있다
트레이스는 성능 문제에만 쓴다	외부 호출 실패나 특정 구간 오류 위치를 찾는 데도 유용하다

운영 판단에 연결하는 기준

운영자는 도구 이름보다 질문 순서를 먼저 가져가야 한다.

1. 전체 장애인가, 특정 서비스 문제인가
2. 언제부터 시작됐는가
3. 어떤 요청 또는 워크로드가 영향을 받는가
4. 인프라 문제인가, 애플리케이션 문제인가

이 질문에 따라 메트릭, 로그, 트레이스를 엮어 보는 것이 observability의 핵심이다.

이 문서와 하위 절차 문서의 경계

이 문서는 어떤 도구를 왜 보는가를 설명한다.

아래 같은 작업은 Manual 에서 다룬다.

• Grafana에서 어디를 먼저 보는지
• Kibana에서 어떤 필터로 좁히는지
• Tempo나 trace 도구에서 어떤 요청을 찾는지