여러 서버 배치를 감시하는 관제 대시보드 직접 만들기 (설계 포인트)

여러 서버에 흩어진 배치가 잘 돌고 있는지 매번 SSH로 접속해 로그를 까보는 건 금방 한계가 옵니다. 관제 대시보드를 직접 만들면서 잡았던 핵심 설계 포인트를 정리합니다. 특정 시스템 얘기가 아니라, 배치를 여러 대에서 돌릴 때 공통으로 마주치는 설계 문제들입니다.

1. 에이전트 + 중앙 콘솔 (원시 로그는 옮기지 않는다)
각 서버에 가벼운 에이전트를 두고, 그 서버 로그는 그 자리에서 스캔해 "요약"만 중앙 DB로 보냅니다. 원시 로그를 중앙으로 다 끌어오면 용량도 네트워크도 부담이라, 서버에서 세어서 결과만 전송하는 게 훨씬 가볍습니다. 콘솔은 DB만 읽어 대시보드를 그립니다.

- 에이전트: 서버 로컬에서 스캔 후 요약만 전송
- 중앙 DB: 각 서버 요약을 모음
- 콘솔: DB만 보고 렌더(원시 로그 접근 X)

2. 데드맨 스위치: "에러 없음"이 아니라 "침묵"을 잡는다
관제의 가장 흔한 함정입니다. 에러 로그만 감시하면, 배치가 아예 죽어서 아무 로그도 안 남을 때를 못 잡습니다. 진짜 위험한 건 "에러"가 아니라 "보고가 끊긴 것"입니다. 그래서 로그 파일의 마지막 수정 시각(mtime)으로 신선도를 봅니다. 예상 주기에 허용 지연을 더한 시간을 넘겨도 보고가 없으면, 그건 배치가 멈춘 것이고 최악의 상황입니다. 이 침묵을 알람으로 바꾸는 게 데드맨 스위치입니다.

- 에러 감시만으론 "배치 자체가 죽은" 상황을 못 잡음
- 로그 mtime(마지막 활동)으로 신선도 판정
- 주기+허용지연 초과 = 미보고 = RED(최악)

3. 스트리밍 로그 스캔 (대용량에도 메모리 안 터짐)
로그 파일을 통째로 메모리에 올려서 처리하면 수 기가짜리 로그에서 바로 터집니다. 파일을 한 줄씩 읽으며 패턴을 세면, 메모리 사용량이 파일 크기와 무관해져서 아무리 큰 로그도 안전합니다. 결과는 grep으로 세는 것과 같지만, 관제 로직 안에 넣을 수 있습니다.

- 파일 전체 로드 = 대용량에서 OutOfMemory
- 한 줄씩 읽어 카운트 = 메모리 O(한 줄)
- 로그가 커져도 관제가 안 죽음

4. 무코드 설정: 점검 추가에 재배포가 필요 없게
"어떤 로그의 어떤 패턴을 임계 몇으로 볼지"를 코드에 박아두면, 점검 하나 추가할 때마다 코드를 고치고 다시 배포해야 합니다. 이걸 설정(DB나 JSON)으로 빼두면, 새 점검은 설정 한 줄이면 끝이고 재배포가 필요 없습니다. 운영자가 코드를 몰라도 점검을 추가할 수 있습니다.

- 점검 항목(로그/패턴/임계)을 코드 아닌 설정으로
- 새 점검 = 설정 한 줄, 재배포 없음
- 로직은 그대로, 항목만 데이터로 늘어남

5. 정리: 관제는 '침묵'과 '규모'를 견뎌야 한다
관제 도구를 만들 때 놓치기 쉬운 두 가지가 침묵과 규모입니다. 에러만 보면 죽은 배치를 놓치고(그래서 데드맨 스위치), 로그를 통째로 읽으면 큰 로그에서 스스로 죽습니다(그래서 스트리밍). 여기에 점검을 설정으로 빼두면 오래 굴러도 손이 덜 갑니다. 화려한 기능보다 이 세 가지가 관제의 뼈대입니다.

- 침묵 감시(데드맨) + 스트리밍 + 무코드 설정 = 뼈대
- 에이전트는 가볍게, 콘솔은 DB만
- 관제 자신도 안 죽게(가벼움/예외 견디기)

함께 보면 좋은 글:
- 로그에서 원하는 것만 뽑는 grep 패턴 (배치·에러 추적 실전)

여기까지 여러 서버 배치를 감시하는 관제 대시보드의 핵심 설계(데드맨 스위치, 스트리밍 스캔, 무코드 설정)에 대해서 작성해봤습니다. 여기까지 읽어주셔서 감사합니다!