레이블이 network인 게시물을 표시합니다. 모든 게시물 표시
레이블이 network인 게시물을 표시합니다. 모든 게시물 표시

2012-09-16

Network] 오픈소스 트레픽 테스트 툴] 시즈(Siege) 사용하기


많은 웹개발자들과 서버 관리자들이 가장 두려워하는 것은 엄청난 트래픽 때문에 웹사이트가 다운되는 사태다. 트래픽 폭주의 원인은 DoS 공격 등 여러가지가 있지만 분명한 것은 더이상 웹사이트를 사용할 수 없도록 만든다는 사실이다.

이런 필요 때문에 등장한 것이 바로 부하 테스트 툴이다. 사이트가 어떤 트래픽 수준에서 다운되는 지를 테스트하는 소프트웨어로, 이미 좋은 툴들이 많이 출시돼 있다. ‘WAPT’라는 상용 소프트웨어는 Builder.com에 서 리뷰하기도 했다. 필자는 무료로 사용할 수 있는 오픈소스 툴을 선호하는데, 오픈소스 부하 테스트 툴 가운데 가장 널리 사용되며 꾸준히 업데이트되는 소프트웨어로는, 이름과도 잘 어울리는 ‘시즈(Siege, 포위공격)’가 있다.

시즈의 특징
‘시 즈’라는 이름은 이 툴의 모든 것을 말한다. 서버를 에워싸 서버가 어떤 이유로 문제를 일으켰는지를 보여주는 것이다. 유닉스 기반의 명령행 기반 툴인 시즈는 GNU GPL 오픈소스 라이선스를 따르기 때문에 사용, 수정, 배포가 모두 무료다.

시즈는 단일 URL의 부하 테스트는 물론 많은 URL을 메모리로 불러들여 사용자가 설정한 시뮬레이션 유저만큼의 부하를 동시에 테스트할 수 있다. 또한 기록된 총히트수와 전송된 바이트수, 반응시간, 병행성(Concurrency), 리턴 상태 등을 보여주며, HTTP 1.0/1.1 프로토콜, GET/POST 디렉티브, 쿠키, 트랜잭션 로깅, 기본적인 인증 등을 지원한다.
1. 다운로드와설치


시 즈 최신버전은 Builder.com 다운로드 사이트에 서 받을 수 있다. 설치는 GNU 오토콘프(autoconf)를 사용해 유닉스 애플리케이션용 컴파일 절차를 따른다. 표준 ANSI C 컴파일러(대부분의 기본 *nix 인스톨의 일부)를 지원하는 최근의 리눅스 시스템이나 다른 *nix 시스템 환경이라면 설치는 매우 간단하다. 먼저 다운로드한 파일의 tar 압축을 다음과 같이 해제한다.
$ tar xvzf siege-latest.tar.gz
이제 다음과 같이 설정한다(디폴트 설정을 추천한다).
$ ./configure

설정에 대한 도움말은 -help 서픽스(suffix)를 이용하면 된다. 필자가 개인적으로 추가한 것은 SSL 지원으로, ‘-with-ssl=/usr/local/ssl’ 서픽스를 통하면 된다. 여기까지 마쳤으면 이제 남은 것은 다음과 같이 컴파일해 설치하는 것이다.
$ make
$ make install

2. 실행하기


시 즈는 웹서버를 테스트하는 다양한 옵션을 제공한다. 가장 간편한 실행 방법은 단일 URL 테스트다. 이것은 특정 페이지가 대량 트래픽에 어떻게 반응하는지를 잘 보여준다. 이때 중요한 옵션 두 가지가 동시 접속자수(-c 옵션, 디폴트는 10)와, 반복 쿼리수 혹은 시간으로 표현되는 테스트 기간(-t)이다. 예를 들어 25명이 동시에 1분간 접속하는 환경이라면 다음과 같이 실행하면 된다

$ siege -c25 -t1M www.example.com

이밖에도 딜레이를 설정하는 -v와 -d 옵션을 자주 사용하는데 기본값은 0 이다
3. 분석결과


여기까지 실행했다면 시즈는 당신의 코드와 서버가 대량 트래픽에 어떻게 반응했는지를 알려준다. 다음은 위의 명령을 실행했을 때의 결과 화면이다.
** Siege 2.59
** Preparing 25 concurrent users for battle.
The server is now under siege...
Lifting the server siege... done.
Transactions: 406 hits
Availability: 99.75 %
Elapsed time: 59.66 secs
Data transferred: 10340918 bytes
Response time: 2.36 secs
Transaction rate: 6.81 trans/sec
Throughput: 173330.84 bytes/sec
Concurrency: 16.07
Successful transactions: 412
Failed transactions: 1

가용성(Availability)은 가장 중요한 요소인데 이것이 100%에 미달했다는 것은 사용자 중의 일부가 사이트에 접속하지 못했다는 것을 의미한다. 따라서 위의 실행결과는 문제가 된다. 1분에 25명이 접속했을 때 가용성이 99.75%에 불과했기 때문이다.

병행성 (Concurrency)은 각 트랜잭션 처리 시간을 경과시간으로 나눈 것이다(이때 트랜잭션이란 모든 인증시도를 포함한 서버의 히트수다). 이를 통해 평균 동시 접속 수준을 알 수 있는데, 병행성이 높을수록 서버가 어려움에 봉착했음을 암시한다. 그 이유는 새로운 트래픽 처리를 위해 소켓을 열어야 하는 상황에서, 서버가 한 트랜잭션을 완료하는데 걸리는 시간이 길면 길수록, 동시에 처리해야 할 트래픽이 많아져 서버 성능이 떨어지기 때문이다.
4. 고급기능


필자가 시즈 초기버전을 사용했을 때는, 서버에 준 부하에 성공과 실패가 서로 뒤섞여 있었다. 단순히 동시 접속자와 테스트 시간을 늘려 결과를 살펴보는 정도였다. 그러나 시즈 최신버전에는 봄바드먼트(Bombardment)라는 툴이 포함돼 있어, 명령어 옵션으로 클라이언트 숫자를 증가시킬 수 있다. 그러나 봄바드먼트(Bombardment)는 버보스(verbose) 출력이나 로깅 기능 등 시즈가 기본적으로 지원하는 사용자 옵션이 없어 제대로 실행되지 않는 단점이 있다.

