CloudWatch의 데이터 부족을 정상값 0으로 단정하지 마세요. 계속 보내야 하는 지표인지, 오류가 있을 때만 보내는 지표인지부터 구분하고 누락 데이터 처리와 경보 이력을 확인합니다.
적용 환경: AWS CloudWatch 일반 지표 경보, 공식 문서 2026-10-23 확인. 문서 기반 가이드이며 실제 서비스 설정 변경·시험 결과가 아닙니다.
1. 원인: 값이 없는 것과 정상값은 다릅니다
수집 장애로 지표가 끊길 수도 있고, 이벤트가 있을 때만 값을 내보내는 설계일 수도 있습니다. 먼저 계정·리전·네임스페이스·차원이 실제 자원과 맞는지 확인합니다. 지표를 잘못 선택한 문제를 누락 처리 설정으로 덮지 않습니다.
2. 해결 순서: 지표의 의미에 맞춰 선택합니다
| 값 | 누락값을 평가할 때의 의미 |
| notBreaching | 임계값을 넘지 않은 것으로 취급 |
| breaching | 임계값을 넘은 것으로 취급 |
| ignore | 현재 경보 상태 유지 |
| missing | 평가 범위가 전부 누락되면 데이터 부족 |
설정은 실제 점이 부족해 보충이 필요한 평가에서 의미가 있습니다. 충분한 실제 데이터가 확보되면 누락 처리 옵션이 사용되지 않을 수 있으므로 그래프의 빈 구간만 보고 최종 상태를 계산하지 마세요.
연속 발행이 전제인 지표와 드물게 발생하는 오류 지표에 같은 규칙을 적용하지 않습니다. 주기·평가 기간·필요 데이터 수와 현재 누락 처리값을 한 기록에 모은 뒤 원하는 정상/이상 의미를 정합니다.
3. 확인: 경보 상태와 알림 도착은 별개입니다
경보 이력의 상태 전환 시각과 원인을 지표 시간대에 맞춰 대조합니다. 알림 연결이 필요한 경우에는 대상 SNS 등 실제 동작이 존재하는지, 수신 경로가 작동하는지도 별도로 검증합니다. 경보가 ALARM으로 바뀌었다는 사실만으로 담당자가 알림을 받았다고 보고하지 않습니다.
시험은 승인된 별도 경보와 영향 없는 대상에서 수행합니다. 실제 자원 종료·재시작 동작이 연결된 운영 경보를 단순 테스트용으로 강제 변경하지 않습니다. 설정을 바꾸기 전 원래 값을 보존하고 문제가 생기면 되돌릴 조건을 정합니다.
4. 주의와 FAQ
breaching을 고르면 누락에 더 안전한가요? 지표 의미와 연결된 동작에 따라 오탐이 위험할 수 있습니다. EC2 중지·종료·재부팅·복구 동작 경보에는 공식 문서의 missing 권고와 ALARM 조건을 확인하세요.
ignore는 정상 처리인가요? 정상으로 바꾸는 것이 아니라 현재 상태를 유지하는 선택입니다.
모든 종류의 경보에 같은 표를 적용하나요? 이 글은 일반 지표 경보의 출발점입니다. 특수 네임스페이스·수식·쿼리 경보의 별도 조건은 해당 공식 문서를 확인합니다.
공식 출처와 이어 읽기
'소프트웨어개발' 카테고리의 다른 글
| S3 만료 후 용량이 남는 이유: 삭제 마커와 비현재 버전 구분 (0) | 2026.10.24 |
|---|---|
| curl은 성공인데 HTTP 404일 때: 종료 코드와 응답 상태를 따로 확인 (0) | 2026.10.23 |
| git diff가 비어 있는데 변경이 남을 때: 작업 트리·인덱스·HEAD 비교 (0) | 2026.10.23 |
