감시 스크립트가 영구 DOWN에 빠진 이유

자동화를 붙여놓고 마음이 놓이는 순간이 있어요. 잡이 돌고, 감시 스크립트가 붙어 있고, 문제가 생기면 알림이 오니까요. 그런데 9월 14일에 정반대 상황을 만났습니다. 아무 문제 없이 돌아가는 잡이 계속 DOWN으로 찍혀 있었거든요.

로그를 보는 방식이 문제였어요

감시 스크립트는 원장 로그에서 error가 들어간 줄을 찾아 상태를 판정하고 있었어요. 단순하고 빠르죠. 처음 붙일 때는 그걸로 충분해 보였고요.

문제는 로그가 누적된다는 점이었어요. 어느 시점에 error 한 줄이 기록되면, 그 줄은 지워지지 않아요. 그 뒤로 100번을 성공해도 감시 스크립트는 여전히 그 옛날 한 줄을 보고 DOWN을 외칩니다. 잡은 멀쩡한데 대시보드만 빨간 상태인 거예요.

로그에 error 1줄이후 성공 계속감시는 error만 탐색영구 DOWN

이게 왜 고약하냐면, 알림의 신뢰도를 갉아먹어요. 늘 빨갛게 떠 있는 항목은 며칠 지나면 눈에 안 들어옵니다. 진짜 장애가 났을 때 그 알림을 흘려보내게 되죠.

fix(heartbeat): 리믹스 원장 감시에 success 패턴 추가 — 커밋 제목 그대로예요. error만 찾지 말고, 성공 패턴도 함께 보게 만들었어요. 최근 기록에 성공 흔적이 있으면 과거 error 한 줄로 DOWN 판정을 내리지 않도록요.

직접 고쳐 보니 핵심은 "무엇을 찾을까"가 아니라 "언제 기준으로 볼까"였어요. 감시는 과거 전체가 아니라 최근 상태를 봐야 하는 거였습니다. 로그 전체 스캔은 역사 조회지 건강 검진이 아니니까요.

재밌는 건 이게 그 주의 유일한 감시 수정이 아니었다는 점이에요. 최근 7일 커밋 6건 중 감시 스크립트 한 파일만 4번 손댔습니다.

돌려 보니 두 번의 허위 DOWN이 원인은 달랐어요. 하나는 이미 멈춘 잡을 계속 지켜본 것, 다른 하나는 판정 기준이 과거에 묶인 것. 그런데 증상은 똑같았습니다. 거짓 빨간불.

9월 14일 커밋 두 건이 공통으로 준비라는 단어를 쓰고 있어요. 새 감시 항목을 바로 켜지 않고 주석 상태로 넣어둔 거예요. 배포 창이 열리거나 관련 작업이 합쳐진 뒤에 주석을 풀도록요.

적용해 봤더니 이 방식이 편했습니다. 아직 존재하지 않는 대상을 감시하면 또 허위 DOWN이 나요. 그럼 방금 고친 문제를 그대로 다시 만드는 셈이고요. 코드는 미리 넣어두되 스위치는 나중에 켜는 게, 두 번 일하지 않는 방법이었어요.

혼자 개발하다 보면 감시 스크립트를 부속품처럼 다루게 돼요. 본 제품이 아니니까요. 그런데 이번 주에 한 파일을 4번 고치면서 생각이 바뀌었습니다. 감시가 틀리면 판단이 틀립니다. 잘못된 초록불은 문제를 숨기고, 잘못된 빨간불은 알림을 무디게 만들어요.

라이프케어로그에서 플랜씨나 플랜엘 같은 서비스를 운영할 때도 같은 원칙을 적용하고 있어요. 상태를 보는 눈이 흐려지면, 그 뒤의 모든 결정이 흐려지니까요. 감시 대상을 늘리기 전에 먼저 물어봅니다. 이 판정 기준, 과거에 묶여 있지 않나요?

혼자서 여러 자동화를 돌리고 있다면 한 번쯤 로그 판정 로직을 열어보시길 권해요. error만 찾고 있다면, 아마 어딘가 영구 DOWN이 조용히 켜져 있을 겁니다. 🔍