MRTG는 장비의 CPU, 메모리, 4～7계층 스위치, 다양한 서버와 애플리케이션의 상태를 모니터링 하는 툴로, 네트워크 관리자라면 한번 이상은 사용해 봄직한 공개용 툴이다. 하지만 알고 있는 것과 실제로 잘 활용하는 것은 별개의 문제. MRTG 설치시 유의할 점과 MRTG 전체 구조의 이해 등을 통해 실력있는 네트워크 관리자의 세계로 한단계 성큼 다가서 보자.
네트워크에 연결돼 있는 수많은 스위치, 라우터, 서버 등과 같은 여러 장비들을 관리하는 엔지니어들이 가장 궁금해 하는 것 중에 하나가 바로 ‘어떻게 장비의 상태를 주기적으로 모니터링할 수 있을까’일 것이다.
과거 네트워크 장비 상태를 점검한다고 하면 대부분 ‘트래픽’의 양에만 국한됐다. 하지만 최근에는 장비의 CPU, 메모리, 4～7계층 스위치, 다양한 서버와 애플리케이션까지 등장하면서 보다 다양한 값을 포함하게 됐다.
MRTG는 이런 상태를 모니터링하는 툴 중 하나로, ‘Mutli Router Traffic Grapher’의 줄임말이다. MRTG는 이름에서 알 수 있듯이 기본적으로 라우터에서 가장 중요한 여러 인터페이스들의 ‘In/Out’ 트래픽을 일간, 주간, 월간, 년간을 기준으로 각각 별도의 그래프를 그려주고, 이들의 현재, 평균, 최대치를 한눈에 알 수 있게끔 해주는 아주 유용한 툴이다.
 |
| (화면 1) 네트워크 장비의 트래픽(주간) |
MRTG는 라우터를 기본적으로 하고 있지만 조금만 응용해서 사용한다면 상상 이상의 것들도 모니터링이 가능하다. MRTG 활용으로 유명한 국내 사이트인 www.mrtg.co.kr로 가면 네트워크 장비들의 내부 온도를 나타내는 수치를 이용해, 온도 그래프까지 그려보이고 있다.
그만큼 네트워크를 하는 사람들에게 MRTG는 잘 알려진 툴이며, 많이들 사용하고 있고, 실제 상용화된 네트워크 제품들이 통계치를 가진 그래프가 필요할 때 많이 사용된다. 아직 MRTG를 접해보지 않은 독자들이 있다면 이번 글을 통해 유용한 툴 하나를 얻을 수 있을 것이다.
MRTG의 동작 원리
MRTG는 여러 가지 요소가 복합적으로 동작을 하기 때문에 제일 먼저 MRTG가 전체적으로 어떻게 구성돼 있는지를 이해해야만 한다. 필자가 처음 MRTG를 접하고 나서 어느 정도 익숙해지기까지 시간이 많이 걸렸던 것도 바로 이런 부분을 그냥 지나쳤기 때문이었던 것으로 기억한다. 때문에 이 같은 시행착오를 거치지 않으려면 MRTG의 전체 구성을 반드시 이해하고 넘어가는 것이 좋다.
MRTG는 (그림 2)와 같이 모니터링 대상이 되는 시스템과 그 시스템을 모니터링 하는 두 개의 시스템으로 구성된다.
 |
