분산 모니터링 시스템 계획
 대문  주제별 보기  함수사전  코드모음  바뀐글  목록   Anonymous
총 페이지 수 : 3224

전체 함수/용어사전
Facebook Joinc 그룹   Joinc QA 사이트
현재위치 : 미니사이트>QA>DistributeMoniter



joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.

Contents

1 분산 모니터링
2 사용 기술들
2.1 기술 선택을 위한 조건
2.2 정보 수집
2.3 정보 분석
2.3.1 통계 데이터 생성
2.3.2 RAW 데이터 분석
2.4 이슈 관리
2.5 배포 시스템
2.6 Dash Board
3 시스템 설계
3.1 정보 수집
3.2 HTTP를 이용한 정보 수집
3.2.1 수집 서버 구성
3.2.2 Target 서버 구성
3.3 배포 시스템
3.3.1 배포 운영체제 환경
3.4 이벤트 관리
3.4.1 티켓 발행과 처리
4 장비 이력 관리
5 개발 이슈
5.1 분산 수집
5.2 분산 처리
5.3 대략 관제 시스템
5.4 대략 Ticket 처리 시스템
6 전체 구성

1 분산 모니터링

이전에는 몇 개의 강력함 컴퓨터로 데이터를 처리했기 때문에, 이들 컴퓨터를 제어하는 것도 큰 문제가 되지 않았다.

하지만 클라우드 컴퓨팅 시대의 돌입한 지금은 상황이 좀 다르다. 우리나라는 약 3년전인 2008년쯤 부터 공개소프트웨어를 중심으로 이 분야에 관심을 가지기 시작해서, 지금은 응용 단계에 이른 것으로 보인다. 관련 제품을 전문적으로 취급하는 회사도 있다.

클라우드 컴퓨팅은 강력한 소수의 컴퓨터로 데이터를 처리하는 방식이 아니다. 비교적 저렴한 다수의 컴퓨터를 이용해서 데이터를 처리하게 되는데, 모니터링 해야 하는 자원의 양이 늘어나니 기존의 모니터링 툴로는 한계에 부닥치게 된다. 최대 100 대 정도의 시스템을 모니터링 해야 하는 것과 최소 수천대에서 수만대까지 모니터링 해야 하는 툴은 완전히 다른 기술을 사용할 수 밖에 없기 때문이다.

이와 관련 상업용의 분산 자원관리 시스템이 있는 것으로 알고 있다. Zenoss 와 같은 공개 소프트웨어도 분산 자원 관리 시스템을 지향하고 있다.

Zenoss와 같은 경우 오픈 소스 버전과 상용 버전으로 라이선스 정책을 가져가고 있는 것으로 알고 있다. 상용 버전의 Zenoss가 분산 자원 관리 시스템을 지원한다고 한다. 이전에 한 2년 정도 공개 버전의 Zenoss를 사용해 본적이 있는데, 관리 자원의 갯수가 늘어나면서 효율적인 모니터링에 문제가 생기는 것을 경험했다.

여기에서 나는 이들 제품을 소개할 마음은 없습니다. 이런 류의 제품을 다루어본 경험으로 어떤식으로 시스템을 구성해야 다수의 자원을 효과적으로 모니터링 할 수 있을지에 대한 고민을 하려합니다

2 사용 기술들

분산 모니터링은 두 개의 기술적 범주로 나눌 수 있겠네요. 하나는 모니터링 기술이고 다른 하나는 분산 데이터 처리 기술이겠죠. 모니터링은 대게 모니터링 서버에서 일정 시간 간격으로 데이터를 수집하는 방식으로 이루어지는데, 관리 자원의 개수가 많아지면 데이터를 수집하는 자체가 문제될 수 있을 겁니다. 데이터 처리도 마찬가지구요. 자원이 분산되는 만큼 모니터링 기술도 이에 대응할 수 있어야 한다 이런거죠.

