타임아웃으로 오인되는 거짓 알림 제거

슬롯 점검 스크립트에서 bash 프로세스가 죽거나 응답 없을 때 무조건 timeout으로 판정하던 버그를 고쳤다. 이제는 프로세스 상태와 무관하게 실제 발행수를 재확인한 뒤 최종 판정한다.

배경: 모니터링의 거짓 양성

슬롯 점검이라는 건 보통 사전에 할당된 슬롯들이 정확히 발행되고 있는지 주기적으로 모니터링하는 배치 작업이다. 내 경우 bash 서브프로세스로 실발행수를 확인하고, 기대값과 실제값을 비교하는 구조였다.

문제는 bash가 여러 이유로 crash 하거나 hanging 상태에 빠질 수 있다는 것. OS 리소스 부족, 데드락, 또는 예상 못한 시그널. 기존 코드는 bash 응답이 없으면 즉시 timeout으로 판정하고 알림을 쏘버렸다. 그런데 대부분의 경우 실제로는 슬롯이 정상적으로 발행되었음에도 일반적인 모니터링 도구나 대시보드에선 "timeout 실패" 로 표시되는 상황이 반복됐다.

이런 거짓 양성은 여러 문제를 야기한다:
- 온콜 팀이 불필요한 페이징 받음
- 실제 장애와 거짓 알림을 구분하는 노력 증가
- 모니터링 신뢰도 하락 (울던 늑대 증후군)
- 대시보드에 빨간불이 떠도 사실 아무 일도 없음

해결: bash 상태와 발행 상태 분리

핵심 아이디어는 간단하다: 프로세스 상태와 비즈니스 상태를 분리해서 판정하는 것.

기존 (X) :
bash 응답 없음 → timeout 판정 (끝)

개선 (O) :
bash 응답 없음 → 실발행수 DB 재확인 → 
  • 실발행수 == 기대값 → 성공 (bash 관계없음)
  • 실발행수 < 기대값 → 실패 (true timeout)

bash가 죽었다는 것은 조회 채널의 문제일 뿐이다. 실제 슬롯이 발행됐는지는 독립적으로 확인할 수 있다. 이 로직을 추가하면:

• False positive 제거: bash가 hang 해도 실제 발행이 완료됐으면 성공으로 기록
• True failure 감지: bash가 살아있어도 실발행수가 모자르면 여전히 fail 잡음
• 신뢰성 향상: 모니터링이 더 정확해짐

회고: 외부 상태 조회의 독립성

이런 유형의 버그는 "조회 메커니즘의 실패 = 상태 실패"라는 암묵적 가정에서 비롯된다. 특히 배치/모니터링 스크립트에서 자주 본다.

• 외부 API timeout → 즉시 fail (재시도 or 상태 재확인 없음)
• 데이터베이스 쿼리 hang → 데이터 손실로 판정
• 워커 프로세스 crash → 작업 실패로 판정

사실 더 견고한 설계는:
1. 조회 경로 다원화: 주 경로 실패 시 백업 경로로 상태 재확인
2. 타임스탬프/로그 기반 판정: 프로세스 상태보다 실제 발행 로그나 결과물로 판정
3. 비동기 조정: 프로세스 완료와 상태 저장을 명확히 분리

이 경우 bash 대신 직접 DB를 조회하거나, 슬롯 발행 로그를 별도로 보관하면 더욱 견고해진다. 다음에 비슷한 모니터링을 설계할 땐 처음부터 "프로세스가 응답 없어도 상태를 확인할 방법이 있나"를 먼저 생각하려고 한다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 홍삼 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.