관찰 가능성: 로그, 메트릭, 트레이스

유용한 관찰 가능성은 질문에 빠르게 답한다. 모델 없이 모든 것을 수집하면 비용과 잡음이 늘고 장애 대응은 느려진다.

각 신호에 역할 부여하기

메트릭은 시스템이 바뀌었음을 드러낸다. 트레이스는 시간이 어디에 쓰였는지 보여준다. 로그는 로컬 맥락 안에서 특정 결정을 설명한다. 세 가지 모두 같은 요청 식별자와 도메인 식별자를 중심으로 설계한다.

사용자 경로를 계측하기

사용자가 경험하는 경계에서 시작한다. 요청률, 오류율, 지연 시간이 그 기준이다. 그런 다음 그 신호의 변화를 설명할 수 있는 의존성을 계측한다. 이렇게 하면 대시보드가 실제 영향에 고정된다.

request_id=af31 order_id=9231 outcome=payment_declined reason=insufficient_funds

알림을 실행 가능하게 만들기

모든 호출은 증상, 현재 사용자 영향, 가능성 높은 소유 팀, 첫 번째 진단 링크를 포함해야 한다. 받는 사람이 행동할 수 없다면 그것은 알림이 아니라 대시보드여야 한다.

카디널리티 제어하기

고카디널리티 식별자는 메트릭 라벨이 아니라 트레이스와 로그에 있어야 한다. 작고 검토된 라벨 어휘는 쿼리를 예측 가능하게 만들고 비용을 제한한다.