모니터링 알림, 같은 폭주는 6시간에 한 번만 보내요

자동화 감시 알림이 늘면서 섞여 들어온 헛경보와 중복 알림을 어떤 기준으로 걸러 냈는지, 알림 한 통의 모양과 보내는 곳까지 다시 정한 이야기예요.

모니터링 알림을 켜 두었는데, 어느 날부터 알림을 열어 보지도 않고 지운 적 있으세요? 저는 혼자 여러 서비스를 운영하고 있어서, 자동화 작업이 잘 도는지 지켜보는 스크립트를 하나씩 붙여 왔어요. 감시하는 게 늘어난 만큼 알림도 늘었어요.

그런데 알림을 하나씩 뜯어보니 제가 손댈 게 없는 알림이 섞여 있었어요. 최근 3주 동안 알림 쪽을 몇 군데 손봤어요. 헛경보 하나를 없앴고, 반복되는 알림은 묶었고, 알림 한 통의 모양과 보내는 곳도 다시 정했어요.

좀비 프로세스만 치운 실행이 왜 실패로 찍혔을까요?

reaper라고 부르는 스크립트가 있어요. 자동화 작업 가운데 끝나지 않고 계속 붙잡혀 있는 폭주 프로세스를 찾아서 정리하는 스크립트예요. heartbeat는 reaper를 비롯한 작업들이 제대로 돌았는지 지켜보고요.

처음 막힌 건 여기였어요. reaper가 좀비 프로세스만 치우고 끝난 실행을 heartbeat가 실패로 세고 있었어요. 좀비 프로세스는 이미 종료됐는데 부모 프로세스가 회수해 가지 않아서 프로세스 목록에 이름만 남은 상태예요. CPU나 메모리를 쓰고 있는 게 아니에요.

그러니까 좀비만 치운 날은 reaper가 원래 할 일을 한 날이에요. 장애가 난 게 아니고요. 그런데 이게 실패로 찍히면 알림이 오고, 열어 보면 할 게 없어요. 이런 일이 몇 번 반복되면 진짜 실패 알림도 같은 무게로 보이기 시작해요.

그래서 좀비만 정리하고 끝난 실행은 실패로 세지 않도록 바꿨어요. 폭주 프로세스를 실제로 잡았을 때는 지금도 알림이 와요.

같은 폭주를 볼 때마다 다시 알릴 필요는 없었어요

두 번째 문제는 같은 알림이 반복된다는 거였어요. 폭주 프로세스가 바로 정리되지 않으면 reaper는 다음번에 돌 때 같은 프로세스를 또 발견해요. 발견할 때마다 알림을 보내면 같은 내용이 계속 쌓여요.

규칙은 두 가지로 정했어요. 같은 폭주라도 단계가 바뀌면 바로 다시 알려요. 단계가 그대로면 6시간 안에는 다시 보내지 않아요. 상황이 나빠지면 바로 알아야 하지만, 이미 알고 있는 상황을 계속 다시 들을 필요는 없으니까요.

그림 1.

폭주 하나가 시간순으로 다시 발견될 때 발송·보류가 갈리는 지점(reaper 재알림 규칙 기준)

알림은 무슨 일이 있었는지 알리는 데서 끝나면 안 되고, 그래서 내가 뭘 하면 되는지까지 보여 줘야 해요.

알림 한 통에서 가장 중요한 건 둘째 줄이었어요

알림 내용도 다시 짰어요. 제게 오는 브리프 알림 템플릿을 고쳐서, 첫 줄에는 무슨 일이 있었는지, 둘째 줄에는 제가 할 일을 쓰도록 했어요.

휴대폰 알림은 앞쪽 몇 줄만 보고 넘길 때가 많아요. 할 일이 본문 아래쪽에 묻혀 있으면 앱을 열어서 끝까지 읽어야 하고, 그게 귀찮아서 미루게 돼요. 할 일이 둘째 줄에 있으면 미리보기만 보고도 판단할 수 있어요.

그림 2.

휴대폰 알림 미리보기에서 보이는 줄 비교(브리프 알림 템플릿 수정 전/후)

메시지를 만드는 부분과 어디로 보낼지 정하는 부분도 나눴어요. 둘 다 상태를 따로 저장하지 않는 작은 함수예요. 전에 뭘 보냈는지 기억하지 않으니까 같은 입력을 넣으면 항상 같은 결과가 나오고, 그래서 테스트하기 쉬워요. 6시간 제한처럼 기억이 필요한 판단은 reaper 쪽에 따로 두었어요.

알림은 어디로 한 번만 보내야 할까요?

알림은 텔레그램 한 곳으로만 보내요. 텔레그램 발송이 실패했을 때만 슬랙으로 보내고요. 같은 알림이 두 군데로 가면 어디서 확인했는지 헷갈리고, 결국 둘 다 대충 보게 되거든요.

보낼 때마다 영수증도 남겨요. 어디로 보냈는지, 성공했는지를 적어 두는 기록이에요. 알림이 안 왔을 때 보낼 일이 없었던 건지 보냈는데 실패한 건지는 이 기록이 있어야 구분할 수 있어요. 알림이 조용하다는 것만으로는 아무 일도 없는 건지, 알림이 고장 난 건지 알 수 없으니까요.

그림 3.

이벤트부터 영수증까지 알림 발송 경로(텔레그램 우선, 실패할 때만 슬랙)

바꾼 내용을 한 번에 보면 이래요.

바꾼 것	지금 기준	이유
좀비만 정리한 실행	실패로 세지 않음	원래 할 일이라 따로 할 게 없음
같은 폭주 재알림	단계가 바뀌면 바로, 같은 단계면 6시간 안에는 보내지 않음	악화는 놓치지 않고 반복은 줄임
알림 템플릿	둘째 줄에 할 일	미리보기만 보고 판단
보내는 곳	텔레그램 1곳, 실패하면 슬랙	확인할 곳을 하나로
발송 기록	보낼 때마다 영수증	조용한 것과 고장 난 것을 구분

직접 해 보려면

• 최근에 받았지만 아무것도 하지 않은 알림을 하나 골라 보세요. 그 알림을 만든 판정이 원래 해야 할 일을 실패로 세고 있지 않은지 확인해 볼 만해요.
• 같은 대상의 재알림 규칙을 하나 정해 보세요. '상태가 바뀌면 바로, 그대로면 N시간 뒤' 정도로 시작해도 충분해요.
• 알림 템플릿 둘째 줄에 할 일을 넣고, 보낼 때마다 성공했는지 한 줄씩 기록해 보세요.

재알림 규칙을 코드로 쓰면 대략 이런 모양이에요. 실제 코드를 그대로 옮긴 건 아니고 판단 순서만 적었어요.

def should_realert(prev, now):
    if prev is None:
        return True  # first time seeing this runaway
    if now.stage != prev.stage:
        return True  # stage changed: alert right away
    return now.at - prev.sent_at >= timedelta(hours=6)  # same stage: at most once per 6h

이걸로도 안 되는 것

• 6시간이 적당한 값인지는 아직 몰라요. 같은 단계에 오래 머무는 폭주는 늦게 알아챌 수 있어서, 실제로 놓치는 게 생기는지 더 봐야 해요.
• 텔레그램과 슬랙이 둘 다 막히면 알림은 오지 않아요. 영수증은 실패를 기록할 뿐 대신 알려 주지는 않으니, 누군가 그 기록을 열어 봐야 의미가 있어요.