测验：故障排查

사고 조사에서 '시작 시각을 자료로 못박는 일' 을 가장 먼저 하는 이유는?

• 시작 시각이 있어야 영향 범위를 셀 수 있고 가설마다 예측을 쓸 수 있기 때문
• 시작 시각이 있어야 경보 규칙의 for 값을 바꿀 수 있기 때문
• 시작 시각을 알아야 로그 보존 기간을 늘릴 수 있기 때문
• 시작 시각이 사후 분석 문서의 첫 줄로 정해져 있기 때문

사고 구간의 실패 건수를 셀 때 '시각으로 창을 잘라 increase 를 구하는 방법' 의 위험은?

• increase 는 게이지에만 쓸 수 있어 카운터에는 적용되지 않는다
• 창이 사고를 모자라게 덮으면 실패 건수가 통째로 빠진다
• 창 길이가 5분을 넘으면 Prometheus 가 빈 결과를 낸다
• increase 는 창 안의 최댓값만 돌려주어 합계가 되지 않는다

'한 핸들러의 코드 결함' 가설을 자료로 지우는 근거로 가장 알맞은 것은?

• 전체 5xx 중 한 핸들러가 차지한 비중이 절반을 넘었다
• 사고 구간의 전체 요청률이 평소와 거의 같았다
• 네 핸들러의 5xx 비율 최댓값이 서로 거의 같았다
• 사고 구간에 p99 지연이 오르지 않았다

남은 가설을 확증할 때 '처음 쓴 조건식으로 다시 확인하는 것' 이 왜 확증이 아닌가?

• Prometheus 가 같은 쿼리를 캐시해 값이 달라지지 않기 때문
• 같은 지표를 다시 본 것이라 새로운 정보가 하나도 더해지지 않기 때문
• 조건식은 경보용이라 조사에는 쓸 수 없게 정해져 있기 때문
• 5분 창 지표는 같은 구간에서 두 번 조회하면 값이 달라지기 때문

5분 창 비율에 임계 0.10 과 for: 10m 을 건 경보가 있다. 탐지 지연이 11분쯤 나오는 이유는?

• Alertmanager 의 group_wait 기본값이 10분이기 때문
• rate 함수가 창 길이만큼 결과를 미루어 내보내기 때문
• 비율이 임계를 넘는 데 걸리는 시간에 for 의 지속 조건이 더해지기 때문
• 평가 주기가 기본 10분이라 규칙이 그만큼 뒤에 평가되기 때문

더 짧은 창으로 경보를 바꿀 때 같은 기간 자료로 반드시 함께 확인해야 하는 것은?

• 규칙 파일의 그룹 이름이 기존 그룹과 겹치지 않는지
• 히스토그램 버킷 경계가 임계값과 맞아떨어지는지
• 규칙 평가에 걸리는 시간이 스크레이프 간격보다 짧은지
• 사고 구간 밖에서 울린 분이 얼마나 되는지