적당한 회귀 테스팅도 단일 URL 이상에서만 가능하다. 시즈는 과거에 ‘스카우트(Scout)’라는 툴을 이용해, 특정 도메인에서 URL들을 추출한 후 이를 시즈 테스트 목록에 포함시키는 기능을 지원했었다. 현재 스카우트는 더 이상 업데이트되지 않지만 이전 버전은 다운로드해 사용할 수는 있다.

시즈 최신 버전에는 스카우트 대신 새로운 테스팅용 URL 추출기인 ‘스프록시(Sproxy)’가 포함돼 있다. 그러나 필자는 개인적으로 스카우트에 더 후한 점수를 주고 싶다. 스프록시는 옵션을 사용자 브라우저 프록시로 설정하면, 사용자가 방문한 모드 사이트의 링크를 테스트 목록에 추가하기 때문이다. 유일한 추가 옵션은 수동으로 모든 URL을 입력하는 것이다.

시즈는 사이트내에 존재하는 모든 GET/POST, 인증, 쿠키에 대한 부하 테스트를 할 수 있으며, 사용자는 단지 URL을 입력하거나 스프록시나 스카우트 등의 툴을 이용하면 된다. 다수 URL에 -i 옵션을 사용하면 동시 쓰레드 방식으로 URL을 난수화해 보다 실제에 가까운 테스트도 할 수 있다.

5. 가용성가 방응시간 개선방법

시즈는 URL 부하를 테스트하는 간단한 툴일 뿐이다. 따라서 가용성과 반응시간 등을 개선하기 위해서는 이를 결정하는 두 가지 요소, 즉 네트워크적인 요인과 웹 개발자에 의해 좌우되는 웹페이지의 요소들을 살펴봐야 한다.

먼저 네트워크 측면을 보면 호스트 웹서버의 대역폭(처리 능력)과 메모리가 가장 중요하다. 로드 밸런스 환경이라면 호스트 웹서버 대신 서버가 된다. 웹페이지 부분에서는 코드를 효율적으로 개발하는 만큼, 이론적으로는 파일 크기가 작아지기 때문에, 네트워크 자원의 낭비도 줄일 수 있다.
6. 참고사이트
시즈를 받을 수 있는 홈페이지 - http://Builder.com

Network] MRTG를 이용한 트래픽사용량 분석하기


MRTG를 이용한 트래픽사용량 분석하기
 
1. 서버트래픽분석 개론
MRTG에서 서버트래픽을 모니터링하기위해서는 cfg파일을 만들어야한다.
cfg파일을 만드는 방법은 두가기가 있다.
  • 첫째, cfgmaker로 만드는 방법
  • 둘째, 가장유사한 cfg파일 복사후 수정하는 방법