여기에서는 아이디어만 제시합니다. 자세한 내용은 기술별로 다룰 생각입니다.

2.1 기술 선택을 위한 조건

많은 기술들이 있을 건데, 다음과 같은 조건을 만족하는 툴을 선택하기로 했다. 개발할 경우에도 아래의 조건을 만족해야 한다.
  1. 공개 기술
    상용 제품은 제외한다.
  2. 쉽게 다룰 수 있는 언어
    Python, Perl, PHP 등으로 구성한다.
  3. 통합
    웹으로 쉽게 통합 가능해야 한다. HTTP와 REST를 이용한 방법과 FUSE를 이용한 방법 중 하나를 선택하려고 한다. 이들 방법에 대한 아이디어는 따로 정리 할 생각이다.

2.2 정보 수집

모니터링을 위한 툴들을 정리했다.
  • SNMP : 일단 SNMP는 기본 지원해야 되지 싶다.
    SNMP를 어느 수준에서 사용할지도 고려해야 한다. 단지 구성정보를 수집하는 정도로만 할건지 아니면, 활용할 수 있는 모든 정보를 사용할 건지. 일단 초기에는 SNMP에 맡기고, 점차적으로 Agent로 정보를 얻어오게 할 생각이다. 마지막에는 SNMP를 Agent로 전부 대체하는게 낫지 싶다. 물론 이건 관리 대상 시스템이 사내 시스템일 경우에 선택가능한 옵션일 것이다.
  • Agent : SNMP로 수집할 수 없는 정보들이 있다. 이들 정보는 Agent를 설치해서 수집해야 겠다. Agent는 언어에 상관없이 작동할 수 있도록 할 계획이다. 정보 포맷은 Nagios의 형식을 따를 것이다. Nagios는 꽤 널리 사용하고 있는 모니터링 시스템인데, 많은 Agent들이 공개돼 있어서 이들 툴을 그대로 사용할 수 있다는 장점도 누릴 수 있겠습니다.

2.3 정보 분석

수집한 정보는 분석해야 겠죠. 두 가지 방법이 있겠습니다. 미리 통계자료를 만드는 방법과 RAW 데이터를 쌓아두고 필요할 때, 분석해서 원하는 정보를 얻는 방법입니다.

2.3.1 통계 데이터 생성

Disk, CPU, Memory, 네트워크 사용율등의 정보는 시간이 지난 정보에 대해서는 RAW 데이터를 남길 필요는 없습니다. 추이만 보면 되기 때문이죠. 그래서 하루, 일주, 한달, 일년 주기로 통계를 만들어서 저장을 합니다. 데이터의 크기가 고정이 되기 때문에 디스크 공간을 아낄 수 있고, RAW 데이터를 분석할 필요가 없으니 빠르게 정보를 확인할 수 있다는 장점이 있습니다.

이들 정보는 RRD같은 툴을 이용하면 쉽게 통계 정보로 만들 수 있습니다. 제가 애용 하는 툴이기도 하구요.

2.3.2 RAW 데이터 분석

2005년 쯤 하나로 IDC에서 관리자/고객 시스템 관리 소프트웨어를 만든적이 있었는데요. 그 때도 RAW 데이터를 저장해 두었다가 나중에 레포트를 만드는 시스템이 있긴 했지만, 쓸모가 좀 애매모호 했습니다. 지금이야 NoSQL 기반 기술을 사용할 수 있겠지만, 당시에는 SQL로 질의어 노가다를 했어야 했거든요. 시간도 시간일 뿐더러, 다양한 레포트를 만들기가 수월치 않았습니다. RDBMS는 구조적인 데이터에 적합한 언어로 테이블 설계시 레포트의 종류가 특정되기 때문이죠.

NoSQL 중 MongoDB가 끌리는 군요. 용도에 맞는지 한번 살펴봐야 겠습니다.

2.4 이슈 관리