| (그림 1) MRTG의 구성과 동작 원리 |
(그림 2)와 같이 네트워크 장비의 트래픽을 모니터링하고 싶을 경우 MRTG 서버의 SNMP(Simple Network Management Protocol) 요청에 응답하기 위해 시스템에서 제일 먼저 SNMP는 에이전트(Agent)를 구동시켜야 한다. 물론 이때 두 시스템은 네트워크에서 연결이 돼야 한다(인터넷 구간에서도 많이들 사용한다).
다음으로 MRTG가 구동될 서버에는 모니터링 장비에 정보를 요청하고, 그 값을 로그로 남기고, 그래프를 만드는 MRTG 프로그램을 설치해야 한다. 이들 결과값을 사용자가 웹 브라우저를 이용해서 볼 수 있도록 웹 서버를 설치해야 한다. 웹 서버는 결과값을 만드는데는 필요하지 않고, MRTG의 결과값이 gif, png 형태의 그래프와 HTML 형식으로 만들어지기 때문에 사용될 뿐이다.
여기서 웹 서버는 자주 사용하는 리눅스(유닉스 계열)의 아파치나 마이크로소프트의 윈도우 NT 계열 이상에 설치되는 IIS 또는 개인용 웹서버라고 불리우는 ‘Persnal Web Server’이어도 상관없다.
다시 한번 정리하면 모니터링 대상이 되는 시스템에 SNMP가 구동돼야 하고, MRTG가 설치된 서버에 MRTG 프로그램과 웹 서버를 설정하면 모든 작업은 끝난다. 이제 필요할 때마다 웹 브라우저를 이용해 장비 상태를 점검하면 된다.
다양한 운영체제 지원
MRTG가 가장 많이 사용되는 시스템은 리눅스(유닉스) 계열이고, 최근에는 마이크로소프트의 윈도우 계열에서도 많이 사용한다. 그 이유는 더 편해서라기 보다는 대부분의 사람들이 윈도우를 사용하기 때문일 것이다.
최근 리눅스 배포판들의 경우는 대부분 MRTG를 이미 포함하고 있기 때문에 리눅스가 있다면 바로 사용할 수 있다. 참고로 MRTG는 다음과 같은 다양한 운영체제를 지원한다.
- 리눅스 1.2.x, 2.0.x, 2.2.x, 2.4.x(인텔, 알파, 스팍, 파워PC)
- 리눅스 MIPS, 리눅스 S/390
- SunOS 4.1.3
- MacOSX 10.2.8
- 솔라리스 2.4, 2.5, 2.5.1, 2.6, 7, 8, 9
- AIX 4.1.4, 4.2.0.0, 4.3.2
- HPUX 9,10,11
- 윈도우 NT 3.51, 4.0, 2k, XP, 2003(95, 98, ME too, but only for die-hards)
- IRIX 5.3, 6.2, 6.5
- BSDI BSD/OS 2.1, 4.x, 3.1
- NetBSD 1.5.x 1.6.x
- FreeBSD 2.1.x, 2.2.x, 3.1, 3.4, 4.x
- OpenBSD 2.x, 3.x
- Digital Unix 4.0
- SCO Open Server 5.0
- Reliant UNIX
- NeXTStep 3.3
- OpenStep 4.2
- Mac OS X 10.1
- 기타 유닉스 계열의 운영체제
이렇게 다양한 운영체제를 지원하는 것만으로도 MRTG가 얼마나 범용적인 툴인가를 알 수 있다.
이번 기고에서는 지면 관계상 MRTG 설치법에 대해서는 자세히 다루지 않는다. 그렇다고 걱정할 필요는 없다. 다음과 같은 홈페이지를 이용하면, 보다 더 자세한 설치 매뉴얼을 얻을 수 있으니 말이다.
- www.mrtg.co.kr
- http://people.ee.ethz.ch/~oetiker/webtools/mrtg
대신 MRTG 설치시 주로 고민하게 되는 몇 가지에 대해서만 간단히 짚고 넘어가도록 하겠다. 우선 MRTG는 펄(Perl)과 C를 기본으로 동작하는데, 리눅스의 경우 대부분 펄이 이미 설치돼 있기 때문에 MRTG만 설치하면 되지만, 윈도우에서는 그렇지가 못하다. 때문에 ‘윈도우용 Perl’을 별도로 설치해야만 한다.
자신의 시스템에 펄이 설치돼 있지 않다면 www.perl.com이나 www.perl.org를 방문해서 별도로 펄을 설치해야 한다. 참고로 펄은 스크립트형 프로그래밍 언어로, 유닉스 계열에서 많이 사용되며, 특히 웹 서버들의 프로그래밍에 많이 사용돼 왔다.
MRTG 실행 파일 활용 1 : cfgmaker
MRTG에는 다음과 같은 3개의 실행 파일이 있다.
- cfgmaker
- mrtg
- indexmaker
cfgmaker는 이름에서 짐작할 수 있듯이 MRTG가 구동되기 위한 Config 파일을 만드는데 사용된다. 사실 Config 파일의 포맷을 정확히 알고 있다면 cfgmaker를 사용할 필요가 없지만, 그렇지 않은 경우에는 cfgmaker를 이용해서 설치를 한 후에 간단하게 Config 파일을 만들 수 있다.
그 다음으로 이 Config 파일을 자신이 원하는 형태로 수정을 하면 된다. cfgmaker의 경우, 처음에 Config 파일을 생성할때만 사용된다. 다음은 간단한 cfgmaker 사용법이다.
[root@tech mrtg]# cfgmaker admin@192.168.10.10 switch.cfg
여기에 사용된 ‘admin’은 실제 모니터링을 할 시스템인 192.168.10.10에 설정된 SNMP 커뮤니티 값이다. 그리고 다음에 있는 switch.cfg는 cfgmaker에 의해 만들어질 Config 파일의 이름이다.
여기서 cfgmaker는 192.168.10.10 시스템에 직접 SNMP 통신을 해 모든 인터페이스들의 값을 나타내고자 한다. 그러므로 cfgmaker를 구동할 때는 시스템과 SNMP 통신이 가능해야만 한다. 만약에 그렇지 않다면 ‘에러’를 만나게 될 것이다.
MRTG 실행 파일 활용 2 : mrtg
MRTG의 또다른 실행파일인 mrtg는 기본적으로 5분마다 실행돼 Config 파일에 따라서 SNMP 요청을 하고, 그 결과값으로 로그를 남기고 그래프도 만든다. cfgmaker와 indexmaker가 어떤 대상을 모니터링 하고자 할 때 처음에만 사용된다고 한다면, mrtg 파일은 모니터링을 하는 동안 계속해서 사용된다.
[root@tech mrtg]# mrtg switch.cfg
mrtg 파일은 cfgmaker로 만들어지거나 임의로 만든 Config 파일을 이용해 실행할 수 있다. 이때도 물론 해당 서버와 통신이 가능해야만 정확한 값을 가지고 올 수 있다. mrtg의 경우, 이전에 남은 로그를 비교해서 만들기 때문에 초기에 실행하면 첫번째, 두번째는 에러가 나고, 세번째에야 에러가 없이 동작을 하게 되니, 첫 번째, 두 번째 에러에 너무 당황하지 않아도 된다.
설치 초기에만 mrtg 파일을 수동으로 실행시키고 이후에는 유닉스의 자동 스케줄 프로그램인 cron을 이용해서 5분마다 구동시키면 된다. 다음은 cron에 등록돼 5분마다 실행하도록 추가된 내용이다.
*/5 * * * * /usr/local/mrtg-2/bin/mrtg /var/www/html/mrtg/switch.cfg
mrtg를 5분마다 실행하는 또 다른 방법으로는 Config 파일에 다음과 같은 항목을 넣어주는 것이다.
RunAsDaemon:Yes
Interval:5
위와 같은 항목만 넣어주고 mrtg가 실행되면서 데몬으로 동작을 하게된다. mrtg가 cron에서 동작할 경우 매번 Config 파일을 로딩하고 파싱을 해야 하는 반면, 데몬의 경우 그 동작을 한번만 수행하는 장점이 있다.
다만 데몬으로 동작하는 경우는 시스템 구동시 시작되도록 시작 스크립트에 mrtg가 한번 구동되도록 해야 한다는 점을 절대 잊지 말자.
MRTG 실행 파일 활용 3 : indexmaker
'indexmaker' 파일도 cfgmaker와 마찬가지로 초기에 cfgmaker를 만들고, mrtg 파일을 다음에 한번만 생성하면 된다. 이 파일은 실제 mrtg가 동작하는데 사용되기 보다는 mrtg로 만들어진 결과값을 사용자가 웹 브라우저로 볼 때 만들어지는 HTML 형태의 초기 화면을 만들어주는 역할을 한다. 그러니 mrtg를 구동하고 처음에 한번만 실행을 하면 된다.
[root@tech mrtg]# indexmaker --title "스위치“ --output ./switch/index.html switch.cfg
위의 명령어를 실행시키고 나면 ‘switch’라는 폴더에 ‘index.html’이라는 파일이 생성됨을 알 수 있을 것이다. 물론 이 페이지를 열게 되면 페이지 맨 위의 제목이 ‘스위치’로 돼 있다. 참. 이때 간단한 내용이지만 주의할 점은 이 파일이 만들어지는 위치는 당연히 웹 서버의 홈 디렉토리 내부에 위치해야만 웹 브라우저로 볼 수가 있다는 것이다.
지금까지 살펴본 cfgmaker, mrtg, indexmaker 파일이 각각 어떤 역할을 하는지 명확히 구분할 수 있다면 MRTG를 처음 설치하더라도 걱정할 것이 없다.
MRTG의 로그값 분석하기
이제부터는 MRTG가 남기는 로그에 대해 알아보자. MRTG는 5분마다 얻어진 로그를 남기고, 이전까지의 값들을 계산해 최고, 평균값들을 남긴다. 이들의 로그 포맷은 (화면 2)와 같다.
 |