위의 두가지 방법모두 실무에서 사용되고 있는 방법이다.
굳이 구분해 본다면 첫 번째의 경우에는 MRTG서버를 처음구축한후에 이미 사용중인 cfg파일이 존재하지 않으므로 환경파일생성툴인 cfgmaker를 이용하여 생성하는 방법이다.
, MRTG 서버구축초기에 많이 사용되는 방법이며 이방법으로 생성된 cfg파일을 살펴보면 불필요한 내용이 많이 추가되어 있음을 알 수 있다.
두 번째 방법은 MRTG서버를 어느정도 사용하다 보면 생성된 cfg파일이 여러개 존재하게 된다.
새로운 서버의 트래픽사용량이나 자원들(CPU, DISK, MEMORY)의 사용량을 모니터링하기위해서는 새로운 cfg파일이 필요하게 된다.
이때에 이미 사용중인 cfg파일중 가장 유사한 파일을 복사한 후 그 내용을 조금만 수정해 주면 사용이 가능하다.
필자의 경험에 의한다면 MRTG를 처음 사용하는 분이라면 첫 번째 방법을 사용하고, MRTG를 사용중인 분이라면 두 번째 방법으로 cfg파일을 생성하는 것이 일반적이지 않나 생각한다.
다만 여기에서는 앞서 cfgmaker로 환경파일(cfg)을 생성하는 방법에 대해서 배웠으므로 그 사용법을 다시 언급한다는 것은 무의미하므로 두 번째의 방법으로 이미 cfg파일을 생성했다는 가정하에게 설명을 계속진행해 나갈 것이다.
뒤에 나오는 DISK, CPU, MEMORY의 사용량분석의 경우에도 모두 동일하게 적용이 된다.
2. Configuration file 만들기
현재 실습중인 대상장비는 리눅스 서버이다.
이 리눅스서버의 트래픽을 분석하기 위한 cfg파일을 직접 만들어서 보여주고 있다.
물론, 필자가 제시한 cfg파일 포맷을 그대로 사용할 경우에는 수정할 사항들이 있다.
그럼, cfg파일내의 각 항목들에 사용하는 옵션들에 대한 자세한 설명과 함께 수정사항들도 알아보도록 하자.
3. cfg파일 분석
WorkDir
MRTG실행 결과후에 생성되는 웹페이지구성파일들(*.html, *.png, *.log, *.old)이 생성될 위치이다.
이 위치의 디렉토리가 존재하지 않는다면 MRTG실행시 에러가 발생하게된다.
WorkDir에서 지정한 디렉토리가 존재하지 않는다며 반드시 생성을 한후에 실행을 해야한다.
또한 이 디렉토리의 퍼미션(permission) 은 반드시 웹서버 프로세스(대부분 nobody)가 읽을 수 있는 퍼미션이어야한다.
실행이 정상적으로 되었다면 후에 결과페이지를 볼 경우에 이 페이지를 로딩하여 보게된다.
, 현재 서버의 IP Address가 192.168.0.5라면 이 개인별 홈페이지를 로딩되도록 아파치의 httpd.conf파일에서 아래와 같은 설정이 되어 있어야한다.
기본셋팅은 www가 아니라 public_html이지만 필자는 www로 변경하여사용을 하였다.
이렇게 설정을 하였다면 웹브라우즈의 주소창에서 확인이 가능하게된다.
혹은 이 서버에 개별적인 도메인이 www.superuser.co.kr 이라고 가정한다면 웹브라우즈에서 다음과 같이 결과를 확인할 수도 있다.
만약 아파치의 httpd.conf에서 가상호스트 설정을 하여 여러개의 독립도메인이 가능하도록 다음과 같은 설정이 되어있다면 독립적인 도메인의 호출또한 가능하게된다.
이렇게 설정이 되어 있다면 다음과 같은 URL로도 결과를 확인할 수 있다.
물론 얼마든지 다른 URL을 이용하여 다양한 로딩방법이 가능하지만 대부분 필자가 소개한 이런 방법등을 통해서 로딩을 하게된다.
참고로 이 결과페이지를 위와 같은 방법으로 웹브라우즈를 통해서 확인할 때에는 대부분 ID와 패스워드로 암호인증을 하여 로그인하여 사용하게 하는 것이 일반적인다.
이 방법에 대해서는 뒤에 이어서 설명되는 "결과페이지 로딩시 암호인증걸기"편을 보기 바란다.
Language
결과출력시 사용할 언어를 지정한다.
MRTG문서를 보면 지원가능한 언어로 danish, french, english, dutch, brazilian, russian, spanish, greek, italian등이 지원되는 것으로 되어있지만 위의 예처럼 korean으로 설정하면 한국어로 결과페이지를 볼 수가 있다.
Refresh
결과페이지를 몇초(second)에 한번씩 재로딩(expire)시킬 것인가를 지정한다.
단위는 초이므로 위의 예처럼 300을 주면 5분마다 웹브라우즈가 재로딩을 하게된다.
만약 이 옵션을 사용하지 않는다면 기본값으로 300이 지정되며  5분마다 재로딩을 하게된다.
너무 작은 값을 주면 불필요하게 서버부하를 줄 수 있으므로 모니터링의 사용빈도등을 고려하여 적당한 값을 주도록 한다.
WithPeak
MRTG는 원래 대상장비의 모니터링된 송수신값의 평균값만으로 그래프를 그리게 되는데 이 옵션을 사용하게되면 daily, weekly, monthly, yearly의 그래프에서 5분주기의 평균값뿐만아니라 최대전송량까지도 함께 표시가된다.
위의 예처럼 일(day),주 (week),월(month),년(year) 4가지의 그래프중에서 원하는 그래프의 첫문자로 지정하면 된다.
Options
기본적으로 MRTG는 Byte for Second단위, bit 단위에 8을 곱한 단위즉 Byte단위를 사용하여 그래프를 그린다.
하지만 Options에서 bits를 사용하게되면 8을 곱하지 않고 bps(bits per second)를 사용하게 된다.
기본값은 byte단위임에 주의하자.
기본적으로 MRTG는 왼쪽에서부터 오른쪽으로 그래프를 그리게 된다.
, 오른쪽 그래프일수록 예전값이 된다는 것이다.
하지만 growright를 사용하게되면 오른쪽가장자리부터 그래프가 그려지기 시작하여 왼쪽으로 갈수록 이전그래프가 되도록 한다.
기본적으로 이 두가지 옵션을 같이 사용하는 경우가 많다.
이외에도 Options에서 지정할 수 있는 값들은 여러 가지가 있는데 "MRTG Configuration File Format편"에서 자세히 살펴보도록 할 것이다.
Traget
미리 말씀드리는데 cfg파일 설정중에서 가장 중요한 옵션이므로 정확한 이해가 요구되는 키워드이다.
먼저 Target에서 지정하는 것은 대상장비의 IP 주소나 도메인주소, 대상포트번호, community name, 장비이름(lable명)등이 있다.
Target이란 옵션의 용도는 한마디로 MRTG를 통해서 모니터링할 대상장비의 설정이라고 할 수 있다.
참고로 MRTG제작회사에서 배포한 MRTG문서의 원문에서는 Target에 대해서 다음과 같이 알리고 있다.
"The Target keyword you tell mrtg what it should monitor"
[ns.kebia.net_2]
이는 대상장비의 이름이라고 할 수 있다.
, 다른 장비들(내의 포트들)을 구분하기위한 방법이며 mrtg실행결과 생성되는 웹페이지의 파일들이 이 이름으로 생성이된다.
, ns.kebia.net_2.html, ns.kebia.net_2.png등과 같이 생성이 되며 따라서 웹페이지를 볼 때에도 이 이름으로 불러봐야한다.
http://traffic.superuser.co.kr/ns.kebia.net_2.html로 웹브라우즈에서 볼러보면 되는 것이다.
2
대상장비(스위치, 라우터등)의 포트번호이다.
즉 라우터나 스위치에서는 하나의 포터만이 있는 것이 아니라 여러개의 포트(4, 8, 16, 24등 다양함)들이 존재하며 MRTG에서는 주로 이 포트들을 대상으로 모니터링을 하게된다.
여기서 public 앞에 붙은 번호는 라우터나 스위치의 모니터링대상 포트이다.
public
이것은 community name이다.
community name이란 SNMP의 일반적인 보안을 위해서 사용하는 인증암호와 같은 것으로 기본값으로 public을 갖는다.
하지만 보안을 위해서는 다른 값으로 설정할 것을 권한다.
대부분 MRTG의 실행에서 에러가 발생하는 원인이 이 community name이 정확하지 않아서 발생하는 에러이다.
ns.kebia.net
이것은 대상장비의 도메인이거나 ip address이면 된다.
, 모니터링하고자 하는 대상을 정확히 구분하기 위하여 대상장비의 ip 또는 도메인을 정확히 입력하면 된다.
우선 여기서는 Target이란 옵션에 대해서 정확히 이해를 하고 넘어가는 것만을 목표로 삼자.
앞으로 수도없이 나올 cfg파일내에서 Target이란 옵션은 반드시 들어가게 될 것이므로.....
Target옵션에을 설정하는 방법에는 다양한 방법이 있으며 이에 대한 설명을 "MRTG Configuration File Format"에서 하게 될 것이므로 이쯤에서 넘어가기로 하자.
SetEnv
환경변수할당의 일종으로서 외부프로그램이나 스크립트등에서 call 되었을 경우에 넘겨줄 변수와 값들을 설정한 것이다.
이 예는 cfgmaker로 cfg파일을 생성했을 경우에 자동생성된 것이며, 이외에도 다음과 같은 설정이 가능하다.
, 위와 같이 cfg파일에 설정이 되어있었을 경우에 외부프로그램이나 스크립트에서 EMAIL값이나 HOST, URL등의 값을 요구했을 때 각각 할당된 값을 넘겨주게 되는 것이다.
이런 외부환경변수 설정은 MRTG를 이용하여 자체적으로 사용하거나 응용프로그램을 개발시에도 주로 참조가 된다.
MaxBytes
대상장비또는 해당포트(라우터나 스위치의경우)의 최대전송가능 byte수를 지정한다.
, 해당포트가 전송가능한 초당 byte수를 지정하면 된다.
만약, 지정한 수치보다 높은 값이 리턴되어 오면 MRTG는 이값은 무시해버린다.
Title
mrtg실행결과 생성되는 html파일의 <title> 제목</title> 부분에 들어가는 "제목"이다.
, 웹브라우즈의 맨위에 나타나는 제목부분에 나타나는 부분이란 의미이다.
주의 할 것은 바로 뒤에 설명되는 PageTop에서 맨 처음나타나는 부분과 Title부분을 혼돈해서는 안된다.
PageTop은 단지 웹페이지의 최상단에 나타낼 내용임을 주지하기 바란다.
PageTop
mrtg실행결과 생성되는 html파일의 최상단에 출력될 내용이다.
몇 개의 라인으로 구성할 수도 있으며 뒤따르는 모든 라인또한 최상단에 이어서 출력되며, 라인과 라인을 구분할 때에는 "\n"을 사용하면 된다.
참고로 위의 결과 생성되는 MRTG 샘플을 보이면 다음과 같다.
위의 예를 보는 바와 같이 PageTop이하의 내용들이 결과 웹페이지내에서 최상단에 출력됨을 알 수 있다 .
따라서 PageTop에 주로 들어가는 내용들은 MRTG로 분석된 결과페이지들의 제목이나 간략한 설명등이 들어가게 된다.
, 현재 보고 있는 페이지의 대상장비나 대상네트웍에 대한 간략한 소개나 구분정도로 해두면 된다.
MRTG에는 이외에도 다양한 옵션들이 많이 있다.
이들 다양한 옵션에 대해서는 "MRTG Configuration File Format"을 보기 바란다.
4. mrtg 초기실행하기
, 이제 MRTG의 cfg에 관련된 설정들이 모두 끝이났다.
이제 해야할 것은 mrtg를 실행을 시켜서 정상적으로 실행이되는가를 확인하는 작업니다.
물론 mrtg는 cron에 등록되어 자동적으로 주어진 주기(일반적으로는 5분에 1회)에 한번씩 실행이 된다 .
하지만, 아직 cron에 등록되기전이므로 지금까지 만든 cfg파일로 mrtg를 실행시켜보자.
처음 실행은 /usr/local/mrtg/bin/에 있는 실행파일인 mrtg를 이용해서 실행토록 하자.
  • 실행파일 : /usr/local/mrtg/bin/mrtg (가능한 절대경로를 사용하는 것이 에러를 줄이는 지름길이 된다.)
  • 환경파일 : /home/mrtg/conf/kebia_1.cfg (지금까지 고생해서 만든 cfg파일)
  • 실행방법 : /usr/local/mrtg/bin/mrtg /home/mrtg/conf/kebia_1.cfg (쉘프롬프트에서 실행)