이전에 네트워크/시스템 관리를 위해서 Zenoss를 사용했습니다. 훌륭한 도구이긴 한데 문제가 좀 있습니다. 정보 수집과 이벤트 발생은 훌륭한데, 이벤트를 관리하기 위한 방법이 없다는 거죠.

그래서 Zenoss와 연동되는 wiki 기반의 이슈 관리 시스템을 만들어서 사용했습니다. Zenoss는 이벤트가 발생할 경우 스크립트를 실행할 수 있는데, wiki에 이슈를 전달할 수 있도록 스크립트를 만들었습니다. wiki에 전달된 이슈는 해당 장비 담당자에게 Ticket으로 발행되서 처리하게 했다.

Ticket 기반의 이슈관리 시스템을 만들려면, 장비와 소프트웨어 별로 담당자가 정해져 있어야 하니 장비및 사용자 관리 시스템도 필요하겠다. 이래 저래 신경써야 할게 많은데, Bugzilla에서 아이디어를 얻어서 개발했다.

2.5 배포 시스템

다수의 시스템에 Agent를 배포해야 하기 때문에 배포시스템이 필요합니다. ssh로 접근해서 노가다를 할 수는 없으니까요. 자동화된 배포 시스템이 필요합니다. 예전에는 ssh를 기반으로 배포시스템을 만들었습니다. Agent는 자체적으로 Agent Manager 프로그램을 포함하고 있는데요. 이 프로그램이 Agent의 버전과 Agent 목록정보를 가지고 있습니다.

관리는 웹으로 하는데, Agent가 설치된 장비로 부터 버전 정보를 가져올 수 있습니다. 버전 정보를 확인해서, Agent 패키지를 업데이트 하거나 설치하는 등의 작업을 했던 거죠.

2.6 Dash Board

구상하는 시스템은 관제 시스템류인데요. 이런 시스템은 관리자에게 필요한 정보를 보여주기 위한 Dash Board가 필요합니다. 소개했던 Zenoss는 이런 기능이 부족하지요. 그래서 wiki 기반으로 만들어서 사용했습니다. Dash Board에서 중요하게 보여줘야 하는 것은 "이벤트"와 관심 자원에 대한 모니터링 정보겠죠. Zenoss의 모니터링 데이터는 RRD로 저장이 되고, 이벤트는 wiki의 이슈 시스템에 보냈으니 dash board를 만드는 것은 그다지 어렵지 않았습니다. wiki 시스템은 대부분 플러그인으로 기능을 확장하도록 하고 있으니까요.

3 시스템 설계

시스템에 구현을 해보려고 합니다. Zenoss는 일단 사용하지 않을 생각입니다. 이게 위치가 참 애매모호 하거든요. 제대로 사용할려면 이슈시스템등 다른 시스템과 연동을 해야하는게 좀 문제입니다. 그리고 어느정도의 성능을 보여줄지도 장담할 수가 없기 때문입니다. 이전에 600대 정도의 서버를 Zenoss로 관리하는 걸 보긴 했는데, 정보 수집시간을 300초로 한 경우였구요. 300초는 요즘에 너무 길잖아요 ? 이걸 더 줄이면 성능을 장담할 수 없죠. 5초 주기로 수집하게 했는데 무리였습니다. 그래서 분산 모니터링 시스템이 필요한 거겠죠. Zensoo 분산 모니터링 버전도 있던데, 상용인거 같아서 제외 했습니다.

그냥 HTTP 혹은 FUSE 기반으로 설계 해보려고 합니다.

3.1 정보 수집

수백대 정도라면 정보 수집을 위해서 고민할 필요가 없습니다. 수천대를 고려해서 정보를 수집할 수 있는 환경을 구축하는게 목표입니다.

3.2 HTTP를 이용한 정보 수집

HTTP를 이용하는 이유는 이미 잘 만들어진 응용 애플리케이션을 사용할 수 있기 때문이죠 Apache와 PHP가 그것이다. PHP는 SNMP를 지원하니, 관련 응용도 쉽게 개발할 수 있구요.

