서버 모니터링 알림을 켰는데 왜 장애를 놓칠까요?

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

서버 모니터링 화면은 온통 초록색인데 사용자는 접속이 느리다고 항의하고, 담당자가 상황을 확인했을 때는 이미 장애가 끝난 뒤인 경우가 있습니다. 모니터링 도구를 설치하고 알림까지 연결했는데도 장애를 놓쳤다면 장비 성능보다 먼저 감시 항목, 임계값, 통보 경로가 실제 서비스 흐름에 맞게 설계됐는지 살펴봐야 합니다.

서버는 애플리케이션과 데이터를 제공하는 핵심 자원이지만, 서버 자체가 살아 있다는 사실만으로 서비스 정상 여부를 보장할 수는 없습니다. 서버의 기본 개념을 확인해 보면 요청에 응답하고 자원을 제공하는 역할이 핵심이라는 점을 알 수 있습니다. 결국 모니터링도 장비의 전원 상태가 아니라 사용자의 요청이 제대로 처리되는지까지 확인해야 합니다.

서버가 켜져 있으니 정상이라고 판단하지 마세요

CPU와 메모리만 보면 애플리케이션 장애를 놓칩니다

한 회사는 CPU 사용률 80%, 메모리 사용률 90%를 알림 기준으로 설정한 뒤 관제가 끝났다고 생각했습니다. 그러나 실제 장애 원인은 로그인 API가 연결하는 인증 데이터베이스의 응답 지연이었습니다. 웹 서버 CPU는 25%에 불과했고 메모리도 여유가 있었지만, 사용자는 로그인 버튼을 누른 뒤 20초 넘게 기다려야 했습니다. 자원 지표만 감시한 탓에 서비스 장애가 정상 상태로 표시된 실패 사례입니다.

서버 모니터링은 최소한 장비, 운영체제, 애플리케이션, 사용자 경로의 네 층으로 나눠야 합니다. 예를 들어 웹 서비스라면 프로세스 실행 여부뿐 아니라 특정 URL의 HTTP 상태 코드, 응답 시간, 로그인 또는 조회 같은 핵심 기능의 성공 여부를 확인해야 합니다. 네트워크 장비도 단순한 포트 업·다운 외에 오류 패킷, 폐기 패킷, 지연 시간과 대역폭 포화 여부를 함께 봐야 합니다.

• 장비 계층: 전원, 온도, 팬, 디스크 상태와 하드웨어 오류를 감시합니다.
• 운영체제 계층: CPU, 메모리, 파일시스템, 프로세스 수, I/O 대기 시간을 확인합니다.
• 애플리케이션 계층: 포트 개방 여부에 그치지 않고 API 응답 코드와 처리 시간을 측정합니다.
• 사용자 경로: DNS 조회부터 네트워크 구간, 웹 접속, 인증, 데이터 조회까지 연속된 흐름을 시험합니다.

특히 TCP 포트 연결 성공만으로 웹 서비스가 정상이라고 판단하면 안 됩니다. 포트는 열려 있어도 애플리케이션 스레드가 고갈됐거나 데이터베이스 연결 풀이 꽉 차면 실제 요청은 실패할 수 있습니다. 외부 또는 별도 네트워크 구간에서 주기적으로 핵심 URL을 호출하는 합성 모니터링을 추가하면 이런 사각지대를 줄일 수 있습니다.

관제 화면의 초록색은 설정한 조건이 정상이라는 뜻일 뿐, 사용자가 서비스를 정상적으로 이용하고 있다는 보증은 아닙니다.

모든 서버에 같은 임계값을 복사하지 마세요

고정된 숫자는 서버의 역할과 평소 패턴을 무시합니다

새 모니터링 시스템을 도입하면서 모든 서버에 CPU 80%, 디스크 90%, 메모리 90%라는 동일한 기준을 일괄 적용하는 실수가 흔합니다. 배치 서버는 새벽 작업 중 CPU가 95%까지 올라가도 정상일 수 있지만, 평소 CPU가 10%인 인증 서버가 50%를 15분간 유지한다면 장애의 전조일 수 있습니다. 같은 숫자를 사용하면 전자에서는 불필요한 경보가 쏟아지고 후자에서는 중요한 이상 징후를 놓칩니다.