아래 실행예를 보기 바란다.
위의 예와 같이 똑같은 명령을 모두 3회를 실행시켰는데 처음실행과 두 번째 실행에서 각각 이상한 경고메시지(WARNING)가 발생을 했다.
그리고 세 번째 실행에서는 경고(WARNING) 가 발생하지를 않았다.
개론부분에서 자세히 설명드린 바와같이 MRTG는 각각 실행한 값들의 비교계산한 값들로 그 수치를 얻어내는데, 처음실행과 두 번째 실행에서는 비교값들이 존재하지 않아서 발생한 메시지이므로 이는 처음실행시에 당연히 발생하는 경고로 걱정할 것은 못된다.
세 번째 실행에서는 에러가 발생하지 않았다는 것은 비교할 값들이 존재하므로 정상적인 mrtg 실행수치를 얻어냈다는 것을 의미한다.
, 그럼 실행결과 생성된 결과 파일들을 보도록 하자.
cfg파일내에서 WorkDir의 값을 /home/mrtg/www/kebia_1로 주었으므로 이 위치로 가서 "ls -l"을 한 결과를 보이고 있는 것이다.
유의해서 볼 것 몇가지만 언급하자.
먼저 html파일의 이름(ns.kebia.net_2)이 cfg파일의 Target부분의 "[ ]"에서 지정된 것임을 확인하자.
그리고, 생성된 파일들의 종류를 보면 html, log, old과 같은 파일들임도 확인토록하자.
앞서 설명을 드렸지만, 이제 생성된 결과를 웹브라우즈에서 불러보면 되며 이때에 불러볼 파일명도한 html파일명(ns.kebia.net_2.html)임도 함께 확인토록 하자.
5. 결과확인 및 분석하기
이제 온전한 결과페이지를 확인해 보자.
정상적인 결과페이지가 생성이 되었다면 아래와 같을 것이다  여기 페이지에  ip address 192.168.0.5로 바꿀것..
결과페이지로 생성된 4개의 결과페이지를 간단히 설명하면 다음과 같다.
일간그래프

   - 5분단위 평균값을 기준으로 하여 생성된 그래프
