오픈소스 모니터링 툴 Zabbix(1) : 이론편

반응형

오픈소스 모니터링 툴 Zabbix(1) : 이론편

안녕하세요 김민욱입니다.

 

이번 포스팅에서는 아마 많은 분들께서 서버 관리, 인프라 관리, 클라우드 등에서 사용하고 계시면서도 잘 알려져 있는 오픈소스 모니터링 툴인 Zabbix 이론에 대해 말씀드리고자 합니다. 

 

저 또한 장애 관리나 고가용성에 대한 연구들을 진행하면서 Zabbix를 많이 사용했었습니다. 그 이유는 간편하게 구성할 수 있었고, 제 나름대로의 주관은 웹 UI 즉 인터페이스가 편리했습니다. 이 부분에 대해서는 여러 의견이 있을 것 같네요. 그래도 Template라는 개념을 기반으로 해서 모니터링 범위도 넓기 때문에 범용적으로 사용될 수 있다고 생각됩니다. 

 

그럼 지금부터 오픈소스 모니터링 툴 Zabbix 이론 편에서 Zabbix 기본, 모니터링 범위, 유즈 케이스 등에 대해 설명드리겠습니다. 

 

Zabbix Basic

Zabbix는 알렉세이 블라디셰브에 의해 개발되어 2004년 1.0이 버전이 발표되었습니다. [1] Zabbix는 특히 엔터프라이즈급 분산 모니터링 솔루션이며, 수많은 종류의 네트워크 장애 혹은 상태나 H/W 등을 모니터링하는 오픈소스 모니터링 솔루션입니다.

그림 1. Zabbix 로고

장애가 발생하면 관리자에게 이메일, 메시지와 같은 방식으로 알릴 수도 있습니다. 무엇보다 저는 웹 UI가 직관적이었습니다. 그러나 이 부분을 단점으로 뽑으시는 분들도 계시는 것 같아서 어디까지나 주관적인 의견임을 밝혀드립니다. 

 

그럼 Zabbix의 구조를 가지고 Zabbix에 대해 알아보도록 하겠습니다. 이번 포스팅은 Zabbix 정식 문서 및 평소 제가 Zabbix를 기반으로 연구했던 경험 등을 토대로 작성하였습니다. [2]

그림 2. Zabbix 구조 

그림 2에서는 Zabbix의 구조를 나타냅니다. 대부분의 모니터링 툴들의 구조와 다르지 않습니다. 크게 관리자가 모니터링 기능을 사용할 수 있는 웹 UI / 데이터베이스 / 데이터 수집기 / 모니터링 서버로 나뉩니다. Zabbix Agent는 모니터링 대상에게 설치되는데 OS와 연동하여 하드웨어의 리소스 상태를 수집해서 서버로 보내거나 특정 APP에 대해서도 모니터링하여 APP 상태를 판단합니다.

 

이때 포트 모니터링을 이용하여 애플리케이션의 상태를 판단할 수도 있습니다. Zabbix 서버는 수집된 데이터를 데이터베이스에 넣게 되는데 실제로 데이터베이스를 보게 되면 정수나 실수와 같은 숫자들이 빠르게 저장되고 있습니다. 물론 수집되는 주기에 따라 차이가 있겠지만요. 그리고 Zabbix는 PHP로 구현된 Apache 기반의 웹 브라우저도 지원하고 있습니다. 

 

그림 3. Push 방식과 Pull 방식

