NMS 개념 - 장애관리 여섯번째

지금까지 네트워크 관리에서 장애 판단 및 예보 기능에 대해 알아보았다.

 

이번에는 이 장애 판단 및 예보에 가장 흔하게 사용되는 LOG에 대해서 알아보기로 하자.

 

대부분의 장비들은 장비 자체에 장비의 운영에 관련된 LOG를 기록한다.

때문에 네트워크 관리자들은 장비에 접속하여 이 LOG들을 분석함으로써 장비의 현재 상태나

과거의 운영 상태들을 관리할 수 있다.

 

그러나 이 LOG들은 휘발성이므로 (장비에는 메모리가 있을 뿐 DISK가 없다.)

장비가 문제가 생겨 부팅하고 나면 모두 사라져 버린다.

 

대부분 장애 발생시에 장비를 껐다 켜는 경우가 많으므로 추후 LOG를 보고자 하면 이미 모두

사라져 버린 후라 장애의 원인을 파악하기란 쉽지가 않다.

 

따라서 대부분의 장비는 SNMP Trap 또는 Syslog의 형태로 LOG를 기록할 수 있는 다른 시스템에

이 LOG를 전송할 수 있는 기능을 제공한다.

 

가장 많이 사용되는 Cisco 등 대부분의 벤더는 SNMP 보다는 syslog 형태로 더욱 장비의 LOG 형식에

가깝게 LOG를 기록할 수 있도록 해 준다.

 

그렇다면 이 LOG들은 어떤 방식으로 남겨지는가?

 

Cisco의 경우 syslog를  Alert, Critical, Error, Warning, Notification, Information, Debugging Mode 의 7가지 모드로 제공한다. syslog를 debugging mode로 설정하면 어느 정도의 log가 쌓이게 될까?

 

실제... 이 라우터에 이상이 있거나 이상 패킷이 많아 log가 매우 많이 발생하고 장비에 부하가 걸렸던 경우(였던 것으로 추정) debug mode 가 걸려있던 장비가 갑자기 CPU 사용율이 치솟으며 reboot 되는 경우를 본 적이 있었다. 75XX급 이상 대형 장비인 경우 이 debugging mode로 10대 정도만 log를 받아도 하루 100만건이 넘는 log들이 쌓이는 것을 볼 수 있는데 하루 백만건이면 NMS에서 관리하기에도 버거운 양의 데이터이다.

 

어쨌건 이 LOG들을 통합 저장하고 모니터링 할 수 있는 기능도 NMS의 필수 기능이다.

주요 기능은 LOG를 받아서 실시간으로 뿌려줄 수 있을 것.

그리고 모두 저장한 후 검색 조건으로 골라서 볼 수 있을 것.

그리고 가능하다면 통계를 내 줄 것.

 

이 짧은 세 줄에  LOG 관리 시스템의 모든 것이 담겨 있다.