Quiz: Alert Design

CPU 사용률에 페이지 알림을 걸면 안 되는 이유로 가장 정확한 것은?

• CPU 메트릭은 카디널리티가 높아서
• CPU 90% 인데 응답이 정상이면 아무 일도 없는 것이고, CPU 40% 인데 응답이 5초면 심각한 사고이므로 두 경우 모두 틀리기 때문
• CPU 는 게이지 타입이라 rate 함수를 걸 수 없어 알림을 만들 수 없기 때문에
• CPU 는 클라우드에서 자동으로 조정되므로

'오탐이 많으니 for 를 30분으로 늘리자'가 안티패턴인 이유는?

• 프로메테우스가 30분 이상의 for 를 지원하지 않아서
• 메모리 사용량이 늘어서
• 탐지가 30분 늦어지고, 사고가 25분 만에 끝나면 알림이 아예 울리지 않기 때문
• for 는 표현식이 참인 총 시간을 세므로 의미가 없어서

하루 400건의 알림 중 실제 조치로 이어진 것이 4건일 때 가장 큰 위험은?

• 알림 기록이 쌓여 스토리지 비용이 커진다
• 양이 많아 알림 전송이 지연된다
• '일단 무시하고 나중에 확인'이 합리적인 전략이 되어 버린다
• 규칙이 많아 평가가 느려진다

Alertmanager 의 group_by 에 instance 를 넣으면?

• 파드 수만큼 알림이 온다
• 알림이 전혀 오지 않는다
• 억제 규칙이 동작하지 않는다
• repeat_interval 이 무시된다

알림 라우팅에서 '일단 슬랙 채널에만 보내자'는 절충안이 최악인 이유는?

• 슬랙 API 요금이 비싸서
• 슬랙은 억제 규칙을 지원하지 않아서
• 아무도 책임지지 않고 아무도 끄지 않는 4단계가 생기기 때문
• 슬랙 메시지는 감사 로그에 남지 않아서

사일런스가 30일 이상 유지된 알림은 어떻게 해야 하는가?

• 사일런스를 90일로 연장한다
• 심각도를 page 로 올려 주의를 끈다
• 임계값을 두 배로 올린다
• 삭제한다 — 사일런스는 알림이 틀렸다는 가장 정직한 신호이기 때문