모니터링

1. 서버 모니터링의 목적

서버 모니터링(Server Monitoring)은 단순히 “서버가 죽었는지 보는 것”을 넘어,

시스템 전체의 안정성·성능·가용성을 유지하기 위한 운영 관리 체계이다.

기업 서비스에서 모니터링의 목적은 아래와 같다.

1. 가용성 보장(Availability)
2. 장애 발생 시 즉시 감지 → 빠른 복구
3. 성능 최적화(Performance Optimization)
4. CPU/메모리/디스크 I/O 병목 파악
5. 장애 예방(Predictive Monitoring)
6. 리소스 부족, 지표 이상 탐지 → 사전 조치
7. 보안 관점의 이상 탐지(Security Anomaly Detection)
8. 비정상 프로세스 증가, 비인가 접근 탐지
9. 서비스 신뢰성 확보(SLO/SLA 대응)
10. 기업 고객 상대 서비스라면 필수

즉, 모니터링은 서비스 품질 관리 체계의 시작점이다.

---

2. 서버 모니터링 구조(아키텍처)

서버 모니터링 시스템은 보통 아래 5단계 구조로 구성된다.

[Agent] → [Collector] → [Database] → [Analyzer/Rule Engine] → [Dashboard, Alert]

1) Agent (데이터 수집)

• 서버 내부에서 동작
• CPU/메모리/디스크/프로세스/네트워크 등 상세 데이터 수집
• 예: Zabbix-agent, Telegraf, Nagios agent

2) Collector(수집기·Proxy)

• 여러 서버에서 수집한 데이터를 중앙 서버로 전달
• 대규모 환경에서는 Proxy를 두어 부하 분산

3) Time-Series Database (저장)

• 시계열 데이터 저장 (고용량)
• Zabbix는 자체 DB, Prometheus는 TSDB 방식

4) Rule Engine (알람 판단)

• 특정 조건에 도달하면 알람 발생
• 예: 메모리 사용률 90% 초과 5분 지속

5) Notification & Dashboard

• Slack, Discord, SMS, Telegram, Webhook, PagerDuty 등
• 실시간 시각화 대시보드 제공(Grafana/PRTG/Zabbix)

---

3. 모니터링 방식의 구분 (Agent 기반 vs Agentless)

구분	Agent 기반	Agentless
특징	서버에 설치 후 내부 지표 수집	Ping, SNMP, SSH 등 외부 접근
장점	상세 지표, 정확도 높음	설치 불필요, 관리 쉬움
단점	설치·업그레이드 번거로움	제한된 항목만 가능
적용	기업 서버 대부분	네트워크 장비, 간단 Alive 체크

현대 기업 대부분은 Agent 기반이 주력이다.

---

4. 서버에서 수집하는 핵심 지표 (Deep Dive)

서버 모니터링의 수준은 수집 지표 설계가 결정한다.

단순 CPU/Memory만 보는 것은 “기초”이며, 실제 운영에서는 훨씬 더 깊은 지표를 본다.

(1) 서버 리소스 모니터링

CPU

• 사용자 영역(User)
• 커널 영역(System)
• Load Average (1/5/15min)
• CPU Steal (가상화 환경에서 매우 중요)
• CPU I/O Wait (I/O 병목 여부)

Load Average를 CPU 개수 대비 1~2배 이상 초과하면 병목 의심.

Memory

• Buffers / Cached 영역
• Swap in/out 발생 여부
• OOM(Out Of Memory Killer) 발생 로그
• 물리 메모리 대비 캐시 증가 패턴

Swap 사용이 지속된다면 심각한 장애 가능성이 매우 높다.

Disk / IOPS

• 디스크 사용량
• Read/Write IOPS
• Read/Write Latency
• Inode 사용률
• 파일 핸들 수(ulimit)

디스크 Full은 서버 장애 1순위 원인이다.

Network

• Send/Recv Throughput
• Packet drops
• SYN flood 등 비정상 패킷
• NIC Bonding 장애 여부
• MTU mismatch 회피

대용량 서비스에서는 네트워크 모니터링이 더 중요해진다.

(2) 프로세스 & 서비스 Alive

• 핵심 데몬이 죽었는지 체크
• (nginx, haproxy, mysqld, sshd 등)
• 특정 포트 오픈 여부
• 응답 속도(Latency)

단순 살아있음이 아니라 서비스 레벨 응답 속도까지 체크해야 한다.

(3) Application / WAS 모니터링

WAS(JAVA 기반 서비스)라면 더 많은 지표를 본다.

