NMS 개념 - 장애관리 일곱번째

LOG 관리에 대해 좀 더 자세히 알아보자.

 

사실 LOG 관리라는 것은 앞서 말한 것처럼 아래의 세 가지로 요약된다.

 

실시간 LOG 모니터링 => 문제 LOG 발생 시 경보

모든 필요한 LOG의 저장 => 가능하면 전부 다

저장된 LOG의 검색 => 통계 기능도 있으면 좋음

 

 

장비들의 LOG를 서버로 받기 위해서는 해당 장비들이 syslog 프로토콜을 지원하는지 확인하고

해당 장비의 syslog 기능을 enable 해주면 된다. 그리고 LOG의 등급(종류)을 설정해 준다.

여기서 필요한 것이 "관리 정책"이다.

altert이나 critical 만 설정하면... 실제 해당 네트워크에서는 중요한 LOG를 놓칠 수 있다.

때문에.. 실제 운영자나 엔지니어들은 debug 모드를 선호한다.

그러나 이것은 장비에 부하를 줄 수 있고, debug 모드로 올라오는 LOG들을 모니터링한다는 것은

별로 즐겁지 않은 일이므로, 관리자의 성향과 필요성에 따라 모드를 적절히 설정한다.

 

syslog 서버에서는 unix 시스템인 경우 디폴트로 제공하는 syslogd가 /var/log/아래에 파일로 쌓아준다.

수정하고 싶으면 /etc/syslog.conf 파일을 열어 적절히 수정하면 된다.

 

windows 서버의 경우 syslog가 기본으로 제공되지 않으므로,

syslog 데몬 프로그램을 구해서 설치해야 한다. kiwi 같은 것들이 많이 쓰이며 유료이다.

대부분 외산이며, 국산 프로그램은 단품보다는 로그 분석 솔루션에 가까운 것들이 몇 개 있다.

외산의 경우 기능은 매우 단순하다. syslog를 모아서 보여주고,  파일로 저장해 준다.

 

작은 네트워크에서는 이런 솔루션들이 매우 유용하게 쓰인다.

그러나 대형 네트워크에서는 얘기가 달라진다.

장비에서 올려주는 LOG들이 하루 몇십만건, 몇백만건이 이르게 되면,

이 LOG를 파일로 관리한다는 것이 얼마나 노가다 작업이 되는지 해본 사람은 알 것이다.

몇 기가나 되는 파일 덩어리에서 원하는 LOG들을 찾아내기가 얼마나 어려운가.

때문에 대량의 로그를 관리하기 위한 DB가 등장한다.

여기서 네트워크 관리자는 고민에 빠지게 된다.

DB가 등장하면 이제 이 S/W는 네트워크 관리자의 영역을 벗어나

개발의 범주로 넘어가 버리기 때문이다.

LOG를 저장하기 위한 DB 구축 비용과 이를 제대로 볼 수 있게 하기 위한 개발비는

네트워크 관리자에게 상당한 부담을 안겨 준다.

 

LOG를 관리하는 것이 얼마나 중요한가?

LOG 관리 시스템은 꼭 있어야 하는가??