지난달에는 한동안 VPlex 프로젝트에 사용할 Monitoring Agent를 선정하기 위한 자료조사와 테스트를 했었다.
그러다 보니 Monitoring Agent를 구현하는데 참 여러가지 방식이 있구나 하는 생각이 들었다.
VPlex 프로젝트를 진행하는 내내 Monitoring Agent 를 어떻게 구현할지가 주요한 이슈 중 하나였다.(물론 아직도 이슈로 남아있다.ㅠㅠ)
그동안 여러번 정책이 세번이나 바뀌면서 각각 다른 방식으로 Agent의 구현을 시도해 보았었다. (곧 네번째가 등장할지도.. -_-;)
처음에는 Python Agent를 직접 구현하기로 했었다.
Monitoring Server에 Daemon 을 하나 돌려서 이 녀석이 DB에서 모니터링 할 대상에 대한 정보를 가져와서 능동적으로 해당 머신의 정보를 뒤져서 DB에 저장하는 방식이다.
성능을 위해서 Thread Pool과 non-blocking socket을 도입했고 DB는 Driver 방식으로 어떤 DBMS든 연동가능한 구조를 채택했으며, 설계에는 rule-based alert 도 고려했다.
한 2~3주 쯤 논의를 거쳐 꽤 깔끔한 Prototype 까지 나온 것 같았다.
이 방식의 가장 큰 장점은 Monitoring 대상에 어떠한 client agent도 심을 필요가 없다는 것이다.
굳이 양자역학을 들먹이지 않더라도 Monitoring 을 위해서 client에 추가적인 agent를 설치하는 것은 monitoring 이라는 행위 자체가 monitoring 결과에 영향을 주게 되고, client agent 가 매우 깔끔하고 가벼운 구조로 설계되어 있지 않으면 오히려 monitoring 자체에 더 많은 resource 를 사용하게 되는 어쳐구니 없는 상황이 되는 문제 때문에 이 구조가 최선의 방식이라고 생각했었다.
(그러나 나중에 실제로 많이 사용되는 Monitoring Agent들은 이 방식을 사용하는 경우가 별로 없다는 사실을 알게됐다.)
그러다가 시카고에 GMS(Global Monitoring Service)라는 녀석이 있으니 Hostway의 모든 Monitoring 기능은 이 녀석을 써서 해야된다.. 라는 말 한마디에 기존 작업을 모두 중단하고 GMS 분석에 들어갔다.
(한달이 넘게 시카고 개발자들과 메일을 주고 받으면서 힘들게 진행됐다..)
GMS 는 전형적인 Unix C 코드로 작성된 Socket Application 이였다.
Server-Client 구조고 Monitoring 대상에 Client Agent를 설치해 놓으면 이 client 가 주기적으로 로컬 리소스를 검사하여 GMS-Protocol 에 정의된 규칙대로 GMS-Server에 퍼다 넣는 방식이다.
GMS-Server 는 다시 세가지 모듈로 나뉘는데 Client 가 퍼 나르는 데이터를 받아서 메모리에 쌓아 두는 녀석과 메모리의 데이터를 읽어서 DB에 넣는 모듈, 그리고 그래프를 생성해주는 rrd 모듈이다.
이 GMS 는 처음 직접 만들려고 시도했던 Agent 와는 완전히 정반대의 개념에서 출발한다.
Server는 하는 일이 없이 수동적으로 client 가 넘겨주는 데이타를 받아서 쌓는 역활을 하고 모든 능동적인 작업은 client agent 가 수행한다.
확실히 server 가 하는 일이 별로 없으니 동시에 모니터링 가능한 머신 수가 대폭 늘어난다.
첫번째 Agent 가 설계를 잘해봤자 수백대 정도의 머신을 담당하는데 적합하다고 하면 GMS는 시카고 측 얘기로는 동시에 10만대 이상의 머신을 모니터링할 수 있게 설계가 되었다고 한다.
그러나 원시적인 소스코드의 문제는 차치하고서도 GMS에는 여러가지 구조적인 문제가 있었다.
우선 client agent가 모든 작업을 처리하기 때문에 기능을 추가하거나 통신 방식을 변경하려면 agent 소스를 수정하여 재배포해야 된다는 점이다. 그리고 현재는 agent의 기능이 별로 없지만 기능을 추가해 나갈수록 client 의 부담이 커진다.
그밖에 System DB의 sysid 를 client-server 통신의 키로 사용한다던지 하는 내 생각에는 불합리하게 여겨지는 여러가지 문제가 있었다.
Global 정책이라고 하니 어쩔 수 없이 사용하긴 했지만 정말 맘에 들지는 않았다.
그런데 기존의 client agent 소스를 수정해서 VPlex 용 Linux client agent를 만들고 기존에는 아예 존재하지 않던 Windows 용 agent까지 만들어서 서버와 잘 통신하는 것까지 확인하고 나서 날아온 소식...
GMS 개발자들이 모두 퇴사했다는 것이다. -_-; (황당 * 100)
그후 세번째는 윈도우와 리눅스를 모두 지원하는 Open Source Monitoring Agent 를 조사하여 그중 적당한 녀석을 쓰는 것이였다.
대여섯개 정도의 후보들을 테스트해본 결과 zabbix(
http://www.zabbix.com) 라는 녀석을 쓰기로 했다.
zabbix 는 기능도 많고 꽤 널리 쓰이고 있는 검증된 제품이다.
이 것은 뭐랄까 첫번째와 두번째의 중간적인 형태를 띄고 있다.
client agent를 설치하는 것은 GMS 와 동일하지만 client agent를 호출하여 정보를 가져가는 것은 zabbix 서버가 담당한다.
첫 번째 방식이 agent를 심지 않는 대신 해당 머신이 기본으로 제공하는 정보들을 뒤져서 원하는 정보를 찾아내는 방식이기 때문에 모니터링 할 수 있는 범위의 제약이 크다.
그러나 zabbix 는 서버가 monitoring query 를 만들어서 client에게 넘기면 client 가 이를 실행해서 그 결과값을 서버에 넘겨주는 방식이기 때문에 자유도가 높고 기능을 추가할 때마다 agent를 재배포할 필요도 없다.
성능도 나쁘지 않은 편이고.. 드디어 답이 나왔구나 싶었다.
그러나 zabbix 같은 방식에도 문제가 있다.
바로 보안이다.
어떻게 보면 zabbix client 라는게 트로이의 목마 같은 security hall 을 일부러 심어놓는 것이다. 물론 client 설치시 설정하는 서버 IP 로 부터의 접속만 허용하기는 하지만 IP Spooping 도있고 근본적으로 좀 위험한 방식이다.
그래도 약간만 신경을 쓰면 그렇게 높은 보안성이 요구되지 않는 일반적인 환경에서는 매우 유용하게 사용할 수 있을 듯하다.
Agent 소스를 약간 수정해서 보안성을 강화하고 추가로 필요한 Management 기능을 추가해서 VPlex 에 사용하면 될 듯..
이것으로 끝?????
그러나 하늘은 또 새로운 시련을 주신다. ㅠㅠ
GMS Project를 우리 VPlex 팀에서 떠 맡으란다.
그렇게 되면 자연스럽게 다시 GMS 를 VPlex 에 사용하는 걸로 바뀌게 될 듯.
다음주에 한국에 오는 Jason 과 얘기를 해봐야겠지만 혹시 내가 GMS 를 떠맡게 되고 모든 책임이 넘어오면 기필고 모든 코드를 첨부터 뜯어 고치고야 말겠다.
(아님 이력서를 가슴에 품고 출근해야 하나...ㅋㅋ)