| (화면 2) MRTG의 로그 포맷 |
MRTG는 이렇게 남겨진 로그를 갖고 그래프를 그린다. 기본 입력값은 Byte/Sec 단위이다. MRTG의 로그중에서 가장 재미있는 내용은 시간 필드이다. 이 필드는 MRTG가 유닉스 계열에서 만들어졌음을 여실히 나타내고 있다.
이 시간들은 유닉스의 기본값인 1970년 1월 1일부터 초단위로 증가한 시간을 나타낸다. 물론 사용자가 이 시간을 구분할 필요는 없다. 이 값은 그래프로 그려지는 순간에 이미 사용자가 알 수 있는 시간으로 변환돼 있기 때문이다(그래프가 그렇다는 것이지 로그파일 자체가 바뀌는 것은 아니다).
MRTG의 CFG 파일 구조
다음으로 MRTG의 CFG 파일의 구조를 간단하게 살펴보자. 앞서 설명한 실행 파일인 cfgmaker로 파일을 만들고 나면 그 파일을 그대로 쓰는 것보다는 몇 가지를 수정해서 사용하는 편이 낫다. 물론 수정을 하다가 에러를 만들 위험도 있지만 몇가지 정도만 수정을 하면 보다 깔끔한 화면과 원하는 화면을 만날 수 있을 것이다.
cfgmaker로 만들어진 보통 파일들은 대부분 위와 같은 형태를 갖고 있는데 크게 3가지로 구분할 수가 있다. 첫번째로 Config 파일 전체에 영향을 미치는 ‘전체 환경 설정’ 부분이 있는데 이 부분에서는 사용하는 언어라든가 작업 디렉토리, 또는 각각의 항목에 영향을 미칠만한 옵션들을 사용할 수 있다. 필자가 주로 사용하는 옵션은 (표 1)과 같다.
(표 1)의 첫 번째 줄에 있는 'WorkDir: /home/www/mrtg'는 없어서는 안되는 아주 중요한 옵션이며, 그밖의 두 가지는 없어도 문제가 없지만 가독성에 상당한 도움이 되므로 알아두면 도움이 되는 옵션이다.
 |
