CloudWatch 알람, 데이터가 안 들어오면 어떤 상태가 될까

AWS의 지표와 로그를 모으는 서비스인 CloudWatch에서 알람을 만들면, 지표를 고르고 기간과 임곗값을 정하는 단계가 나온다.
그 아래 추가 설정에는 값이 들어오지 않은 구간을 어떻게 처리할지 고르는 항목이 있다.

기본값 그대로 두고 넘어가기 쉬운 칸이다.
그런데 알람이 조용할 때, 오류가 없어서 조용한 것인지 아무것도 재지 못해서 조용한 것인지를 이 칸이 정한다.

지표와 알람이 판단하는 방식

지표는 시간에 따라 쌓이는 숫자의 줄이다.
로드밸런서가 받은 요청 수나 오류 응답 수를 보내면 그 숫자들이 하나의 지표로 쌓인다.

CloudWatch 알람은 지표를 정해 둔 길이의 기간마다 값 하나로 묶어서 판단한다.
이 길이를 기간(period)⁠이라고 하고, 기간 하나에서 나온 값을 데이터 포인트라고 한다.

임곗값은 위반으로 볼 기준선이다.
로드밸런서의 5XX 오류 응답 수를 1분마다 더해서, 그 합이 10을 넘으면 위반으로 보는 식이다.

알람은 최근 데이터 포인트 몇 개를 보고, 그 가운데 몇 개가 위반이면 경보로 바꿀지도 미리 정해 둔다.
예를 들어 최근 세 개가 모두 위반일 때만 경보로 바꾸게 할 수 있다.

알람의 상태는 셋이다.
임곗값 안쪽이면 OK, 바깥이면 ALARM이다.
세 번째인 INSUFFICIENT_DATA는 알람이 막 만들어졌거나, 지표를 쓸 수 없거나, 상태를 정할 만큼 데이터가 모자랄 때의 상태다.

알람은 상태가 바뀔 때만 걸어 둔 동작을 실행한다.
ALARM이 되면 알림을 보내도록 걸어 뒀다면, 알람이 데이터 부족 상태에 머무는 동안에는 그 알림이 가지 않는다.

대시보드에 올린 알람은 ALARM일 때 빨간색, 데이터 부족일 때 회색으로 보인다.
회색 알람은 조용해 보여도 지금 아무것도 판단하지 못하고 있다는 표시다.

값이 빠지는 경우

값이 빠지는 데는 몇 가지 이유가 있다.
연결이 끊기거나 서버가 멈출 때도 있고, 처음부터 간헐적으로만 값을 보내도록 만들어진 지표도 있다.

앞의 둘은 장애이고 마지막은 정상 동작이다.
그런데 알람이 받는 것은 셋 다 똑같이 비어 있는 구간이다.

마지막 경우는 생각보다 가까이에 있다.
로드밸런서는 요청이 흐를 때만 CloudWatch에 지표를 보내고, 로드밸런서가 직접 만든 5XX 오류 응답 수는 0이 아닐 때만 보고한다.
오류가 없는 시간에는 0조차 찍히지 않아 그 구간이 비어 있다.

0과 빈칸은 다르다

0은 세어 봤더니 없었다는 뜻이고, 빈칸은 세지 못했거나 보낼 값이 없었다는 뜻이다.
그래프에서 0은 바닥에 붙은 점으로 찍히고, 빈 구간에는 아무것도 찍히지 않는다.

오류처럼 드문 지표는 평소에도 빈 구간이 많다.
그래서 값이 끊긴 것이 장애 때문인지 오류가 없어서인지, 그래프만 보고는 구별하기 어렵다.

빈 구간을 다루는 네 가지 방법

이 차이를 알람에 알려 주는 것이 처음에 본 그 칸이다.
알람마다 빈 데이터 포인트를 어떻게 볼지 정하는데, 고를 수 있는 값은 넷이고 따로 정하지 않으면 missing이 기본값이다.

