ダッシュボードの目的の確認

장애 대응용 상태 대시보드의 패널 수가 계속 늘어나는 구조적인 이유는?

• 지표 수집 비용이 계속 떨어져서
• Grafana 가 패널 수를 제한하지 않아서
• 붙일 근거는 쉽고 지울 근거는 만들기 어려워서
• 패널이 많을수록 장애를 빨리 찾을 수 있어서

5xx 를 개수가 아니라 비율로 그리는 이유는?

• 트래픽이 늘면 개수도 같이 늘어 사용자가 겪는 실패 확률과 어긋나서
• 비율이 저장 공간을 덜 차지해서
• 개수는 카운터라 rate 를 쓸 수 없어서
• 비율은 시계열이 하나라 그래프가 단순해서

구글 SRE 의 네 가지 골든 시그널에 해당하지 않는 것은?

• 지연 — 요청이 얼마나 걸리는가
• 트래픽 — 초당 얼마나 들어오는가
• 오류 — 얼마나 실패하는가
• 배포 빈도 — 얼마나 자주 배포하는가

상태(health) 대시보드에 CPU 사용률 패널을 맨 위에 두면 안 되는 이유는?

• CPU 지표는 수집 주기가 길어 최신 값이 아니라서
• CPU 가 80% 라는 사실만으로는 사용자가 겪는 일을 알 수 없어서
• 노드마다 값이 달라 하나로 합칠 수 없어서
• 컨테이너 환경에서는 CPU 지표를 신뢰할 수 없어서

대시보드를 만든 뒤 해 볼 '인시던트 테스트' 는?

• 패널마다 쿼리 실행 시간을 재서 느린 것을 찾는다
• 일부러 장애를 내고 알림이 울리는지 본다
• 호출받은 사람이 되어 30초 안에 정상 여부를 말할 수 있는지 본다
• 모든 패널의 데이터가 비어 있지 않은지 확인한다