| (화면 3) MRTG의 Config 파일 |
| |||||||||||||
| |||||||||||||
|
 |  | |
| (화면 4) Language 옵션으로 달라질 수 있는 페이지(한글/영어) | ||
MRTG는 영어를 기본으로 하고 있다. 하지만 (표 1)의 두 번째 줄에 있는 ‘Language: Korean’이라는 옵션을 사용하면 화면이 한글로 변환된다. (화면 4)에서 좌측에 보이는 ‘일간 그래프’는 우측의 영문 버전으로는 ‘Daily Graph’로 표시된다. 역시 마찬가지로 좌측의 ‘최대 수신’은 우측에는 ‘Max In’이라고 표시된다. 한글이든 영문이든 의미가 같은데 뭐 그리 크게 다를 것이 있냐고 할 수도 있지만, 한국 사람은 아무리 영어를 잘 하더라도 한글 페이지가 더 편하게 느껴질 수밖에 없지 않겠는가.
다시 (화면 3)으로 돌아가서 두번째 사항인 ‘장비에 대한 설명’ 부분을 살펴보자. 이는 SNMP의 값 중에서 모니터링 대상이 되는 시스템이 어떤 정보들을 남겼느냐에 따라서 다르게 설명할 수 있다. 이 부분은 동작에 이상이 없지만 말 그대로 장비에 대한 설명이므로 장비의 SNMP 설정에서 시스템에 맞는 값으로 조절해 두는 것도 괜찮은 방법일 것이다.
마지막으로 (화면 3)의 ‘항목에 대한 내용’은 실제로 시스템에서 모니터링을 하고자 하는 항목에 대한 내용이다. cfgmaker로 만들었다면 장비가 갖고 있는 모든 인터페이스에 대한 각각의 항목들이 생겨난다.
다시 말해 24포트 스위치라면 24개의 항목이 생긴다. 다만 이중에 링크(Link)가 다운(Down)된 포트는 모두 주석(#) 처리가 된다. cfgmaker가 사용하지 않는 포트로 인식하기 때문이다. 하지만 주석으로 표시됐지만 실제로 사용하는 포트라면 주석만 삭제해주면 된다. 그리고 실제 데이터 값과는 상관없는 여러 ‘설명 항목’들이 있는데 이 부분은 사용자의 입맛에 맛게 수정하면 된다.
필요할 경우 항목 하나하나를 복사해서 추가해주고 각각의 항목들을 수정해주면 별도의 cfgmaker로 만들 필요가 없다.
다각도로 활용 가능한 MRTG
MRTG의 초기 개발 의도는 라우터 트래픽을 모니터링하는 것이었다. cfgmaker를 이용해서 Config 파일을 만들고 나면 더더욱 개발 의도가 그랬다는 것을 몸으로 느낄 수 있을 것이다(대부분 트래픽에 관한 용어들만 사용되고 있기 때문에). 하지만 MRTG의 활용도는 라우터 트래픽 분석 그 이상의 의미를 갖고 있다.
(화면 5)는 전형적인 MRTG의 페이지로 MRTG의 특징을 그대로 보여주고 있다. (화면 6)은 4계층 스위치에서 처리하는 TCP/UDP 커넥션 숫자를 SNMP를 이용해서 MRTG에서 얻은 그래프이다. 이 그래프를 이용해서 실제 이 사이트의 사용자 접속형태를 알 수 있고, 어떤 시간대에 가장 많은 사용자 증가가 있었는지를 짐작할 수 있다. 물론 이를 이용해서 시스템 확장 여부도 가늠할 수 있을 것이다.
 |
| (화면 5) 라우터의 트래픽 모니터링 하기 |
 |
| (화면 6) 4계층 스위치에서의 동시 사용자 모니터링 |
(화면 7)은 예전에 필자가 만졌던 장비의 CPU 사용률을 알아보기 위해 MRTG를 이용해서 얻은 결과이다. 이 그래프를 보면 CPU가 아침 9시부터 증가해서 초저녁까지 증가세가 이어졌다가 다시 새벽까지 천천히 내려가는 패턴을 보이고 있다. (화면 7)의 그래프 중에 그래프를 보면 갑자기 CPU가 뚝 떨어져 있는 것도 볼 수 있을 것이다. 이 그래프에서 우리는 어떤 문제점이 있었는지를 짐작할 수가 있다. 물론 문제가 아니라 시스템 점검으로 서비스를 중단했을 가능성도 있다.
이렇게 그래프를 통하면 직관적으로 원하는 요소들이 각각 어떤 패턴을 갖고 있는지를 짐작할 수 있도록 해주며, MRTG의 경우 일간, 주간, 월간, 년간으로 각각 그려주기 때문에 전체적인 흐름을 이해하는데 아주 많은 도움이 된다.
 |
| (화면 7) 시스템의 CPU 사용률 모니터링 |
‘MRTG에서 RRDTool로 새롭게 도전하자’
마지막으로 MRTG 활용과는 상관이 없지만 지금껏 MRTG를 사용해 온 독자라면 분명 매력적이라고 느낄 툴 하나를 더 소개하고자 한다. 이 툴의 이름은 ‘RRDTool’이며, ‘Round Robin Database Tool’의 약자이다.
RRDTool은 MRTG의 그래프 기능과 로깅 기능을 강화한 새로운 형태의 툴이다. RRDTool과 MRTG의 가장 큰 차이는 처리 속도와 유연성의 강화에 있다. 참고로 RRDTool에 대한 보다 자세한 정보는 홈페이지(www.rrdtool.com)에서 얻을 수 있다.
(화면 8)은 해외의 유명한 음악공유 사이트인 냅스터(www.napster.com)에서 사용하고 있는 RRDTool의 화면이다. 이 사이트에서는 각종 서비스들의 트래픽 사용률을 나타내고 있다. (화면 9)는 미국에서 모뎀으로 통신 접속을 하는 가입자들의 평균 속도를 구분하고자 사용된 RRDTool이다. 이 그래프를 이용해서 보다 화려한 그래프로 통계치를 나타내고 있다. MRTG와 비교해 보다 시각적인 면에서 발전된 양상을 보여주는 툴이 바로 RRDTool이다. 이미 MRTG에 익숙한 사용자라면 한단계 발전한 RRDTool을 이용해 보다 화려하고 다양한 그래프를 만들어 보는 것도 나쁘지 않을 것이다.
MRTG나 RRDTool은 모두 공개용 툴이므로 돈을 주고 사는 상용 툴과 달리 사용자 힘으로 처음부터 끝까지 모든 것을 해결해야 한다. 즉, 제품 구매 업체에 전화를 해서 도움을 청할 수도 없고, 의논을 할 수도 없다. 하지만 두려워할 필요는 없다. 인터넷 여러 사이트를 뒤지면 많은 유용한 정보들이 넘쳐나고 있기 때문이다. 엔지니어라면 누구나 마음만 먹고, 노력한다면 공개툴에 가볍게 도전할 수 있을 것이다. 이미 많은 사람들이 그렇게 해서 아주 유용하게 사용하고 있으니 말이다. @
 |
| (화면 8) 넵스터 서비스의 사용률 |
 |
| (화면 9) 모뎀 속도에 따른 접속자 수 분석 |