주기적으로 수집하는 정보와 이벤트성 정보가 있는데, 주기적으로 수집하는 건 일정 시간 주기로 정보를 모으면 될 것 같네요. 이벤트성 정보는 snmp trap을 이용하는 방법, HTTP를 이용해서 전송하는 방법이 있고요. syslog를 전송하는 방법도 있겠죠. 여기에서는 HTTP를 이용하기로 했습니다. syslog는 유닉스 시스템에서 널리 사용하는 방법이긴 하지만 syslog 설정을 해줘야 하니 귀찮구요. 차라리 로컬에 syslog 분석을 위한 Agent를 설치하는게 낫다는 생각입니다.


  1. 주기적으로 수집
    웹 서버에서 주기적으로 수집합니다. 물론 타겟 서버에도 웹 서버와 시스템/네트워크 데이터를 읽기 위한 애플리케이션이 설치되 있어야 한다. 웹 서버는 요청<->응답 방식으로 작동합니다. 그러므로 데이터를 수집하려면, 수집 서버의 웹 서버에 요청을 해야 합니다. 별도의 요청 프로그램이 필요하죠. 이 요청 프로그램은 wget이나 curl등으로 개발하면 됩니다. 설정된 시간을 주기로 수집서버에 wget으로 요청을 하는 거죠.
  2. 이벤트 수집
    이벤트는 수집 서버와 Target 서버 모두에서 발생할 수 있습니다. 수집 서버에서 발생하는 이벤트는 룰 기반의 이벤트가 되겠죠. 예를들어 CPU 정보를 5초 주기로 수집하고 있는데, 연속해서 5번 90%를 초과하면 이벤트를 발생시켜라이런 류의 이벤트 입니다. Target 서버에서 발생하는 것은 디스크 마운트 에러, 열린 포트 에러, 각종 장치 에러, 커널 이벤트, sys log 이벤트와 같은 것들입니다.
    Target 서버에서 이벤트는 Target 서버에 설치된 Agent가 만듭니다. Agent를 데몬 프로세스로 만들어서, 이벤트가 발생하면 웹 서버로 데이터를 전송하는 식입니다.

3.2.1 수집 서버 구성


수집서버의 중심에는 웹 서버가 있습니다. 이 웹서버는 설정, 이벤트, 기타 통계 데이터를 관리합니다. 요청은 wget을 응용한 스크립트가 수행하는데, wget 스크립트도 웹 서버가 관리 합니다.

흐름은 다음과 같습니다.
  1. wget 스크립트로 웹 서버에 요청을 한다.
    • 요청 정보는 Config에서 읽어온다.
    • Config는 웹 서버가 관리한다.
  2. 웹 서버는 요청을 분석해서, 데이터를 요청한다.
    • 주기적으로 수집한 데이터는 RRD에 저장한다.
    • 시스템 구성정보는 구성정보 테이블에 저장한다.
    • 이벤트는 Event 테이블에 저장한다.
    • Config는 별도의 관리 페이지를 이용해서 관리한다.

3.2.2 Target 서버 구성


Target 서버 역시 웹 서버를 중심으로 작동을 합니다. 웹 서버는 요청이 있으면, 요청을 처리할 Agent 프로그램을 호출하고 결과 값을 응답 데이터로 전송합니다. 응답 데이터 포맷은 Nagios 형식으로 통일 하면 되겠네요.

일반적인 방식으로 한다면, 요청마다 프로세스를 호출하는 방식이 될건데요. 기능별 Agent를 만들어서, 매번 호출 하는 방식을 쓰면 간단하긴 하지만 프로세스 생성 비용을 생각하면 이 방식을 사용하기는 좀 그렇죠. 5초 간격으로 5개의 정보를 얻는다면, 5초 마다 5개의 프로세스를 실행해야 한다는 얘기가 되니까. 무시해도 될만한 비용이라고 생각할 수도 있겠지만 꺼림직 합니다.

