관측 가능성은 시스템이 외부로 내보내는 정보를 이용해 내부 상태와 문제 원인을 이해할 수 있는 성질이다. 서비스가 살아 있는지 확인하는 것을 넘어, 특정 사용자의 요청이 왜 느리거나 실패했는지 설명할 수 있도록 계측 데이터를 연결한다. OpenTelemetry의 관측 가능성 안내
서로 다른 신호
| 신호 | 도움이 되는 질문 |
|---|---|
| 메트릭 | 오류율이나 응답 시간이 얼마나 변했는가 |
| 로그 | 그 시점에 어떤 사건이 발생했는가 |
| 트레이스 | 한 요청이 어떤 처리 단계를 거쳤는가 |
트레이스는 여러 작업 구간을 나타내는 스팬을 연결해 요청 흐름을 보여준다. 스팬과 맥락 전달은 트레이스 문서에 자세히 설명되어 있다. 메트릭은 전체 경향을 살피기 좋고, 로그는 구체적인 사건의 맥락을 남긴다. 어느 하나의 양만 늘리기보다 서로 연결할 식별자와 의미를 정하는 것이 중요하다.
검색 지연 예시
위키 검색이 느려졌다면 먼저 지연이 전체 요청에서 나타나는지 확인한다. 이후 느린 요청의 트레이스로 검색 API, 데이터베이스, 외부 호출 중 시간을 쓰는 구간을 좁히고 관련 로그로 오류나 재시도를 살핀다. OpenTelemetry는 이러한 데이터를 생성하고 전달하는 공통 도구로 사용할 수 있다.
운영 질문에서 시작하기
CPU 사용량이 낮다는 사실만으로 사용자가 정상적으로 문서를 발행한다고 판단할 수는 없다. 발행 성공률, 완료까지 걸린 시간처럼 실제 사용자 목적과 연결된 지표를 정의한다. 배포 직후에는 전달 파이프라인의 버전 정보와 변화 시점을 연결하면 원인 탐색에 도움이 된다.
많은 데이터를 무제한 저장한다고 관측 가능성이 완성되지는 않는다. 계측 비용과 저장 기간을 정하고, 토큰이나 개인정보가 로그에 남지 않게 설계해야 한다. 수집하지 않은 요청이나 샘플링에서 제외된 구간은 관측의 빈틈이므로, 데이터에 없는 사건을 없었다고 단정하지 않는다.