감시 스크립트가 옛날 에러 한 줄로 영구 DOWN 되던 문제

자동화 파이프라인에 감시(heartbeat) 스크립트를 붙여 두면 마음이 편해요. 잡이 죽으면 알려 주니까요. 그런데 이번 주에 그 편한 마음이 정확히 반대로 작동했어요. 알림은 계속 울리는데 실제로는 아무 문제가 없었거든요.

로그에 error가 있으면 죽은 건가요

원래 감시 로직은 단순했어요. 대상 잡의 로그 파일을 읽고 error 문자열이 있으면 DOWN으로 판정하는 방식이요. 처음엔 잘 돌았어요. 문제는 로그가 누적된다는 거였어요.

며칠 전 한 번 실패한 기록이 로그 아래쪽에 남아 있으면, 그 뒤로 백 번을 성공해도 스크립트는 계속 DOWN이라고 말해요. 과거의 실패 한 줄이 현재 상태를 영구히 덮어쓰는 거죠. 알림을 받고 들어가 보면 잡은 멀쩡히 돌고 있고, 그게 두세 번 반복되니까 알림 자체를 안 보게 되더라고요. 감시가 감시를 망가뜨리는 구조였어요.

과거 error 한 줄 남음→이후 성공해도 계속 DOWN→알림 피로→진짜 장애를 놓침

최신 성공 신호를 같이 보게 했어요

9월 14일에 고친 방식은 이래요. error 패턴만 보는 대신, 성공 패턴도 같이 인식하도록 바꿨어요. 마지막 성공 기록이 마지막 에러 기록보다 뒤에 있으면 그 잡은 살아 있는 거예요. 이렇게 바꾸고 나서 허위 DOWN이 사라졌어요.

돌려 보니 핵심은 "에러가 있었나"가 아니라 "가장 최근 상태가 뭔가"였어요. 로그는 시간 순서가 있는 데이터인데, 저는 그걸 순서 없는 문자열 뭉치처럼 다루고 있었던 거예요. 감시 대상의 최신 성공 시각을 기준으로 삼는 쪽이 훨씬 정직해요.

안 쓰는 잡을 감시 목록에 남겨두면

같은 날짜 근처에 정리한 게 하나 더 있어요. 7월 말에 이미 세워 둔 자동 포스팅 잡이 감시 목록에 그대로 남아 있었어요. 잡은 안 도는 게 맞는데 감시는 계속 "왜 안 도냐"고 알려 주는 상황이었죠. 결국 그 항목을 감시에서 빼는 커밋을 따로 남겼어요.

이런 건 코드 문제가 아니라 목록 관리 문제예요. 기능을 중단할 땐 감시 항목도 같이 빼야 하는데, 그걸 놓치면 알림이 쓰레기가 돼요. 최근 7일 커밋 6건 중 4건이 이 감시 스크립트 한 파일에 몰렸는데, 뒤집어 보면 그만큼 감시 로직이 손이 많이 가는 자리라는 뜻이기도 해요.

• ✓성공 패턴 같이 보기
• ✓최신 상태 기준 판정
• ✓중단한 잡은 감시 목록에서 제거

배포 창까지 기다리는 항목들

새 감시 항목을 준비해 두고도 바로 켜지 않은 커밋이 두 건 있어요. 소비자·백로그 감시 항목과 선별 감시 항목인데, 코드는 적어 두되 주석 처리한 상태로 머지했어요. 배포나 머지가 끝난 다음에 주석을 풀기로 한 거예요.

감시를 먼저 켜면 아직 없는 대상에 대해 알림이 울리고, 그 알림이 또 가짜예요. 기능보다 감시가 앞서면 딱 이번에 겪은 허위 DOWN 문제가 반복돼요. 준비는 미리, 활성화는 대상이 실제로 존재할 때. 그 순서만 지켜도 알림 신뢰도가 유지돼요.

만들면서 남은 생각

감시 도구는 만드는 것보다 믿을 수 있게 유지하는 게 훨씬 어려워요. 한 번 "또 가짜겠지" 하는 마음이 생기면 그 뒤로는 진짜 장애도 놓치게 되니까요. 그래서 요즘은 감시 항목을 추가할 때마다 이 두 가지를 먼저 확인해요. 판정 기준이 최신 상태를 보는가, 그리고 대상이 사라지면 항목도 같이 사라지는가.

이런 운영 습관은 제품 쪽에도 그대로 이어져요. 플랜씨(plan-c) 같은 무료 계산기도 로그인 없이 바로 쓰는 도구인 만큼, 조용히 죽어 있는 상태를 제가 먼저 알아채야 해요. 사용자가 알려 주기 전에요. 알림이 정직해야 그게 가능하더라고요.