해서 Agent의 효율적인 작동방식도 좀 고민해볼 필요가 있겠네요. Python이나 Perl로 Agent 데몬을 만들고, 각 기능을 모듈로 끼워 넣는 방식도 생각할 수 있겠구요. 웹서버와 Agent의 통신은 Unix Domain Socket으로 하면 되지 싶습니다.

하지만 이 방식도 문제가 있습니다. 특정언어에 종속되게 하면, 다른 언어로된 도구를 사용하기가 껄끄러워지기 때문입니다.

그래서 생각한 절충안. 기본적으로는 코드 조각을 수행하도록 하지만, 외부 프로그램을 수행할 수 있도록 하는 겁니다.

3.3 배포 시스템

Agent 배포와 업그레이드를 수동으로 할 수는 없는 노릇이죠. 따라서 배포 시스템을 만들어야 할건데요. 배포 시스템은 대략 다음과 같은 기능을 가지고 있어야 할겁니다.
  1. 운영체제 배포 환경
    상당한 규모의 시스템을 관리할 거라면, 배포환경을 따로 구축할 겁니다. 여기에 Agent를 패키지화 해서 운영체제 설치시 자동으로 설치하도록 해야 겠죠.
  2. 업데이트 관리
    새로운 Agent가 설치되거나 Agent가 업데이트 할 수 있어야 합니다. Agent 별로 업데이트 할 수도 있겠지만 너무 복잡하겠구요. 그냥 Agent 빌드 -> 패키징 시스템을 만들어서 패키지 단위로 업데이트하는게 낫겠지 싶다. Agent 하나 추가로 모든 시스템의 패키지를 업데이트 해야 하는게 부담일 수 있는데요. 음. 단일 Agent install 기능 정도는 추가하는 것도 괜찮을 것 같습니다.
  3. 상태 관리
    Agent의 상태를 확인할 수 있어야 겠죠. 수집서버에서 상태 정보를 요청하면 되겠네요.
  4. 설정 관리
    가능한 Agent 시스템은 설정을 가지지 않도록 할 생각입니다. 최대한 단순하게 구성하는 거죠. 유일한 설정은 이벤트 관련 Agent를 활성화 할 것인지 말것인지와 수집 서버의 IP와 포트번호 정도 만 가지도록 구성하면 되겠지. 아예 설정을 가지지 않도록 할 수도 있을 거다. 수집서버가 수집서버의 정보를 알려주면 되니까. 후자가 더 낫겠군.

3.3.1 배포 운영체제 환경

배포 운영체제를 하나 만들어야 겠죠. 패키지 repository도 만들어야 겠고요. Agent 작동을 위한 환경도 만들어줘야 겠고요.
  1. Agent 작동 유저와 그룹 생성
  2. Agent 작동 홈 디렉토리 구성
  3. Agent 애플리케이션이 설치될 디렉토리 구성 
--- home ---+---- WebServer  
            | 
            +---- Cfg 
            | 
            +---- Agent ---+-- Module  
                           | 
                           +-- Exec
대략 위의 방식으로 디렉토리를 구성해 주면 될겁니다.

3.4 이벤트 관리

앞서 설명했듯이 이벤트는 두 가지 종류가 있습니다. 룰 기반 이벤트와 Trap 방식의 이벤트입니다.

3.4.1 티켓 발행과 처리

어떤 종류의 이벤트이든지 간에 이벤트가 발생하면, 이 이벤트는 티켓으로 발행 됩니다.

티켓 관리 시스템에 대한 것은 다른 문서에서 설명을 했으니 참고 하시기 바랍니다. 정리하자면
  1. 티켓이 담당자에게 발행된다.
  2. 티켓을 받은 담당자는 티켓을 할당 한다.
  3. 티켓 이벤트를 처리한다.