주간그래프
   - 30분 단위 평균값을 기준으로 하여 생성된 그래프
월간그래프
  - 2시간 단위 평균값을 기준으로 하여 생성된 그래프
년간그래프
  - 일일 단위 평균값을 기준으로 하여 생성된 그래프
그래프에서의 파란색
   - 대상장비에서 외부로 송신된(빠져나간) 트래픽량을 나타냄.
그래프에서의 초록색
   - 외부네트웍에서 대상장비로 수신(들어온) 트래픽량을 나타냄.
6. 결과페이지 로딩시 암호인증걸기
여기까지 해서 mrtg의 설정작업이 마무리되었다.
하지만, 이제 정기적인 mrtg실행을 위한 cron작업과 트래픽정보는 보안사항이므로 관계자외에는 보게해서는 안되므로 mrtg 실행결과 생성되는 웹페이지에 암호인증설정을 해야한다.
암호인증설정하는 방법은 여러 가지가 있지만 여기서는 아파치(Apache)제공 유틸리티인 htpasswd를 이용토록 할 것이다.
이책의 뒷부분에 가면 실무프로젝트를 다루었으며 좀더 강화된 보안을 위한 암호인증을 위해 mysql과 php로 웹프로그래밍을 하여 인증하는 방법에 대해서 소개하고 있으므로 참조바란다.
먼저, htpasswd로 암호인증을 위해서는 다음과 같은 것이 필요하다.
  • .htaccess파일생성
  • htpasswd 유틸리티위치확인
  • htpasswd 로 .htpasswd파일 생성하는 방법
.htaccess파일만들기
mrtg실행결과 생성되는 웹페이지파일들이 존재하는 디렉토리(/home/mrtg/www/)에서 다음과 같은 내용을 가진 .htaccess파일을 생성해준다.
주의할 것은 .htaccess파일이 점(.)으로 시작한다는 것이다.
위의 내용을 간단히 설명하면 다음과 같다.
  • AuthName : 트래픽분석 관리자페이지의 적당한 제목을 임의대로 적는다.
  • AuthType : 인증타입은 일반적으로 Basic으로 한다
  • AuthUserFile : ID와 암호가 존재할 위치와파일명
  • AuthGroupFile : 그룹으로 인증확인을 할경우에 그룹인증파일명을 적는다.
  • <Limit> ~ </Limit> : require valid-user 인증이 유효한 사용자만 접근가능토록한 설정
위와 같이 적당한 .htaccess파일을 만들었으면 이제 .htpasswd파일을 만들어줄 차례이다.
먼저 htpasswd라는 유틸리티가 어디에 존재하나를 확인한다.
확인하는 방법은 "which htpasswd"로 하거나 또는 "find / -name htpasswd -print"로 찾아볼 수도 있다.
대부분은 아파치 설치디렉토리 아래의 bin 디렉토리(/usr/local/apache/bin)에 존재하고 있다.
아래와 같이 htpasswd를 처음 실행할 때에는 반드시 -c (create option)을 사용해야 .htpasswd라는 파일이 만들어 진다.
.htpasswd 파일을 생성한 후에 cat 명령어로 정상적으로 ID와 패스워드가 생성이 되었는가를 확인한 것이다.
이제 웹브라우즈를 통해서 이 페이지를 다시 불러보자.
앞에서와는 달리 ID와 패스워드를 입력하라는 창이 뜨게 된다.
이 창에 좀전에 생성했던 ID와 패스워드를 입력해주면 정상적인 접근이 가능하게 된다.
7.cron에 mrtg주기적인 실행 설정하기
 여기까지 오느라 정말 고생이 많았으리라 생각이 된다.
하지만 이제 MRTG의 실행이 모두 정상적으로 이루어 졌으므로 이제 남은 것은 주기적으로(일반적으로 5분간격) MRTG를 실행시키는 작업만이 남아있을 뿐이다.
따라서 모든 cfg파일이 들어있는 mrtg스크립트파일 mrtg.sh 파일을 아래와 같이 만들어서 이 파일을 cron에 등록하기만 하면 된다.
mrtg.sh파일의 내용
이미 설명을 드렸지만 확인하는 의미에서 말씀드린다면 이파일의 위치는 /home/mrtg/bin/mrtg.sh 파일이다.
이제 이 파일을 root의 crontab에 등록을 할 것이다.
crontab이란 주기적으로 어떤 프로그램을 실행시키기 위해서 등록을하는 cron테이블이다.
crontab에 등록을 하기 위해서는 "crontab -e"란 명령어를 아래와 같이 입력하면 현재 사용중인 사용자의 cron설정을 할 수가 있다.
MRTG의 cron은 root로 설정하거나 mrtg계정의 cron에 등록하나 둘중 하나에 하면 된다.
아래와 같이 "crontab -e"를 하게되면 vi모드와 같이 입력을 할 수 있다.
위의 cron설정은 매 5분마다 /home/mrtg/bin/mrtg.sh 스크립트를 실행하게한 설정이다.
이제 crontab에 등록된 내용을 확인해보도록 하자.
확인은 아래의 예와 같이 "crontab -l"을 하면 현재 사용중인 계정의 crontab등록상황을 보여주게 된다 .
 이제 5분마다 mrtg.sh파일에 등록되어 있는 mrtg가 실행이 되어 cfg파일에 설정되어 있는 WorkDir 디렉토리에 mrtg의 결과인 웹파일들을 저장하게된다.  

Network] mrtg를 이용한 다양한 자원 관리