Zabbix의 특징에 대해 알아보기 앞서 그림 3과 같이 모니터링 프로젝트는 수집 방식에 따라 크게 두 가지로 나뉩니다. 바로 Push와 Pull 방식이죠. 일반적으로 대부분의 모니터링 프로젝트는 Push 혹은 Pull 방식으로 동작하고, 컨테이너 모니터링 프로젝트 Prometheus가 Pull 방식의 모니터링을 사용하고 있습니다. Prometheus는 다른 포스팅에서 다뤄보도록 하겠습니다. 간략하게 Push 방식은 에이전트가 모니터링 서버에게 데이터를 보내는 것이고 Pull 방식은 모니터링 서버가 데이터를 에이전트에게 접근하여 가져오는 것입니다. 그럼 Zabbix는 어느 방식일까요? Zabbix는 모두 지원하고 있습니다. 다만 기본적인 Passive 방식의 모니터링 기능(모니터링 서버가 에이전트에게 데이터를 요청하면 응답하는 방식)이라고 말합니다. Active 방식은 데이터를 Agent에서 Server로 보내는 방식(주기적으로 모니터링 에이전트가 모니터링 서버로 데이터를 보냄)입니다. 그러나 Zabbix의 Passive 방식이 서버가 에이전트에게 데이터를 요청하여 가져오기 위한 구성 방법에서 완전히 Pull 방식과 동일하다고 보기는 어렵습니다. Prometheus는 서버에서 에이전트로 데이터를 요청하기 위해 일방적으로 서버에 에이전트의 주소를 구성하면 되지만, Zabbix의 경우 서버에서 에이전트로 데이터 요청을 위해 양쪽 다 정보를 알려주어야 합니다. 따라서 이러한 관점으로 보았을 때, Zabbix가 완전한 Push 혹은 Pull 방식이다라고 확정하긴 어렵고, Zabbix만의 Passive, Active 방식이다 라고 생각하는 것이 좋은 것 같습니다. (다만, Push 및 Pull 방식과 이러한 관점에서는 비슷하다. 라고 표현 할 수 있을 것 같습니다.)

 

지금부터는 Zabbix가 가지고 있는 여러 특징들에 대해서 알아보겠습니다. 공통적으로 다른 모니터링 프로젝트에서도 가지고 있는 특징이긴 하지만 Zabbix에서는 어떻게 구현되어 있는지 그림과 함께 보도록 하겠습니다. 

 

그림 4. Zabbix Graph 

그림 4에서는 Zabbix 그래프를 나타냅니다. Zabbix의 대표적인 특징으로 수진 됩 데이터를 그래프로 나타낼 수 있고, 평균, 최대, 최소 같은 그래프 구성도 지원하고 있습니다. 전문적인 시각화 툴에 비해서는 기능이 단순하다고 생각되지만 그래도 꽤나 유용하게 쓰고 있습니다.

 

그림 5. Zabbix Network Map

그림 5에서는 Zabbix 네트워크 맵을 나타냅니다. 해당 기능은 네트워크 장비들의 분포와 구성 등을 한눈에 볼 수 있도록 지원하는 기능으로 사실 저는 해당 기능을 깊게 사용해본 적은 없습니다. 아무래도 클라우드를 사용하게 되면 서버는 범용적인 서버고, 구성은 클라우드를 통해 확인할 수 있기 때문입니다. 

 

그림 5. Zabbix 템플릿

마지막으로 Zabbix의 템플릿에 대해 알아보겠습니다.  Zabbix 템플릿은 일종의 모니터링 구성에 대한 집합입니다. 어떤 모니터링을 할 것인지, 해당 모니터링에 대한 조건은 무엇인지, 이벤트는 무엇인지, 알람은 무엇인지, 또 장애가 발생했을 때 어떤 액션을 수행할 것인지에 대해서 하나의 그룹으로 묶어두는 것입니다. Zabbix는 기본적으로 제공하는 템플릿이 있고 커뮤니티에 의해 제공되는 템플릿이 있습니다. 예를 들어 컨테이너 모니터링을 위해서는 컨테이너 모니터링 템플릿을 받아서 포함시킨 뒤 템플릿을 모니터링에 적용하는 것입니다. 

 

제가 Zabbix를 이용해서 주로 연구를 했던 가장 강력한 이유 중 하나는 API를 제공하는 것입니다. 물론 다른 모니터링 프로젝트도 API를 제공하는 경우도 있었지만 유료이거나 굉장히 지원하는 API가 적었습니다. 

 