trac같은 시스템을 하나 만든다.. 그렇게 보시면 되겠습니다.

4 장비 이력 관리

장비는 그룹별로 관리가 되야 겠죠. 그래야 그룹별로 관리/모니터링 정책을 정하고, 티켓 역시 그룹별로 발행할 수 있을 테니까요. 장비 이력 관련 해서는 장비 입고에서 폐기까지를 처리하는 전문적인 툴이 있기는 합니다. 물론 상용제품이죠. 저는 상용 제품을 이용할 생각은 없구요. 아래의 기능을 포함하도록 개발할 생각입니다.
  1. 장비 이력 관리
    장비 입고 에서 폐기까지의 히스토리
  2. 장비 그룹
    그룹으로 관리할 수 있어야 겠죠.
  3. 장비 구성정보
장비 이력관리에서 생각해야 할게 하나 있는데요. 장비를 구성하는 기기들에 대한 것들입니다. 다수의 시스템을 운영하다 보면 장비의 구성 기기들 그러니까 하드디스크, CPU, 이더넷 카드가 바뀔 수 있을 겁니다. 이 정보를 유지해야 하느냐 하는 거죠.

중요할 수 있는게 각 기기의 내구성, 성능등을 측정할 자료로 사용할 수 있기 때문입니다.

5 개발 이슈

시스템 자체는 간단합니다. 시스템은 간단하고 이해하기 쉽게 설계하는게 최고죠. 하지만 실제 구현은 그렇지 않습니다. 정보 수집, 분석, 이벤트 관리, 장비/유저 관리를 모두 통합해야 하기 때문이죠. 프로세스 관리입니다.

또 하나 이 시스템은 수십에서 수백대가 아닌 수천대에서 수만대의 시스템 관리를 목적으로 합니다. 수집하는 것 자체가 도전이 될 수도 있습니다.

5.1 분산 수집

음.. 어떤 구조를 가지는게 좋을까. 수집서버가 요청해서 수집하는 방식을 사용해야 하나 ? 아니면 타겟 서버가 데이터를 전송하는 방식을 사용해야 할려나 ? 성능을 중심으로 살펴보도록 하겠습니다.

시스템 구성은 다음과 같습니다.


일단은 수집 서버에서 주기적으로 수집하는 방식으로 구현하기로 했습니다.

수집 서버는 여러 대가 될 수 있습니다. Manager는 이들 수집 서버를 관리하고 Job을 할당하는 일을 합니다. 여기에서 Job이란 관리할 서버 목록과 관리 요소가 되겠죠. 새로운 Job이 만들어지면, 수집 서버로 정보를 전송합니다. 수집 서버는 Job을 받으면, 수집 스크립트를 재 가동합니다. 다음과 같은 기능이 있겠죠 ?
  1. 새로운 Job 할당.
  2. 기존 Job에 새로운 장비 추가

wget 스크립트를 이용해서 주기적으로 데이터를 가져옵니다. 만약 10초 주기로 1000대의 서버로 부터 데이터를 수집한다고 하면, 초당 100의 응답 데이터를 처리하게 될겁니다. 실제로는 하나 이상의 정보를 수집하게 될테니, 그 이상의 요청을 처리해야 겠죠. 가능한 한번의 요청에 많은 데이터를 처리하기 위해서 데이터 범주를 나누어야 할 겁니다. 2-3개 정도로 나눌 수 있겠죠.

정보 범주가 3개라면 초당 300개의 데이터를 처리해야 하는 군요. 테스트를 해봐야 겠지만 성능에 문제가 될 것 같지는 않군요.