• GC time / GC pause
• Heap 영역 / Non-Heap 영역
• 스레드 수 증가
• Slow Query
• 내부 오류 패턴 (HTTP 500 증가 등)

이 부분은 Zabbix보다 제니퍼(Jennifer) 같은 APM 전문 솔루션이 강하다.

(4) 로그 기반 모니터링

• /var/log/messages
• /var/log/secure
• nginx access/error log
• app log pattern 매칭
• 권한 상승 로그
• 재부팅 로그 감지

DevOps에서는 로그 기반 모니터링(ELK stack, Loki 등)이 기본이 되었다.

---

5. 서버 모니터링이 감지하는 주요 장애 유형

1) 서버 다운 (H/W or O/S)

• 전원 문제
• 커널 패닉
• 재부팅
• 가상머신 freeze

2) 성능 병목

• CPU 100%
• Memory 부족
• Disk I/O 지연
• 네트워크 포화 (특히 대규모 트래픽일 때)

3) 디스크 Full

• inode 부족
• log 쌓임
• 백업 파일 누적
• Docker overlay 용량 부족

4) 서비스 프로세스 중단

• nginx/haproxy/httpd/mysql 같은 핵심 서비스 중지

5) 연결 장애

• 네트워크 인터페이스 down
• 패킷 드랍
• 라우팅 테이블 오류

6) 비정상 패턴 탐지

• 갑작스러운 트래픽 증가
• 공격 의심 (SSH brute force 등)
• 프로세스 스파이크

---

6. 알람 설계 (Threshold / Trigger 설계)

알람은 “조건만 넣는다”가 아니라 운영 전략이 필요하다.

예를 들어 다음과 같다.

CPU

• Warning: 70% 이상 5분 지속
• Critical: 90% 이상 5분 지속

Memory

• Swap 1초라도 발생하면 Critical
• Memory 95% 이상 10분 지속 → Warning

Disk

• 80% Warning
• 90% Critical

네트워크 지연 (ICMP latency)

• 지역 IDC 내 평균 1ms → 50ms 이상 시 문제
• 해외라면 100~200ms 기준 별도

알람 기준을 잘못 잡으면

(1) 너무 많은 알람 → 운영자 피로도 증가

(2) 너무 허술한 알람 → 장애 늦게 발견

이라는 문제가 생긴다.

---

7. 서버 모니터링 툴의 깊은 비교

Zabbix

• 대규모 구축 가능
• 템플릿 자동화
• Proxy 구조로 글로벌 모니터링 가능
• 장애 알람·대시보드 우수
• 기업에서 가장 많이 사용되는 표준

Nagios

• 오래된 전통있는 모니터링 툴
• 플러그인 기반 유연성
• 커스터마이징 자유도 높음
• UI/관리 편의성은 떨어짐

Ganglia

• HPC, 수천 노드 환경 특화
• Lightweight 구조
• 연구소/연구환경에서 인기

PRTG

• GUI 강력
• 설정 매우 쉬움
• 중소기업 or 운영팀 없는 개발팀에서 많이 사용

제니퍼(Jennifer)

• WAS/웹 서비스 실시간 Transaction 분석
• 장애 원인 추적 최강
• 백엔드 성능 문제 분석에 필수적

---

8. 운영에서 자주 발생하는 문제 & 대응 패턴

디스크 Full

웹 서비스 장애의 가장 흔한 원인

→ 로그 로테이션, 디스크 사용률 모니터링 강화

Docker 용량 폭발

→ overlay2 디렉토리 정리, container pruning

Swap 발생

→ 즉시 문제로 판단해야 함

특정 프로세스 CPU 100%

→ 자동으로 프로세스 kill 또는 재기동 스크립트 설정하는 기업도 많음

알람 폭탄(Field Alert Storm)

→ 매우 중요

→ 동일 알람 10개가 터지면 운영팀은 실질적 대응 불가

→ Debounce/Rate Limit 설정 필요

---

9. 결론 — 서버 모니터링의 핵심

서버 모니터링은 아래 3가지만 명확히 하면 된다.

1. 적절한 지표(메트릭)를 수집할 것

단순 CPU/Memory가 아니라 I/O, 네트워크, WAS, 로그까지.

2. 올바른 알람 기준을 설계할 것

지속시간, 조건, 민감도 조절

3. 장애 대응 프로세스를 설계할 것

알람 → 관제 → 엔지니어 조치 → 보고 → 재발 방지

이 3가지가 정착되면 서버 운영 안정성이 크게 올라간다.