설정	빈 데이터 포인트를	놓치기 쉬운 것
notBreaching	임곗값 안쪽으로 봄	수집이 끊겨도 알람이 조용함
breaching	임곗값을 넘은 것으로 봄	원래 드문 지표면 한가할 때마다 울림
ignore	무시하고 지금 상태를 유지	끊기기 직전 상태에 계속 머묾
missing (기본값)	평가 범위가 모두 비면 데이터 부족으로 바꿈	ALARM에 걸어 둔 알림은 가지 않음

이 설정이 값이 하나 빠질 때마다 끼어들지는 않는다.
CloudWatch는 판정에 필요한 개수보다 더 많은 데이터 포인트를 과거로 거슬러 가져오는데, 이 범위를 평가 범위라고 한다.

평가 범위 안에 실제 값이 필요한 만큼 있으면 빈칸은 건너뛰고 실제 값만으로 판정한다.
설정이 빈칸을 채우는 것은 실제 값이 모자랄 때뿐이다.

오류 수가 1 이상이면 위반으로 보고, 최근 세 구간으로 판단하는 알람이다. 수집이 멈춰 그 세 구간에 값이 없다. 알람 상태는 빈 값을 다루는 방식에 따라 달라진다.

000 없음없음없음 평가 구간

알람 상태 데이터 부족

평가 구간이 모두 비면 기본값인 누락 처리에서는 데이터 부족, 정상으로 보면 정상, 위반으로 보면 경보가 되고, 무시하면 직전 상태가 유지된다.

평가 방식을 단순화한 예시다. 실제 알람은 평가할 값을 더 이전 구간까지 찾아보기도 해서, 일부만 비었을 때는 결과가 달라질 수 있다.

어떤 지표에 무엇을 고를까

CloudWatch의 누락 데이터 처리 문서에 실린 예가 좋은 기준이 된다.
계속 값을 보내는 지표로 배포 롤백용 알람을 만든다면, 빈칸은 뭔가 잘못됐다는 신호일 수 있으니 위반으로 보라고 한다.
오류가 날 때만 값이 생기는 지표라면 빈칸을 정상으로 보는 쪽을 권한다.

반대 방향의 경고도 있다.
인스턴스를 멈추거나 재부팅하는 동작을 건 EC2 알람은 빈칸을 missing으로 두고 ALARM일 때만 동작하게 하라고 권한다.
서버는 멀쩡한데 지표 전송만 잠깐 끊겨도 알람이 데이터 부족으로 갈 수 있기 때문이다.

예외도 하나 적혀 있다.
DynamoDB 지표에 건 알람은 기본값부터 ignore여서, 값이 비면 지금 상태를 그대로 유지한다.

ECS 배포와 이어진 알람은 더 따져 봐야 한다.
ECS는 지정한 알람이 ALARM 상태가 되면 배포를 실패로 보고 되돌릴 수 있다.
새 태스크가 아예 뜨지 못해 지표가 비면 알람은 데이터 부족에 머물고, 배포는 실패로 잡히지 않는다.

자동 확장의 목표 추적 정책도 같은 영향을 받는다.
정책이 쓰는 알람이 데이터 부족이면 새 데이터가 들어올 때까지 태스크 수를 바꾸지 않는다.

살아 있다는 신호는 따로 둔다

오류 지표 하나로 오류가 늘었는지와 수집이 살아 있는지를 함께 잡으려고 하면 어긋난다.
오류 지표는 오류가 늘었는지만 보게 하고, 빈칸은 정상으로 둔다.

서비스나 수집이 살아 있는지는 늘 값이 들어와야 하는 지표로 따로 본다.
앱이 1분마다 살아 있다는 값을 보내는 하트비트 지표를 두고, 그 알람에서는 빈칸을 위반으로 본다.

데이터 부족 상태로 바뀔 때 실행할 동작도 따로 걸 수 있다.
중요한 알람이라면 이 상태에도 알림을 걸어서, 지표가 끊긴 사실을 ALARM과 따로 알 수 있게 해 둔다.