Facebook Joinc 그룹
Joinc QA 사이트
Tweet
joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.
Tweet
joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.
1 IT 모니터링
요즘엔 시스템, 네트워크 모니터링 이란 용어대신 IT 모니터링이란 말이 오르내린다. 예전과는 달리 모니터링 환경이 복잡해지고 서비스 모니터링 까지 외연이 확대됨으로써, 그 의미를 확대시킬 필요가 있기 때문으로 생각된다.
개인적으로 다른일 보다 이러한 모니터링 관련된 일을 해본경험이 좀더 많다. (ESM)통합 보안관제시스템도 만들어본적이 있고, IDC의 시스템/네트워크 관리 시스템도 만들어본 경험이 있다. 지금도 비슷한 일을 하고 있고..
이런일을 하면서 겪게되는 어려움이라는 것은 이러한 시스템을 위한 프로세스나 경험등이 정리된게 존재하지 않는다는 거다. Internet가 본격적으로 도입된게 1992년이고, 기업환경에서 컴퓨터가 주요하게 사용되었던것 까지 하면 20년 가까운 세월이 흘렀다고 생각되는데 여전히 주먹구구식으로 관리가 된다. 마땅한 툴도 없다.
사실 마땅한 문서나 툴이 없는건 아니긴 하다. 매우 훌륭한 문서와 IT 모니터링을 위한 철학들이 잘 구현되어 있는 툴들이 있긴 하다. 그러나 이런류의 일은 기업의 인프라를 관리하는 것으로, 오랜시간 고민을 하면서 구축해 나가야 하는데, 많은 회사들이 당장 돈이 안되며일에 자원을 투자하는 것을 안타까워 하는것 같다. 당장 돈이 안되며, 그 결과가 눈에 보이는 것도 아니니 빨리 빨리가 체질화된 우리나라 IT기업들에 있어서 필요성이 그다지 느껴지지 않아 보이는거 같기도 하고.
그러다보니, IT 모니터링 시스템 구축하는 것은 사이드 잡형태로 주어지는 경우가 많고 MRTG와 RRD, SNMP등을 가지고 간단하고 빠르게 만들어서 사용하는게 대부분이다.
2 최근의 분위기
다행히 분위기가 조금씩 바뀌고 있다. 아직은 초기단계이지만 플렛폼위에서 서비스를 계획하는 회사가 많아진게 이유인거 같다. 다수의 컴퓨터와 소프트웨어로 플렛폼이 구성되고, 그 위에서 서비스가 유기적으로 돌아가는 환경이기에, 그 필요성을 느끼고 있는것으로 보인다. 특히 모니터링/이력관리 툴은 TTR과 TTD를 단축시켜주는 핵심요소가 된다. TTR, TTD에 관련된 내용은 인터넷 서비스 QOS 를 위한 고찰문서를 참고하기 바란다.
3 Zenoss
최근에 관심을 가지고 있는 툴이 zenoss이다. zabbix와 함께 조사해보던 툴인데, 결국 zenoss를 선택했다. 기능도 기능이지만 모니터링 프로세스, 이벤트 사이클, 이벤트 관리등 IT 모니터링을 위한 필요충분 요소들이 충실하게 녹아있다는게 선택의 이유가 되었다.
zenoss에 대한 소개는 Zenoss 위키페이지를 참고하기 바란다.
4 이벤트 이력관리 시스템
하지만 zenoss는 이력관리 시스템이 빠져있다. 있기는 있는데, 발생된 이벤트에 대해서 간단히 로그만 남길 수 있는 것으로, 활용하기에는 절대적으로 기능이 부족하다.
이벤트 이력을 관리하려면 적어도 다음의 기능은 만족시킬 수 있어야 할 것이다.
- 이벤트 이력을 남기는 건 기본
- 이벤트 분류,검색,레포트
5 Ticket 발행 시스템
어떤 이벤트를 추적하고, 이력을 나기기 위한 시스템은 여러개가 나와있다. 그중 가장 널리 사용되고 있는게 아마 trac일 거다. trac은 tciket을 발행하고 처리하는 이력을 남김으로써, 버그를 추적한다. ticket 방식은 예를들자면, 문제가 생기면, 티켓을 끊은 다음 담당자에게 티켓을 주고 나중에 티켓을 확인해서 일을 제대로 처리했는지를 검사하는 방식이다.
남겨진 이벤트 이력은 쉽게 분류/검색 되며, 레포팅 될 수 있어야 한다. 시스템 관리를 예로 들어보자. 이벤트를 발생시킨 문제는 중복되거나 약간 형태를 달리해서 발생하는 경우가 대부분이다. 때문에 이벤트 이력은 지식베이스화 될 필요가 있다. 이렇게 될경우 많은 수의 중복된 문제에 대해서 쉽게 원인을 찾아서 대처할 수 있으며, IT 자원의 사용 품질을 높일 수 있을 것이다.
- 이벤트가 발생
- 레포터가 이벤트를 받는다.
- 이벤트의 내역을 적은 티켓을 생성한다.
- 티켓을 담당자에게 끊어준다.
- 티켓을 받은 담당자는 내용을 읽고 이벤트를 해결한다.
- 담당자는 이벤트 해결과정을 이력으로 남긴다.
- 처리가 끝났다면, 레포터에게 티켓과 이력서를 넘겨준다.
- 레포터는 처리내용을 확인하고, 이벤트처리건을 종료할지를 결정한다.
6 이벤트 이력관리와 wiki
단언컨데, wiki는 지식베이스 구축을 위한 최적의 환경을 지원하고 있다. wiki는 효율적인 공동작업이 가능하게 도와주며, 이 모든 과정을 쉽게 문서로 남길 수 있다. 또한 다른 위키의 다른 문서들과 쉽게 링크될 수 있다. 검색환경도 비교적 쉽게 구현할 수 있으며, 쉽게 확장할 수 있다는 장점도 가진다.
trac이 ticket와 wiki기반으로 작성된건 우연이 아니다.
7 zenoss + Ticket + wiki
그래서 Ticket + wiki를 이용해서 이력관리 시스템을 구축하기로 했다. 대략적인 프로세스는 다음과 같다.
- zenoss 에서 이벤트가 발생한다.
- zenoss는 이벤트에 대한 처리 프로그램을 정의할 수 있는데, Ticket을 생성하는 wikipage를 호출하는 프로그램을 작성한다. 이 프로그램(이하 sendticket)은 HTTP/GET 방식으로 wikipage를 호출한다.
- 호출 받은 wikipage는 GET으로 넘어온 값을 이요해서 ticket를 생성한다.
- 이하 ticket은 일반적인 ticket 처리 프로세스를 따라서 처리하도록 한다.
ticket 처리 프로세스는 trac의 ticket 프로세스를 분석하면 어렵지 않게 구현할 수 있을 것이다.
DB에는 Event의 Meta 정보가 들어가고, File에 이벤트 처리에 대한 상세 내용이 들어간다.
TicketMake
===========
exec HTTP/GET
zenoss Event --> Event Command -------> sendticket ----------> wikipage --> DB
TicketView
==========
DB | wikipage <-----> FireFox
File |
|
|
8 wiki의 선택
wiki는 moniwiki를 선택하기로 했다. 이유는 다음과 같다.
- 순수 php로 구현되어 있다.
- 개인적으로 php에 익숙
- 개인적으로 php에 익숙
- plugin 제작을 통한 확장이 매우 쉽다.
- ticket 처리를 위한 plugin을 작성하면 된다.
- moniwiki의 매크로 시스템에 익숙하다. 역시 개인적인 이유다.
- ticket 처리를 위한 plugin을 작성하면 된다.
9 지식기반 시스템을 위한 추가 요구사항들
위키와 Ticket을 이용하면, 위키 특유의 용이한 공동작업기능과 디렉토리 구성을 통해서 체계적으로 이벤트이력을 관리할 수 있을 것이다. 이제 생각해야 하는건 검색이다.
9.1 Tag의 활용
위의 스크린샷을 보면 TAG 부분이 있다. TAG를 이용하면, 현재 이슈가 되는 문제를 짐작할 수 있고, 관련된 정보를 신속하게 찾아낼 수 있을 것이다. 여러개의 서비스를 위해서 시스템이 분산되어 있을 경우 특히 도움이 될 것이다.
9.2 전용검색엔진 : TAG
검색엔진을 어떻게 구현할 것인가는 선택해야될 문제가 있다. 쉽게 구현하고자 한다면, TAG 클라우드에서의 검색이 있을 수 있을 것이다. 일반적으로 TAG는 카테고리에 비교해서 가볍게 사용할 수 있다는 장점을 가지지만, 체계적으로 정리하기가 매우 힘들다는 단점을 가진다. 병합, 분리도 수월하지 않다. 또한 TAG가 제대로 힘을 발휘할려면, 클라이언트가 똑똑하게 TAG를 사용해야 한다는 점도 부담으로 작용한다.
그러나 특수한 목적을 가지는 정보들만 수집된 영역이라면, 몇가지 사항을 제한함으로써, 이 문제를 해결할 수 있다.