1. 다양한 자원분석 사용량분석 개론
MRTG로 분석가능한 자원은 많이 있다.
그중 가장 대표적인 것이 네트웍트래픽분석이다.
앞장에서 설명드린 내용은 이런 트래픽을 웹화면에서 모니터링하는 방법에 대한 것을 다루었다.
이번장에서는 네트웍장비의다양한 자원의 사용량을 분석하는 방법을 CPU사용량을 웹에서 모니터링하는 방법에 대해서 설명할 것이다.
먼저, mrtg로 트래픽뿐아니라 cpu, memory, disk등의 다양한 자원에 대한 분석을 하려면 ucd-snmp를 업그레이드해야한다.
사용중인 ucd-snmp의 버전이 4.1대라면 4.2대로 업그레이드하기 바란다.
CPU사용량 모니터링을 하는 방법또한 앞장과 많이 유사하다.
단지, cfg파일(Configuration file)이 조금 다를 뿐이다.
따라서 이장과 다음장에 나오는 MEMORY사용량분석에서는 앞장에서 설명한 트래픽분석부분과의 중복되는 부분은 생략하고 주로 cfg파일을 위주로 설명이 될 것이다.
우선, ucd-snmp에 대해서 좀 알아보자.
현재 필자가 MRTG서버로 구축하는 서버는 레드햇리눅스이다.
아마도 최신버전의 리눅스라면 ucd-snmp 4.2.X가 깔려 있을 것이다.
여러분의 서버에 설치되어 있는 ucd-snmp가 4.1.X라면 4.2.X로 업그레이드하기를 권한다.
우선 현재 사용중인 snmp의 버전을 확인해 보자.
확인하는 방법은 "snmpd -v"를 하면 다음과 같이 현재 사용중인 snmp의 버전을 확인할 수 있다. 
확인한 바와 같이 현재 snmp의 버전은 ucd-snmp 4.1.2이다.
ucd-snmp의 최신버전은 4.2.1로서 다운을 받으려면 net-snmp.sourceforge.net에 방문해 보기 바란다.
잠깐만 언급한다면 ucd-snmp는 현재 그 이름이 net-snmp로 불리우고 있다.
최신번전은 2001년 4월달에 발표된 것으로 현재 트래픽분석뿐아니라 다양한 자원분석을 위해 많이 사용되고 있는 프로토콜이다.
4.2.X로 버전업 하는 구체적인 방법에 대해서는 "UCD-SNMP 버전업하기"편에 자세히 설명이 되어있다. 을 참조하기 바란다.
이를 참조하여 버전을 하였다면 다음과 같이 snmp의 버전을 다시한번 확인해 보도록 할 것이다.
2. 관련 MIB 확인하기
우선 트래픽외의 다양한 자원을 분석하기위해서는 대상 MIB정보를 확인해야한다.
ucd-snmp 4.2.1버전의 SNMP를 정상적으로 설치하였다면 이런 MIB값에 대한 정보를 제공하는 파일들이 /usr/local/share/snmp/mibs/디렉토리에 txt파일로 존재한다.
분석코자하는 대상자원의 MIB정보를 가진 txt 파일을 이 디렉토리에서 확인하여 cfg파일내에 LoadMIBs라는 옵션으로 참조하게만 하면된다.
이 디렉토리에 존재하는 파일들중에 CPU라는 자원을 MRTG로 분석하기 위해서는 UCD-SNMP-MIB.txt라는 파일이 필요하다.
따라서 다음절에 나올 cfg파일분석편에 보시면 LoadMIBs로 이 파일을 읽어들이는 것을 확인할 수 있을 것이다.
, cpu라는 자원에 대한 MIB정보는 어떤 것들이 있을까?
UCD-SNMP-MIB.txt파일내에 cpu와 관련된 MIB정보를 확인해 보자.
다음표는 UCD-SNMP-MIB.txt파일내용중 CPU와 관련된 MIB값들이다.
. CPU관련 MIB값
객체
구문
접근권한
Status
설명
비고
ssCpuUser
Integer32
read-only
Current
사용자 CPU time 퍼센트
::= { systemStats 9 }
ssCpuSystem
Integer32
read-only
Current
시스템 CPU time 퍼센트
::= { systemStats 10 }
ssCpuIdle
Integer32
read-only
Current
CPU idle time 퍼센트
::= { systemStats 11 }
ssCpuRawUser
Counter32
read-only
Current
사용자 CPU 시간
::= { systemStats 50 }
ssCpuRawNice
Counter32
read-only
Current
nice CPU 시간
::= { systemStats 51 }
ssCpuRawSystem
Counter32
read-only
Current
시스템 CPU 시간
::= { systemStats 52 }
ssCpuRawIdle
Counter32
read-only
Current
idle CPU 시간
::= { systemStats 53 }
ssCpuRawWait
Counter32
read-only
Current
iowait CPU 시간
::= { systemStats 54 }
ssCpuRawKernel
Counter32
read-only
Current
커널 CPU 시간
::= { systemStats 55 }
ssCpuRawInterrupt
Counter32
read-only
Current
interruptlevel CPU 시간
::= { systemStats 56 }
위의 표를 보면 대충 어떤 MIB값을 사용해야하는 가를 알 수 있을 것이다.
위의 표 "설명"부분을 참조하여 CPU의 어떤사용률에 대한 분석을 하거픈가를 확인하면 된다.
참고로 이책에서 실습대상으로 하는 MIB값은 위의 표중에서 "ssCpuRawUser"와 ssCpuRawIdle"이다.
, 사용자 프로세스가 사용한 CPU사용시간과 CPU가 한가하게 놀았던 시간(idle time)에 대한 분석이될 것이다.

