현재 알림 룰은 대부분 "특정 문자열이 로그에 기록되었는가"에 의존하고 있어, 앱이 정지하면 로그 자체가 발생하지 않아 로그 기반 룰 전체가 조용히 Normal로 고정된다. 앱 다운 시 nginx가 @share_fallback으로 200 정적 페이지를 응답하므로 외부에서도 장애가 드러나지 않는다.
반대로 예외 1건만 발생해도 critical 알림이 즉시 발송되고 5분 뒤 RESOLVED가 이어져, 실제 장애 신호가 노이즈에 묻힌다.

작업 내용

장애 감지 공백 보완

• app-down 룰 신설 — up{job="spring-boot-app"} < 1, noDataState: Alerting, for: 2m, severity critical
• 로그 파이프라인 워치독 룰 신설 — 30분간 {job="photo-app"} 로그가 없으면 알림 (Promtail/Loki/앱 장애 감지)
• HTTP 5xx 에러율 알림 신설 (Prometheus http_server_requests_seconds_count 기반)
• 메모리 알림 신설 (호스트 + JVM 힙)
• DB 커넥션 풀 고갈 알림 신설 (hikaricp_connections_pending)
• job="maintenance" ERROR 알림 신설 — cleanup-disk.sh 실패가 현재 감지되지 않는다

노이즈 정리

• app-unhandled-500: severity critical → warning, 임계값 gt 0 → gt 3, 윈도우 5m → 15m
• app-auth-infra-failure: Apple identity token 검증 실패를 분리. 사용자의 만료 토큰 재사용만으로 critical이 발생하고 있다. AppleOAuthClient의 해당 로그를 log.warn으로 하향하는 방안을 함께 검토
• 디스크 warning 룰을 within_range [85, 92]로 변경하여 critical과 동시 발화하지 않도록 조정

신뢰성

• 모든 count_over_time 룰의 expr에 or vector(0) 추가 — 현재 매칭 0건이 NoData로 처리되어 "에러 없음"과 "관측 중단"을 구분할 수 없다
• execErrState를 KeepLast → Error로 일괄 변경
• Discord contact point를 critical / warning 채널로 분리하고, DatasourceError/DatasourceNoData 라우팅 추가

비고사항

• for: 값을 올리는 것만으로는 단발 노이즈가 해소되지 않는다. count_over_time([5m])은 로그 1건이 5분간 윈도우에 남아 조건이 연속으로 참이 되므로, for:는 발송을 지연시킬 뿐이다. 임계값(건수) 상향이 필요하다.
• p95 레이턴시 알림을 추가하려면 management.metrics.distribution.percentiles-histogram 설정이 선행되어야 한다. 현재 미설정 상태라 http_server_requests_seconds_bucket이 생성되지 않으며, photo-overview.json의 p50/p95 패널도 동일한 이유로 비어 있다.
• 배포 중 앱 재시작이 app-down을 발화시킬 수 있으므로 for: 2m 이상을 유지하거나 배포 파이프라인에서 silence 처리가 필요하다.
• node-exporter에 --path.rootfs=/rootfs가 누락되어 디스크 수치의 정확성이 보장되지 않는다. 디스크 알림 전체가 이 값에 의존하므로 함께 수정한다.
• 알림 파이프라인 자체의 장애(Discord 웹훅 만료 등)를 감지할 수단이 없다. 상시 발화하는 워치독 룰 도입을 별도로 검토한다.