44장. Observability 자체의 장애를 의심한다

대시보드가 초록이라고 서비스가 정상인 것은 아니다. metric scrape 중단, sampling 변화, log drop, trace exporter queue, 잘못된 timezone과 alert silence가 사건을 감출 수 있다. 사용자 synthetic, load balancer, application, dependency와 업무 원장의 독립 신호를 비교한다. 모든 신호가 같은 collector를 지나면 공통 실패 지점이다.

metric label에 request id·user id를 넣어 cardinality를 폭발시키지 않는다. log ingestion 지연과 event timestamp를 구분하고, trace sampling에서 오류·고가치 transaction을 보존한다. telemetry pipeline이 느려져 application thread와 disk를 소진하지 않도록 buffer·drop·backpressure 정책을 둔다. 관측 실패 alert는 같은 실패한 경로로만 보내지 않는다.

실습은 collector를 끄고 application은 정상인 경우, application 오류인데 log pipeline이 10분 늦는 경우를 나눈다. 운영자는 “데이터 없음”을 0으로 해석하지 않고 freshness와 last successful ingest를 본다. incident 중 debug logging을 늘릴 때 개인정보·disk·비용과 자동 만료를 승인한다.

release gate에는 dashboard query의 version과 owner, synthetic fixture, alert delivery test, runbook 링크를 넣는다. 사건 종료 후 실제 timeline과 telemetry timestamp가 어긋난 이유를 교정한다. 관측 도구의 초록불이 아니라 독립적인 사용자 여정과 업무 대사가 복구 판정의 최종 근거다.

마지막으로 당직 교대자는 열린 가설과 누락된 신호, 다음 확인 시각을 소리 내어 인계한다. 새 담당자가 같은 화면에서 같은 결론을 재현해야 한다.