다음표는 UCD-SNMP-MIB.txt파일내용중 MEMORY와 관련된 MIB값들이다.
. MEMORY관련 MIB값
객체
구문
접근권한
Status
설명
비고
memIndex
Integer32
read-only
current
Bogus Index, 항상 0 리턴
::= { memory 1 }
memErrorName
DisplayString
read-only
current
Bogus Name, 항상 'swap'문자리턴
::= { memory 2 }
memTotalSwap
Integer32
read-only
current
전체 swap공간
::= { memory 3 }
memAvailSwap
Integer32
read-only
current
사용가능한 swap 공간
::= { memory 4 }
memTotalReal
Integer32
read-only
current
전체 물리적인(RAM) 공간
::= { memory 5 }
memAvailReal
Integer32
read-only
current
사용가능한 물리적인 공간
::= { memory 6 }
memTotalSwapTXT
Integer32
read-only
current
사용된 가상메모리공간
::= { memory 7 }
memAvailSwapTXT
Integer32
read-only
current
사용중인 가상메모리공간
::= { memory 8 }
memTotalRealTXT
Integer32
read-only
current
사용된 전체 물리적인 메모리공간
::= { memory 9 }
memAvailRealTXT
Integer32
read-only
current
사용중인 실제메모리공간
::= { memory 10 }
memTotalFree
Integer32
read-only
current
전체사용가능한 메모리
::= { memory 11 }
memMinimumSwap
Integer32
read-only
current
비워질 수 있는 swap공간의 최소크기를 리턴하거나 memErrorSwap이 1로 셋팅되어 있을 경우 memSwapErrorMsg에 에러문자리턴
::= { memory 12 }
memShared
Integer32
read-only
current
전체공유메모리 크기
::= { memory 13 }
memBuffer
Integer32
read-only
current
버퍼링된 메모리크기
::= { memory 14 }
memCached
Integer32
read-only
current
캐싱된 메모리크기
::= { memory 15 }
memSwapError
Integer32
read-only
current
Error Flag 리턴. Flag가 1일 경우 여유swap공간이 거의 없음을 의미함.
::= { memory 100 }
memSwapErrorMsg
DisplayString
read-only
current
Error Flag상태를 알리는 에러메시지리턴
::= { memory 101 }
   
다음표는 UCD-SNMP-MIB.txt파일내용중 DISK와 관련된 MIB값들이다.
. DISK관련 MIB값
객체
구문
접근권한
Status
설명
비고
dskTable
SEQUENCE OF DskEntry
not-accessible
current
SNMP Agent의 snmpd.conf에 의해 설정되어 watching된 부분. 디스크의 watching정보.
::= { ucdavis 9 }
dskEntry
DskEntry
not-accessible
current
디스크나 디스크 통계치를 포함한 엔트리(Entry)
::= { dskTable  1 }
dskIndex
 Integer32 (0..65535)
read-only
current
디스크 mib를 참조한 (행)수
::= { dskEntry 1 }
dskPath
DisplayString
read-only
current
마운트된 디스크의 패스정보
::= { dskEntry 2 }
dskDevice
DisplayString
read-only
current
파티션된 디바이스 패스정보
::= { dskEntry 3 }
dskMinimum
Integer32
read-only
current
에러발생전의 최소디스크요구공간의 크기(단 위 : kBytes)
::= { dskEntry 4 }
dskMinPercent
Integer32
read-only
current
에러발생전의 최소디스크요구공간의 퍼센티지
::= { dskEntry 5 }
dskTotal
Integer32
read-only
current
디스크파티션의 총크기
(단위 : kBytes)
::= { dskEntry 6 }
dskAvail
Integer32
read-only
current
사용가능한 디스크공간크기
::= { dskEntry 7 }
dskUsed
Integer32
read-only
current
사용중인 디스크공간의 크기
::= { dskEntry 8 }
dskPercent
Integer32
read-only
current
사용중인디스크공간의 퍼센티지
::= { dskEntry 9 }
dskPercentNode
Integer32
read-only
current
사용중인 inode의 퍼센티지
::= { dskEntry 10 }
dskErrorFlag
 Integer32
read-only
current
에러를 위해 설정된 최소공간의 디스크(파 티션) 에러 Flag 시그널
::= { dskEntry 100 }
dskErrorMsg
DisplayString
read-only
current
여유공간과 경고(warning) 메시지
::= { dskEntry 101 }

이제 이들 MIB값들을 이용하면 MRTG를 통해서 이와 관련된 정보를 모니터링해볼 수 있다.
다음장에서는 이런 MIB값을 가지고 MRTG의 트래픽분석을 위한 Configuration File을 만들어 보도록 할 것이다.

3. Configuration file 만들기
아래와 같은 cfg파일을 만들어 보았다.
분석하려는 구체적인 객체를 /usr/local/share/snmp/mibs/UCD-SNMP-MIB.txt 파일에서 확인한 다음 Target에 아래 예와 같이 설정해 주면 된다.
물론,  LoadMIBs 옵션에 UCD-SNMP-MIB.txt 파일의 위치를 지정해 주는 것도 잊지 말아야 할 것이다.
  • CPU 모니터링을 위한 Configuration file
물론 아래와 같은 cfg파일이 아니더라도 cpu분석은 가능하다.
  • MEMORY 모니터링을 위한 Configuration file
  • DISK 모니터링을 위한 Configuration file
다른 Configuration File들과는 조금 다른 것이라면 디스크의 사용량분석을 위해 대상파티션을 지정해줘야한다는 것이다.
, dskPercent.1 과 dskPercent.2는 각각 루트파티션(/) 과 usr파티션(/usr)에 해당하며, 이들의 설정을 Legend1과 Legend2, 그리고 LegendI와 LegendO에 각각 설정하였다.
그리고, 무엇보다 중요한 것은 디스크의 모니터링을 위한 대상 파티션의 설정을 /usr/local/share/snmp/snmpd.con 파일내에서 다음과 같은 설정을 해야한다.
, 모니터링의 대상이 되는 파티션의 설정을 위와 같이 한후에 snmpd를 다시 띄워야한다.
 cfg 파일에서 설정한 각 options들에 대한 설명은 다음장에서 설명된다.
