경보 설계, 상태 세 가지와 임계값

경보는 세 상태를 오가며 동작합니다

경보를 설정값 하나로 이해하면 오작동을 설명할 수 없습니다. 경보는 세 상태를 가집니다. 정상 상태, 경보 상태, 그리고 데이터 부족 상태입니다. 세 번째 상태가 중요합니다. 지표가 들어오지 않을 때 어떻게 취급할지 정해야 하는데, 정상으로 취급하면 서버가 아예 멈춘 상황을 놓치고, 경보로 취급하면 트래픽이 없는 야간에 계속 울립니다. 그래서 지표 성격에 따라 다르게 둡니다. 서버 생존 여부처럼 항상 들어와야 하는 지표는 데이터 부족을 경보로, 요청 수처럼 없을 수도 있는 지표는 정상으로 둡니다.

평가 기간과 연속 횟수로 잡음을 줄입니다

알림이 너무 많으면 사람이 보지 않게 되고, 결국 경보가 없는 것과 같아집니다. 잡음을 줄이는 수단은 두 가지입니다. 첫째는 평가 기간입니다. 1분마다 판정하면 순간적인 튐에 반응하므로, 5분 평균처럼 묶어 보면 일시적 변동이 걸러집니다. 둘째는 연속 횟수입니다. 연속 3회 기준을 넘을 때만 경보로 바꾸면 한 번의 이상치로 울리지 않습니다. 두 수단의 대가는 반응 지연입니다. 5분 평가에 연속 3회면 인지까지 최대 15분이 걸립니다. 그래서 지표별로 허용 지연을 먼저 정하고, 그 범위 안에서 두 값을 고릅니다.

알림 대비 조치 비율을 측정합니다

학습용 가정으로 계산합니다. 가정값은 경보 40개에서 월 알림이 600건 발생하고 그중 실제 조치가 필요했던 것이 30건이라고 두겠습니다. 유효 비율은 30을 600으로 나눈 5퍼센트입니다. 평가 기간과 연속 횟수를 조정해 알림이 120건으로 줄고 조치 건수는 그대로 30건이면 유효 비율은 25퍼센트가 됩니다. 중간 계산값인 줄어든 알림은 480건입니다. 최종 판단은 놓친 사고 수로 합니다. 조정 뒤에도 조치 건수가 30건으로 유지됐다면 놓친 것이 없다는 뜻이고, 조치 건수가 줄었다면 필요한 알림까지 걸러낸 것이므로 되돌려야 합니다.

지표 자체가 잘못된 경우가 있습니다

결론을 뒤집는 조건은 지표 선택입니다. 평가 기간을 아무리 조정해도 그 지표가 사용자 체감과 무관하면 알림은 계속 쓸모없습니다. 예를 들어 프로세서 사용률이 높아도 서비스가 정상 응답하면 조치할 일이 없습니다. 그래서 유효 비율이 낮은 경보는 설정을 고치기 전에 지표를 바꿀지 먼저 검토합니다. 두 번째 조건은 복합 조건입니다. 두 지표가 동시에 나빠질 때만 문제인 경우가 있어, 하나씩 걸면 잡음이 됩니다. 이때는 복합 경보로 묶습니다. 그래서 점검 작업은 경보 목록에 유효 비율과 지표 적절성 두 열을 적는 것으로 시작합니다.

서버 운영 실행 전 점검표

• 지표별로 데이터 부족 상태의 취급을 정했다
• 허용 지연을 먼저 정하고 평가 기간과 연속 횟수를 골랐다
• 알림 건수와 실제 조치 건수를 함께 집계했다
• 유효 비율이 낮은 경보는 지표 교체를 먼저 검토했다