-
자빅스 모니터링 시스템 구축 가이드 - 1 (온프레미스 기반)
자빅스를 사용하여 모니터링 시스템을 구축하는데에 있어서 내용을 정리할 겸, 시간이 날 때마다 가이드식으로 여러편으로 나눠 포스팅을 하려 합니다. 지극히 개인적인 의견을 포스팅 하는 것 이며, 다른 의견의 피드백 환영 합니다.
1편에서는 "구축하기 전 어떤것들을 생각 해보아야 할까?"에 대해서 포스팅하려 합니다. 2편부터 구축하는 내용들이 담길 예정 입니다.
이번 포스팅에서 살펴볼 내용들은 아래와 같습니다.
- 모니터링이 필요한 노드들의 규모가 얼만큼 되는가?
- 자빅스 서버를 온프레미스 기반으로 하되, 컨테이너화(docker or kubernetes)가 필요한가?
- 자빅스에서 자주 이슈가 되는 housekeeper process를 어떤식으로 대비할 것 인가?
- Zabbix High Availability 구성에 대하여
-
1. 모니터링이 필요한 노드들의 규모가 얼만큼 되는가?
모니터링 시스템을 구축하기 위해서 가장 먼저 생각해 보아야 할 문제 입니다. 자빅스 서버 1대로 감당할 수 있는 것에는 한계가 존재하기 때문에 규모를 먼저 생각하고 Zabbix Proxy 구성을 염려해두어야 할 필요성이 있습니다.
- Q. '그럼 몇대부터 Proxy 구성을 생각 해봐야 할까요?'
사실 굉장히 난해한 질문 입니다. 모든 사람들의 자빅스 서버 스펙이 다를 것 이고, DB 튜닝 등 최적화 값, Zabbix 최적화를 위해 관리하는 능력(필요없는 아이템 제거 등)도 다를 것 입니다.
지극히 개인적인 의견으로는 수십대 정도는 자빅스 서버 하나로도 충분 하지만, 수백대 규모 이후로는 Zabbix Proxy 구성을 생각 해보아야 합니다. (현실적으로 구체적인 기준은 잡을 수 없습니다.)
* Zabbix Proxy 란?
- Zabbix Proxy서버에서 Agent들의 데이터를 수집 후 Zabbix Server에게 데이터를 전송 합니다. 자빅스 서버는 데이터 수집은 하지 않으므로 부하분산하여 자빅스 서버를 관리할 수 있습니다.
- 또는 아래와 같이 Zabbix Proxy 서버와 Zabbix Server, Zabbix WEB 서버를 모두 나눠 관리할 수도 있습니다. Zabbix Server는 수집된 데이터 관리, Zabbix WEB 서버는 Zabbix Server에 있는 데이터를 기반으로 자빅스 대쉬보드를 통해 출력 합니다.
-
2. 자빅스 서버를 온프레미스 기반으로 하되, 컨테이너화(docker or kubernetes)가 필요한가?
우선 저가 포스팅할 내용들은 지극히 개인적인 의견이니 참고 부탁 드립니다. 아래와 같은 상황들이 있다고 생각 하겠습니다.
- 자빅스 서버를 단일용도(모니터링)로 사용, Docker로 컨테이너화
- 자빅스 서버를 단일용도(모니터링)로 사용, Kubernetes로 컨테이너화
- 자빅스 서버를 다용도로 사용, Docker로 컨테이너화
- 자빅스 서버를 다용도로 사용, Kubernetes로 컨테이너화
1번의 경우 컨테이너화를 굳이 할 필요성은 없다고 봅니다. 단일용도로 사용된다면 추가적인 컨테이너도 생기지 않을 것 이고 추후 다시 빌드해야할 상황도 생기지 않을 가능성이 높습니다. 도커로 얻는 이점은 거의 없다고 보입니다.
2번의 경우 단일용도로 사용하지만 kubernetes가 가져다 주는 이점이 너무나 많기에 잘만 사용한다면 충분히 사용할만 할 것 같습니다. 단 기존에 kubernetes를 사용하던 환경에서 자빅스 서버를 kubernetes로 관리할만 하다는 것 이지, 자빅스 서버를 쓰기 위해 kubernetes를 도입하는것은 좋은 방법이라고 보기 힘듭니다. (단, 컨테이너 특성상 휘발성 데이터 성격을 가지므로 DB쪽은 신경을 많이 써서 구축하여야 합니다.)
3번의 경우 어떠한 환경이냐에 따라 다르지만 일반적으로 컨테이너화를 할만 하다고는 보입니다만, 자빅스 서버는 자빅스를 위한 용도로만 사용하는것이 좋다고 생각하기 때문에 자빅스 서버를 다용도로 활용하는 것 자체를 추천드리지 않습니다.
4번의 경우 3번에 적은 내용과 같습니다.
-
3. 자빅스에서 자주 이슈가 되는 housekeeper process를 어떤식으로 대비할 것 인가?
housekeeper process는 자빅스를 사용 하다보면 몇번쯤은 보게 될 것입니다. 이 프로세스는 자빅스에서 일정 기간이 지나면 데이터를 삭제하는 기능을 하고 있습니다.
문제는 데이터가 많아질 수록 이 프로세스가 동작할 경우 Disk I/O를 심각하게 사용한다는 점 입니다. housekeeper process는 자빅스에서 주기적으로 실행되는데 Disk I/O가 부족해질 경우 일부 또는 전체 모니터링 불가, 데이터 수집 불가 등의 모니터링 시스템으로써는 크리티컬한 현상이 발생 합니다.
이러한 현상을 대비하기 위해 우리는 자빅스 서버를 구축할 때 일반적인 APM으로 구축하고 mysql partitioning을 할것인가, mysql 대신 postgresql로 구축하고 timescaledb를 사용할 것인가를 생각해두고 구축을 진행 해야 합니다.
-
4. Zabbix High Availability 구성에 대하여
Zabbix High Availability(이하 Zabbix HA) 구성을 할 수 있는걸로 알고 있습니만, 정말 커다란 인프라를 가지고 있는 대기업이 아니라면 유지비용 등을 생각하여 득실을 따져봐야 합니다. (Zabbix HA 구성은 추후 포스팅 예정 입니다)
모니터링이 죽었다고 실제 서비스들이 죽는것은 아니며, 일반적으로 Zabbix에서 발생하는 모니터링 장애는 하드웨어 장애 또는 구성상의 문제일 가능성이 높기 때문에 어느정도는 예측이 가능 합니다.
사실 모니터링 시스템이 죽었다는 것은 이후 발생할 장애에 대하여 감지할 수 없다는것과 마찬가지이기 때문에 모니터링 시스템을 생각한다면 괴장히 크리티컬한 이슈지만, 일반적인 기업들의 경우 자빅스만 쓰는것이 아니라 PRTG, MRTG, Whats up 등 여러가지 모니터링 솔루션을 같이 이용하기 때문에 자빅스에 문제가 발생 하더라도 down time이 길게 유지되는것이 아닌 이상 그렇게까지 크게 신경을 쓰지는 않습니다.
정리하자면 다음과 같습니다.
- 다른 모니터링 솔루션을 같이 사용하여 이중, 삼중으로 모니터링을 하고 있는가?
- Zabbix HA 구성을 하며 발생하는 유지보수 비용 이상의 값어치가 있는가?
이러한 이유로 'Zabbix HA 구성이 필요한가?'를 생각해 본다면 여러 방면에서 생각 해보아야 할 것 입니다.