참고로, 이런 cfg파일 작성 및 구성에 대한 예제파일들은 아래의 URL에서 찾아볼 수 있으려 이를 그대로 적용하기보다는 좀더 다양한 방법으로 수정해서 사용해보는 것이 발전이 지름길이 될 것이다.
4. cfg파일 분석
여기서 설명되는 옵션들은 앞장에서 설명된 것과 "MRTG Configuration File Format"편에 자세히 설명되었으므로 여기서는 CPU사용량분석이라는 초점에 맞추어서 설명됨을 유의하기바란다.
Language
웹페이지에 한글을 사용하기위한 설정.
WorkDir
mrtg의 실행결과 생성되는 웹페이지들이 저장될 디렉토리경로 설정
LoadMIBs
CPU과련 MIB값을 저장하고 있는 파일  Include 설정
Target
CPU자원을 분석하기위한 MIB값의 설정.
  • kebia_2_cpu : 대상자원의 이름이며, 생성되는 웹파일들의 이름또한 여기서 설정된 이름이 사용된다.
  • ssCpuRawUser.0 : 사용자프로세스가 차지하는 CPU사용량의 MIB객체지정.
  • ssCpuRawIdle.0 : CPU의 idle time 값의 MIB객체 지정.
  • public : SNMP로 통신하기위한 community name.
  • 192.168.0.5 : 대상객체의 IP Address 또는 도메인명
위의 표를 참조하여 CPU관련된 다른 MIB값들을 참조하여 다양한 분석이 가능하다는 것을 인지하기 바란다.
Options
growright : 오른쪽에서부터 그래프가 생성이됨.
nopercent : 결과로 생성되는 웹페이지내의 그래프에서 퍼센트표시를 나타내지않음.
MaxBytes
CPU의 전체사용량을 100으로 설정.
Title
생성되는 웹(html)파일에 <title>제목</title>에 들어갈 제목부분 설정.
웹브라우즈로 결과를 보았을 때 웹브라우즈의 최상단 바(bar)에 나타나는 제목으로 확인하거나 "소스보기"등으로 확인가능.
RouterUptime
이설정은 동일한 라우터를 사용하여 동일한 분석을 여러개 동시에 분석할 경우에 community name과 address를 여러번 반복하여 사용하지 않도록 하기위한 설정이다.
Unscaled
4개의 그래프 즉, day, week, month, year 그래프에서 Y축그래프가 MaxBytes에서 지정한 수치에 미치지 못하는 부분을 축약(생략)하여 표현하기위한 설정이다.
, 불필요한 부분을 보지 않기위한 설정이라는 것을 의미한다.
YLegend
Y축 그래프에 대한 설명표를 "CPU Utilization"이라고 나타낸다.
Legend1
결과 웹페이지의 하단에 표시되는 그래프의 색깔에 대한 설명을 붙인 것이다
, 첫 번째 그래프(여기서는 녹색)색깔에 대한 설명을 "User CPU in % (Load)"로 하겠다라는 설정임.
Legend2
Legend1과 마찬가지로 그래프(여기서는 청색)색깔에 대한 설명을 "Idel CPU in % (Load)"로 하겠다라는 설정임.
LegendI
4개의 그래프(일,주,월,년) 각각의 하단에 INPUT표시의 설명을 "User"로 하겠다라는 설정임.
, 각각의 그래프에서 INPUT에 해당하는 것이 무엇을 뜻하는 것인가를 설명하기 위한 것이며, 여기서는 사용자프로세스에 대한 그래프의 색깔이므로 "User"로 설정한 것임.
LegendO
LegendI와 마찬가지로 OUTPUT에 해당하는 그래프의 색깔 설명을 "Idle"로 설정한 것임.
PageTop
mrtg 실행결과 생성되는 웹페이지의 최상단에 나타낼 내용임.
5. mrtg 초기실행과 웹페이지 생성확인
이제 cfg파일의 생성과 이에대한 설명까지 끝났다.
이제 남은 것은 이 cfg파일로 mrtg를 실행하고 그 결과 지정한 디렉토리에 웹페이지들이 생성이 되는가를 확인한 다음 웹브라우즈로 확인을 해보도록 할 것이다.
아래와 같이 mrtg를 실행시켜보자.
mrtg를 처음실행시킬 때에는 mrtg 실행파일의 경로를 절대경로로 해서 실행하는 것이 습관이 되면 좋을 것이다.
mrtg를 처음실행시키면 트래픽분석에서 보았던 것 처럼 동일한 에러가 발생한다.
동일한 실행은 몇회 계속하게되면 이런 에러는 발생하지 않는다.
이제 cfg파일의 WorkDir에서 지정한 디렉토리로 가서 웹파일들이 생성이 되었는가를 확인해 보자.
앞에서는 볼 수 없었던 파일종류가 하나 있을 것이다
*.png, *.html, *.log, *.old 파일들은 트래픽분석에서도 볼 수 있었던 것이나 *.txt파일은 여기서 처음 생성된 것이다.
이것은 cfg파일에서 LoadMIBs를 사용하였기 때문에 생성된 파일로서 LoadMIBs에서 지정한 UCD-SNMP-MIB.txt파일내의 모든 MIB값들이 필요한 것이 아니기 때문에 다음에 실행할 때에 사용하기위한 것으로 필요한 MIB값을 oid형태의 파일로 보관한 것이다.
아래는 이 파일의 내용이다.
보시는 바와 같이 UCD-SNMP-MIB.txt내의 많은 MIB값들중 두 개(ssCpuRawUser, ssCpuRawIdle)만을 사용했으므로 이 두 개의 oid값만이 들어가 있는 것이다.
6. 웹브라우즈로 결과확인
자 이제 모든 실행이 끝나고 그 결과를 웹브라우즈로 확인해 보도록 하자.
cfg파일 설명부분에서 설명했던 것을 참조하여 결과 웹페이지가 어떻게 나타났는지 확인하기 바란다.
cfg파일을 수정함으로써 원하는 결과를 다르게 나타내는 것을 각자 해보기바란다.
  • CPU 사용량 모니터링 분석 결과확인
  • MEMORY 사용량 모니터링 분석 결과확인
  • DISK 사용량 모니터링 분석 결과확인
7. 마무리 작업
웹브라우즈로 결과까지 확인을 했다.
이제 트래픽분석의 마지막에 했던 것과 마찬가지로 결과 웹페이지를 로딩할 때에 ID와 패스워드를 입력받도록 하기위한 설정과  주기적인 mrtg실행을 위하여 cron파일에 등록하는 것을 잊지 말자