디스크도 사용률 하나만 보면 대응 시점을 잘못 잡기 쉽습니다. 2TB 볼륨의 사용률이 85%라면 300GB가 남지만, 하루에 100GB씩 증가한다면 사흘 안에 가득 찹니다. 반대로 변화가 거의 없는 보관용 볼륨은 90%여도 당장 장애가 발생하지 않을 수 있습니다. 따라서 현재 사용률과 증가 속도, 예상 소진 시점을 함께 계산해야 실무적인 알림이 됩니다.

1. 최근 2~4주의 시간대별 기준선을 수집해 평소 변동 폭을 파악합니다.
2. 서버 역할과 업무 중요도에 따라 경고와 긴급 임계값을 다르게 설정합니다.
3. 순간적인 치솟음은 제외하되, 장애 전조를 가리지 않도록 지속 시간을 조정합니다.
4. 사용률뿐 아니라 응답 시간, 오류율, 큐 적체량처럼 서비스 영향 지표를 결합합니다.
5. 임계값을 바꾼 이유와 변경일을 기록하고 장애 발생 후 적절성을 다시 검토합니다.

예를 들어 API 서버는 ‘CPU 80% 초과’ 한 조건보다 ‘5분 평균 응답 시간이 2초를 넘고 오류율이 3% 이상’이라는 복합 조건이 더 유용할 수 있습니다. 데이터베이스 서버라면 CPU보다 활성 세션 수, 잠금 대기, 느린 쿼리, 복제 지연이 먼저 악화되기도 합니다. 역할에 맞는 지표가 빠진 상태에서 서버 수만 늘리면 IT 인프라 비용은 증가하지만 장애 탐지력은 좋아지지 않습니다.

경고와 긴급 알림의 차이를 없애지 마세요

모든 이벤트를 긴급으로 보내는 방식도 실패하기 쉽습니다. 담당자는 하루 수백 건의 알림을 받다가 중요한 장애 메시지까지 습관적으로 넘기게 됩니다. 경고는 근무 시간에 점검할 수준, 긴급은 즉시 호출하고 대응해야 할 수준으로 구분하고, 동일 원인에서 파생된 이벤트는 묶어서 전달해야 합니다.

• 정보: 자동 복구, 예약 작업 완료처럼 기록만 필요한 사건
• 경고: 용량 증가, 성능 저하처럼 계획된 확인이 필요한 상태
• 긴급: 서비스 중단, 데이터 손상 위험처럼 즉시 대응할 상태

알림을 한 사람의 메신저에만 보내지 마세요

전송 성공과 대응 시작은 전혀 다른 상태입니다

모니터링 시스템이 장애 메시지를 정상 발송했는데도 두 시간 동안 아무도 대응하지 못한 사례가 있습니다. 알림 수신자는 퇴근한 담당자 한 명뿐이었고, 휴대전화는 무음 상태였습니다. 시스템에는 ‘발송 성공’ 기록이 남았지만 조직 관점에서는 알림이 전달되지 않은 것과 같았습니다. 수신 확인과 단계별 확대 통보가 없는 알림은 장애 대응 체계라고 보기 어렵습니다.

일차 담당자가 일정 시간 안에 확인하지 않으면 이차 담당자와 책임자에게 자동으로 알리는 에스컬레이션 규칙을 마련해야 합니다. 야간과 휴일에는 당직표가 자동 반영돼야 하며, 담당자가 휴가를 떠날 때 수동으로 전화번호를 바꾸는 구조는 피하는 편이 좋습니다. 이메일은 기록 보관에는 유리하지만 즉시성이 낮으므로 긴급 장애에는 전화, 호출 앱, 문자 등 별도 경로를 함께 사용하는 것이 안전합니다.

규모가 큰 IT 시스템에서는 장비와 서비스의 소유자가 명확해야 합니다. 자산 정보에 담당 부서, 운영 책임자, 유지보수 업체, 업무 중요도와 변경 이력이 연결돼 있지 않으면 알림을 받아도 누구에게 넘겨야 할지 결정하지 못합니다. 자산 관리의 범위를 이해할 때는 IT자산관리시스템 관련 설명도 참고할 수 있습니다.

• 긴급 알림의 최초 수신자와 대체 담당자를 지정합니다.
• 5분 또는 10분 내 미확인 시 다음 단계로 자동 통보합니다.
• 장애 등급별 목표 확인 시간과 목표 복구 시간을 문서화합니다.
• 전화번호, 메신저 채널, 당직표를 분기마다 실제로 검증합니다.
• 장애 종료 후 오탐 여부와 대응 지연 원인을 함께 기록합니다.

