PID 감시만으로 발견할 수 없었던 문제
연계 모듈은 프로세스가 종료되면 이상을 판단하기 쉽다. 더 어려운 경우는 PID가 존재하고 로그도 추가되지만 실제 업무가 다음 공정으로 넘어가지 않는 상태였다.
같은 실패나 공정을 반복하면 운영체제 관점에서는 정상 실행 중이다. 단순 프로세스 확인과 로그 수정 시각만으로는 계속 기록되는 반복 로그 때문에 이상을 놓칠 수 있었다.
설정 중심의 독립형 구조로 변경
기존 감시는 대상별 고정 메서드 중심으로 구성돼 있었다. 법인이나 모듈이 추가될 때마다 검사 코드를 수정해야 했고 일부 판단은 업무 DB 상태에 의존했다.
이를 독립형 Spring Boot 모니터링 애플리케이션으로 다시 구성했다. 감시 대상은 Java 메서드가 아니라 설정으로 정의하고, 로그와 프로세스 정보만으로 독립 실행할 수 있게 했다.
최신 기준 마스터에서 확인되는 범위는 다음과 같다.
- 24개는 4개 법인의 설정 대상 수다.
- 24개 전체가 실제 운영에 반영됐다는 의미가 아니다.
- 운영 적용 이력이 확인된 범위는 본사·싱가포르 9개, 유럽 5개, 일본 2개로 총 16개 대상이다.
- 나머지는 설정 존재와 운영 적용을 구분한다.
감시 방식을 대상 특성에 맞게 분리
설정 대상은 로그를 생성하는 모듈과 자체 로그가 없는 프로세스로 나눠 감시했다. 기존 글에 있던 방식별 세부 개수는 최신 경력 마스터에 산출 기준이 없어 제거했다.
- 로그 기반 대상은 마지막 기록 시각과 최근 반복 패턴을 확인한다.
- 로그가 없는 대상은 프로세스 실행 여부를 확인한다.
- 업무 DB 상태 확인을 필수 조건으로 두지 않아 모니터링 자체의 독립성을 유지한다.
반복 패턴으로 업무 정체를 판별
로그가 일정 시간 갱신되지 않으면 중단 가능성이 높다. 하지만 같은 실패가 반복되면 로그는 계속 갱신되므로 수정 시각만으로 부족하다.
최근 로그의 필요한 범위만 읽고, 같은 처리 패턴이 일정 기준 이상 반복되는지를 함께 확인했다. 실제 설정 키와 임계값은 공개하지 않는다.
- 최근 로그 기록 자체가 멈췄는가
- 로그는 기록되지만 같은 처리 패턴만 반복되는가
두 번째 조건을 추가해 PID와 수정 시각 검사만으로는 보이지 않던 업무 정체를 감지할 수 있게 했다.
설정 기반 다법인 구조
대상별 설정에는 공개용으로 다음 역할만 설명한다.
- 대상 별칭과 감시 방식
- 로그 또는 프로세스 위치
- 감지 기준과 알림 수신 범위
- 법인별 언어와 메일 환경
실제 설정 키, 파일명, 프로세스명과 내부 경로는 공개하지 않는다. 새 법인이나 대상이 추가될 때 검사 코드를 복제하지 않고 설정과 메시지 범위를 확장할 수 있게 했다.
중복 알림과 장애 독립성
대상별 이상 상태와 알림 이력을 관리해 최초 감지 후 같은 장애의 중복 알림을 억제하고, 이상이 계속될 때만 정해진 정책에 따라 리마인더를 발송했다.
스케줄이 겹칠 때 같은 대상의 상태가 충돌하지 않도록 동시 접근을 보완했고, 한 대상의 검사 실패가 다른 대상의 검사와 알림까지 중단시키지 않도록 처리 범위를 분리했다.
운영 적용 범위와 명확한 한계
이 애플리케이션은 감시와 알림을 담당하며 감시 대상 모듈을 자동으로 재기동하지 않는다.
실행 감시 스크립트는 대상 모듈이 아니라 모니터링 애플리케이션 자체가 종료됐을 때 다시 실행하기 위한 용도다. 실제 스크립트와 JAR 파일명은 공개하지 않는다.
반복 패턴 검사는 미리 정의한 패턴 안에서 정체를 찾는 방식이므로 새로운 형태의 이상을 자동으로 이해하지 않는다. 외부 시스템이나 네트워크의 근본 원인까지 해결하는 기능도 아니다.
정리
프로세스가 존재한다와 업무가 진행된다는 다른 상태다. 이 사례에서는 감시 대상을 관측 가능한 증거에 따라 나누고, 로그 기반 대상에는 수정 시각과 반복 패턴을 함께 적용했다. 24개 설정 대상과 확인된 16개 운영 적용 대상을 분리해 설명하는 것이 현재 근거에 맞는 범위다.