25. NMS 구축 프로젝트에서 SNMP와 알람 설계로 배운 것들

네트워크 장비와 서버가 늘어나면
결국 NMS(Network Management System)를 도입하게 된다.
SNMP, 트랩(trap), 폴링(polling) 주기, 임계치(threshold) 같은 단어가 쏟아지기 시작한다.

실제 NMS 구축 프로젝트를 몇 차례 겪으면서
기술 그 자체보다
“운영 관점에서 무엇을 먼저 정해야 하는지”가
더 중요하다고 느꼈다.

SNMP 버전과 보안 설정을 먼저 표준화하기

현장에서 의외로 많이 부딪히는 부분이
장비별 SNMP 버전과 커뮤니티 문자열 설정이다.

• 오래된 장비는 SNMPv1/v2c만 지원
• 신형 장비는 SNMPv3까지 지원하지만 기본값은 비활성화

이렇게 섞여 있으면
NMS에서 장비를 등록할 때마다 설정을 따로 확인해야 한다.

실무에서는 가능하면 다음 원칙으로 정리했다.

• 신규 장비는 SNMPv3(인증+암호화) 기본 적용
• 기존 장비는 v2c에서 v3로 단계적 전환 계획 수립
• 커뮤니티 문자열, 사용자 계정, ACL을 표준 템플릿으로 관리

네트워크 보안팀과 인프라팀이
이 표준을 같이 잡아두면
이후 장비가 늘어나도 관리 비용이 크게 줄어든다.

폴링 주기와 트랩, “무조건 짧게”가 답은 아니다

처음에는 장애를 빨리 잡고 싶어서
폴링 주기를 1분, 심지어 30초로 설정하고 싶어진다.
하지만 모든 지표를 그렇게 가져오면
NMS와 장비 모두 부담이 커진다.

그래서 지표별로 우선순위를 나눴다.

• 즉각적 장애 지표:
  인터페이스 다운, 장비 다운, 전원 장애 등
  → 트랩 기반 즉시 통보 + 짧은 폴링 주기
• 성능 추세 지표:
  CPU, 메모리, 디스크, 인터페이스 사용률 등
  → 5분~10분 단위 폴링, 장기 추세 보고서 활용
• 저빈도 구성 정보:
  OS 버전, 설정 백업 여부 등
  → 하루 1회 수준 폴링으로도 충분

이렇게 구분해 두면
NMS가 진짜 중요한 이벤트에만 집중할 수 있고,
불필요한 트래픽과 알람을 줄일 수 있다.

임계치 설계에서 “기준 없는 80%/90% 룰” 버리기

CPU 80% 이상, 디스크 90% 이상 같은 기준은
편하지만 현실과 잘 맞지 않을 때가 많다.

실무에서는 다음 기준을 함께 봤다.

• 평상시 사용률 평균과 표준편차
• 피크 시간대 패턴
• 서비스 SLA와 연관된 지표

예를 들어 어떤 서버는
배치 작업 때문에 새벽 시간대만 CPU가 95%까지 올라가고
나머지 시간에는 10%대라면,
단순 80% 임계치로는 의미 있는 알람을 만들기 어렵다.

이럴 때는
시간대별 임계치, 또는
추세 기반 알람(예: 평소 평균 대비 2배 이상 증가)을
함께 써야 노이즈를 줄일 수 있었다.

토폴로지 맵은 예쁘게 그리는 것보다 “장애 분석에 쓰이는지”가 핵심

NMS의 장점 중 하나가
네트워크 토폴로지(Topology)를 시각화할 수 있다는 점이다.
하지만 실제로 장애가 났을 때
그 화면을 보는지, 아니면 쉘/콘솔로 바로 뛰어드는지가 중요하다.

실무에서 유용했던 토폴로지 맵의 조건은 다음과 같았다.

• 단순한 계층 구조: 코어–디스트리뷰션–액세스 구조가 한눈에 보일 것
• 색상·아이콘보다 연결 관계 위주 표시
• 특정 장비/인터페이스 장애 시
  영향 받는 구간(건물, 층, 서비스 등)을 바로 확인할 수 있을 것

결국 “장애 분석 시, 이 화면을 켜놓고 설명할 수 있는가”를 기준으로
토폴로지 맵을 설계하는 것이 실용적이었다.

NMS 자체도 하나의 서비스라는 관점

마지막으로 NMS는
단순한 모니터링 툴이 아니라
운영팀·고객사에 리포트를 제공하는 하나의 서비스라고 보는 게 맞았다.

• 월간/분기별 가용성 리포트
• 장애 발생 시 타임라인 정리
• SLA 준수 여부 보고

이런 산출물이 정리되면
NMS 구축 프로젝트의 성과를
경영진과 외부 파트너에게 설명하기도 훨씬 수월했다.