수집 프로세스는 어떻게 구성할까요 ? 데몬 형식으로 ? 아니면 매 주기 마다 실행 ? 전 데몬 형식으로 할 생각입니다. 매 주기 마다 실행할 경우 다음의 문제가 있기 때문입니다.
  1. 프로세스 생성 비용 : 초당 300개라면, 무시할 수 없겠죠.
  2. 데이터 유지 : 이벤트는 대게 escalator level을 가집니다. 연속 해서 발생 했을 때, 이벤트 Level을 올리는 방식입니다. 예컨데, CPU가 한번 90% 초과 했다고 해서 이걸 주요 이벤트로 볼 수 없을 겁니다. 연속 3번 90%를 초과하면, 아 좀 문제가 있구나. 연속 5번 초과하면 아 이거 중요한 문제구나 이렇게 판단을 하는 거죠. 해서 이전 상태값을 유지할 필요가 있는데, 그럴려면 프로세스가 유지되는게 좋습니다. RRD로 이전 데이터를 남기고 있으니, 읽어오면 되지 않겠냐 싶기는 한데. 그만큼 비용이 소모됩니다.
위 두 문제가 그리 큰 문제가 아니라고 판단했다면, 매 주기 마다 프로세스를 실행해도 됩니다.

전 데몬 방식을 선택했습니다. 하나의 데몬이 하나의 서버를 관리하는 방식입니다. 1000개의 장비라면 1000개의 프로세스가 뜹니다. 2000개라면 2000개입니다.

구성은 아래와 같습니다.

  1. Web Server는 설정을 쓰고 Daemon Manager를 호출합니다.
  2. Daemon Manager는 Config를 읽어서 수집 데몬을 실행합니다.
  3. 수집 데몬은 주기적으로 정보를 요청해서
  4. 정보를 RRD에 넣고
  5. 설정 Rule에 기반해서 이벤트를 만듭니다.
  6. 이벤트는 Web Server로 전송하고, 웹 서버는 이벤트를 Ticket으로 만들어서 할당합니다.
간단하죠 ? 시스템 관리자 입장에서 기분이 우울할 수는 있겠네요. 1000개의 프로세스가 떠 있는 걸 본다면 그닥 기분이 개운치가 않겠죠.

5.2 분산 처리

데이터 처리는 어떻게 해야 할까요 ? 제가 생각하기에는 굳이 분산처리를 할 필요는 없을 것 같습니다. RAW Data는 별 다른 처리 없이 그대로 RRD에 저장할 생각이 거든요. 기본적으로 서버&모니터링 요소 마다 RRD 파일을 남길 겁니다.

그러므로 "서버 갯수 x 모니터링 요소"만큼의 RRD 파일이 만들어지겠죠.

남는 문제는 RAW DATA를 남길 것인지에 관한 겁니다. 필요할 때, RAW DATA에서 정보를 뽑아내기 위해서입니다. Big Table과 같은 column by column 기술을 적용한 데이터베이스 시스템을 하나 선택해야 겠는데. HBase 정도로 한번 살펴볼까 합니다. 연구주제쯤 되겠네요.

5.3 대략 관제 시스템

대략이긴 하지만 정보를 수집과 분석에 대한 설계가 끝났습니다. 이제 관제 시스템을 만들어야 할 건데요. 이 관제 시스템은 다음과 같은 기능을 가지고 있어야 합니다.
  1. Ticket 시스템과 연동
  2. 주요 이벤트 모니터링
  3. 시스템/네트워크 상태 확인
  4. 서비스 상태 확인
  5. Network Map
  6. 설정
  7. 레포팅

5.4 대략 Ticket 처리 시스템

Ticket 관리 시스템에 정리해 둔게 있음.

6 전체 구성

전체 구성은 대략 다음과 같습니다.


  1. Web Server : 웹 서버는 이 시스템의 중심입니다. 수집서버가 수집한 모니터링 정보를 그래프로 출력하고, 이벤트 목록을 보여주는 일을 합니다. 이벤트 (이슈) 관리 기능도 물론 가지고 있죠.
  2. Manager : 수집서버를 관리합니다. Web Server로 부터 구성정보를 가져와서
Email을 기입하면, 댓글이 메일로 전달됩니다.