연락망 문서만 만들고 시험하지 않는 것도 실수입니다

연락망 파일이 공유 폴더에 있어도 계정 권한 장애가 발생하면 파일 자체를 열지 못할 수 있습니다. 핵심 연락처와 초기 대응 절차는 주 운영 시스템과 분리된 위치에도 보관하고, 분기마다 가상 장애를 발생시켜 수신과 확인, 담당자 전환이 실제로 작동하는지 시험해야 합니다. 테스트 알림에는 반드시 훈련임을 표시해 불필요한 혼선을 막아야 합니다.

좋은 알림의 기준은 메시지가 발송됐는지가 아니라, 권한을 가진 담당자가 정해진 시간 안에 상황을 확인하고 행동을 시작했는지입니다.

오늘 한 개의 핵심 서비스를 직접 끊어 보세요

작은 장애 훈련이 감시 사각지대를 가장 빨리 드러냅니다

운영 중인 서버를 무작정 중단하라는 뜻은 아닙니다. 영향이 없는 검증 환경이나 승인된 점검 시간에 테스트용 프로세스 하나를 종료하고, 모니터링 시스템이 어떤 순서로 반응하는지 확인해 보세요. 단순 설정 검토보다 실제 시험이 빠릅니다. 예상한 지표가 변했는지, 알림이 몇 분 만에 발생했는지, 담당자가 알림 내용을 보고 원인과 대상 서버를 바로 이해했는지를 시간순으로 기록합니다.

훈련할 때는 모니터링 서버 자체의 장애도 고려해야 합니다. 감시 시스템이 멈추면 모든 장비가 조용해 보이는 역설이 생기기 때문입니다. 별도 위치에서 모니터링 시스템의 생존 여부를 확인하는 감시 장치와 ‘정상 신호가 일정 시간 들어오지 않으면 알리는’ 데드맨 스위치를 구성하면 관제 공백을 발견할 수 있습니다. 네트워크 단절 상황에서도 동일한 문제가 발생하므로 내부 관제와 외부 접속 시험을 조합하는 편이 좋습니다.

시험 결과는 성공과 실패 두 칸으로만 기록하지 말고 탐지, 통보, 확인, 조치의 네 단계로 나누세요. 예를 들어 장애는 1분 안에 탐지했지만 메시지에 서버 이름만 있고 업무 서비스명이 없어 담당자가 원인을 찾는 데 15분을 썼다면 알림 내용이 실패한 것입니다. 메시지에는 영향받는 서비스, 발생 시각, 현재 지표, 대시보드 링크, 최초 조치 방법이 포함돼야 합니다.

1. 고객 영향이 없는 테스트 대상 서비스 한 개와 점검 시간을 정합니다.
2. 서비스 소유자와 인프라 운영자에게 훈련 범위를 사전에 공유합니다.
3. 테스트 프로세스를 3분간 중지하고 최초 탐지 시각을 기록합니다.
4. 알림 수신자가 메시지만 보고 대상과 우선 조치를 설명하게 합니다.
5. 서비스를 복구한 뒤 정상화 알림과 이벤트 종료 여부까지 확인합니다.
6. 누락된 지표나 연락 경로 한 가지를 그 자리에서 수정 과제로 등록합니다.

복구 알림까지 확인해야 장애가 끝난 뒤에도 경보가 계속 울리거나, 반대로 정상화되지 않았는데 사건이 자동 종료되는 문제를 찾을 수 있습니다. 여러 시스템이 연계된 서비스의 운영 관점은 IT 서비스 시스템 설명처럼 개별 장비보다 서비스 제공 구조를 중심으로 바라볼 때 더 명확해집니다.

지금 바로 할 행동은 하나입니다. 가장 중요한 내부 서비스의 URL을 휴대전화가 아닌 사내 외부 구간에서 한 번 호출하고, 해당 요청의 실패를 현재 모니터링이 몇 분 안에 탐지할 수 있는지 담당자에게 물어보세요. 답이 숫자로 나오지 않는다면 이번 주 점검 시간에 3분짜리 장애 시험을 일정에 등록하는 것이 첫 번째 개선 작업입니다.