EC2 CPU 경보를 만들었는데 상태가 ‘데이터 부족’이다. 알림도 오지 않는다. 이 상태만 보고 설정 실패라고 단정하기는 이르다. 경보는 지표가 들어오는지, 조건을 만족했는지, 알림을 받을 준비가 됐는지를 차례로 봐야 한다.
CloudWatch 경보의 데이터 부족은 무엇을 뜻할까?
경보는 CPUUtilization처럼 시간에 따라 모인 값(메트릭)을 평가한다. 새로 만든 경보에 아직 평가할 데이터가 충분하지 않으면 ‘데이터 부족’ 상태가 나타날 수 있다. 이것은 CPU가 0%라는 뜻도, 서버가 안전하다는 뜻도 아니다.
예를 들어 EC2 한 대의 평균 CPU 사용률을 5분 단위로 보고, 80% 초과를 조건으로 둔다. 아래 숫자는 동작을 설명하기 위한 가상 관측값이다.
| 평가 시점 | 5분 평균 CPU | 조건 > 80% | 판단 |
|---|---|---|---|
| 아직 값 없음 | — | 평가 불가 | 데이터 부족 |
| 첫 관측 | 18% | 거짓 | 정상 쪽 |
| 부하가 걸린 뒤 | 86% | 참 | 경보 쪽 |
실제 상태 전환은 경보의 평가 기간·필요한 데이터 수 설정에 따라 달라진다. 표의 한 줄이 모든 경보에서 즉시 상태 전환을 보장한다는 뜻은 아니다.
아래 그림은 지표 값이 임계선을 넘는 순간과, 값 자체가 없어 평가하지 못하는 구간을 분리한다.
경보가 움직이지 않을 때 어디부터 확인할까?
먼저 경보가 올바른 EC2 인스턴스의 CPUUtilization을 보고 있는지 확인한다. 비슷한 이름의 다른 인스턴스나 잘못된 차원을 선택했다면 그래프부터 예상과 다를 수 있다. 다음으로 통계가 평균인지, 기간과 임계값이 의도와 맞는지 본다. > 80은 정확히 80과 다르다.
그래프에 값이 있어도 경보가 원하는 시점에 바뀌지 않으면 평가 조건을 다시 확인한다. 특정 한 지점만 높았는지, 필요한 평가 구간을 채웠는지 구분해야 한다. 경보 기록의 상태 변경 이유를 읽으면 ‘값이 없어서 못 판단했는지’와 ‘값은 있지만 조건을 충족하지 않았는지’를 나누기 쉽다.
경보 상태가 바뀌었는데 이메일은 왜 안 올까?
경보 상태와 알림 전달은 별도 단계다. SNS 주제를 알림 작업에 연결했는지, 이메일 구독이 ‘확인 대기 중’이 아니라 ‘확인됨’인지 확인한다. 받은편지함만 새로 고치기보다 경보 상태 → 알림 작업 → SNS 구독 상태 순서로 보는 편이 원인을 빨리 좁힌다.
검증을 위해 실제 서버에 CPU 부하를 주는 방법도 있지만, 운영 서비스에서 무심코 실행하면 요청이 느려질 수 있다. 격리한 실습 환경이 아니라면 경보 설정과 관측값을 먼저 검토하고, 부하 테스트는 영향 범위를 정한 뒤 수행해야 한다. 경보 하나가 곧 장애의 원인을 설명하는 것도 아니다. CPU가 높게 측정됐다면 이후에는 애플리케이션 상태와 사용자 영향을 별도로 확인한다.
핵심 요약
‘데이터 부족’은 아직 경보가 판단할 값이 충분하지 않다는 뜻이지 정상 판정이 아니다. 대상 지표 → 통계·기간·임계값 → 상태 변경 이유 → SNS 구독 확인 순서로 점검하자. 경보 전환과 알림 도착을 서로 다른 단계로 다루면 실패 지점을 찾기 쉽다.