그림6. Zabbix API 예

그림 6에서는 Zabbix API의 예를 나타냅니다. JSON 형식으로 포맷을 작성하여 Web 기반의 API를 통해 전달하면 Zabbix 서버는 해당 명령을 수행하는 것입니다. 추가적으로 Python 기반으로 API를 쉽게 사용 가능하게 해주는 Pyzabbix라는 라이브러리도 있습니다. [3] 다만 제가 원하는 만큼 Zabbix를 컨트롤하기 위해 지원하는 기능의 범위가 좁아서 사용하기는 힘들었습니다.

 

Zabbix Use-case

실제 프로젝트에서 Zabbix는 어떻게 사용되고 있을까요? 물론 많은 기업에서 Zabbix를 사용하고 있고 NFV 환경에서 또한 Zabbix를 사용하고 있습니다. 다만 Zabbix가 무엇을 모니터링하느냐에 따라 구조가 다르기도 합니다. 

 

그림7. Openbaton 구조

그림 7에서는 오픈소스 MANO 프로젝트인 오픈 바톤의 구조를 나타냅니다. 오픈바톤의 경우 NFVI에 Monitoring 레이어를 별도로 정의하고 Zabbix서버는 NFVI로 포함되게 됩니다. 그 뒤 MANO에는 Zabbix 플러그인을 구현하여 연동하여  서버의 리소스 사용량, 상태 등과 같이 NFVI를 모니터링하고 있습니다.

 

그림 8. Openstack Tacker & Zabbix 연동구조

오픈스택 MANO 프로젝트인 Tacker에서도 Zabbix를 연동하고 있습니다. 다만 해당 구조에서 Zabbix는 EM의 역할로써 정의되어 있습니다. 그 이유는 해당 구조에서 모니터링 대상은 NFVI와 같은 리소스가 아닌 가상 머신 내부의 OS와 애플리케이션을 모니터링하기 때문에 EM 역할로써 Zabbix가 정의되어 있습니다. 해당 기능은 실제로 오픈스택에 기여되어 있습니다.

 

그림 9. Openstack Vitrage

그림 9에서는 오픈스택 RCA(Root Cause Analysis) 프로젝트인 Vitrage의 구조를 나타내는데 여기서도 Zabbix가 사용되어집니다. 간단하게 Vitrage는 Zabbix와 연동하여 이벤트 장애 알람을 가져와 이들 간의 관계를 분석하여 장애 원인을 식별하고 있습니다. 

 

결론

본 포스팅에서는 Zabbix의 기본과 실 프로젝트 적용에 대해 설명드렸습니다. 연구 시 일반적으로 사용했던 Zabbix이지만 실제로 API가 굉장히 강력했기 때문에 연구 결과를 도출하기 위해 적합했던 것 같습니다. 다음 포스팅에서는 실제로 Zabbix를 설치하고 구성하여 가상 머신을 모니터링하는 것을 포스팅하겠습니다.

 

혹 부족한 내용, 틀린 내용이 있으시다면 언제든지 말씀해주시면 수정하겠습니다. 

감사합니다.  

인용글

[1]  Zabbix Wiki : https://ko.wikipedia.org/wiki/Zabbix

[2]  Zabbix Documentation: https://www.zabbix.com/documentation/3.2/manual

[3]  PyZabbix: https://github.com/lukecyca/pyzabbix

업데이트로그

------------------------------------------------------------------------------------------------------------------------------------

해당 글은 스스로 연구한 내용을 통한 주관적인 이해를 바탕으로 작성 되었습니다. 수정 할 부분이 있거나, 다른 의견이 있으시다면 언제든지 말씀해주시면 반영하도록 하겠습니다. 읽어 주셔서 감사합니다. 끝으로 불법으로 복제하는 것은 금합니다.

 

반응형

댓글

Designed by JB FACTORY