자빅스를 사용하여 모니터링 시스템을 구축하는데에 있어서 내용을 정리할 겸, 시간이 날 때마다 가이드식으로 여러편으로 나눠 포스팅을 하려 합니다. 지극히 개인적인 의견을 포스팅 하는 것 이며, 다른 의견의 피드백 환영 합니다.
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 구성이 필요한가?'를 생각해 본다면 여러 방면에서 생각 해보아야 할 것 입니다.
자빅스 텔레그램을 연동할 때, 여러개의 채팅 봇을 사용하여 용도별 또는 중요도 별로 나눠서 관리할 수 있습니다.
즉 ICMP Ping Down은 모니터링 1번방으로, Port Down은 모니터링 2번방으로 연동 한다거나 Warining 등급을 1번방으로, Average 등급을 2번방으로 나눠서 연동하여 관리할 수 있습니다. 참고로 연동할 수 있는 방의 개수 리밋은 확인하지 못했지만 현재 저가 가지고 있는 방만 15개가량 되므로 실무에서 충분히 나눠서 사용할 수 있습니다.
이번 포스팅의 경우 간단하게 작성할 예정이므로 텔레그램을 연동하는 방식에 대해 알고 있어야 합니다. 궁금하신 내용이 있을 경우 댓글 달아주세요.
기존에 사용중이던 파일을 복사했으므로 waring/zbxtg_settings.py 파일에서 tg_key , zbx_basic_auth_user , zbx_tg_daemon_enabled_ids , zbx_tg_daemon_enabled_users 부분만 변경 해주세요.
api code와 chat id, 채팅 봇의 계정명만 작성 해주시면 됩니다. (zbx_basic_auth의 경우 false 이기 때문에 user를 변경하지 않아도 될것으로 예상 되지만 따로 테스트 해보지는 않아서 그냥 변경 해주고 있습니다. )
이후 /var/tmp/zbxtg/uids.txt 파일, /home/zabbix/uids.txt 파일에 해당 내용을 추가 해주어야 합니다. 만약, 기존에 아래와 같은 형식으로 이미 작성되어 있다면 그 아래줄에 채팅 봇 계정과 chat id를 추가 해주시면 됩니다.
nirsa_test_bot;private;105849283
nirsa_waring_bot;private;10235089 ## 추가
자빅스 웹페이지 설정
아래 부분의 script name이 햇갈리실수도 있는데, 현재 자빅스 서버의 스크립트 경로는 /usr/lib/zabbix/alertscripts 이므로 zbxtg.py만 작성 한다면 /usr/lib/zabbix/alertscripts/zbxtg.py 가 되고, waring/zbxtg.py를 작성 한다면 /usr/lib/zabbix/alertscripts/waring/zbxtg.py가 됩니다.
이 부분만 이해하신다면 미디어 타입을 설정하는데에 큰 어려움은 없으실 겁니다. 하나뿐만이 아니라 여러개의 알람을 설정하도록 할때에도 같은 방법으로 작성 해주시면 됩니다.
Action 부분에 대해서는 각 셋팅 환경에 따라 조금씩 달라질 수 있습니다. 각각 다른 사용자 계정을 통해 관리 한다던지, Admin 계정만을 사용하여 관리 한다던지 등의 차이가 있습니다.
핵심은 Action에서 Conditions을 통한 알람 관리 입니다. 적절한 조건들을 조합하여 원하는 알람만 수신받을 수 있도록 해주어야 합니다.
기존에 저가 사용중이던 Action을 Average 등급만 알람을 수신한다고 예를 들자면 아래와 같이 Trigger sverity를 Average equals일때만 받도록 설정 해주어야 합니다.
새로 생성한 waring의 경우 기존에 사용중이던 action 말고, 새로운 action을 생성하면서 아래와 같이 waring 등급만 수신받을 수 있도록 설정 해주어야 합니다.
또 한가지, 하나의 계정(ex. Admin)만 사용할 경우 User의 Media에서 새로운 타입을 생성 해주셔야 합니다. send to가 다르기 때문에 user media를 생성하지 않으면 알람을 수신받을 수 없습니다.
저의 경우 waring만 수신받을 예정이기 때문에 use if severity를 waring만 체크한 media를 하나 더 생성 하였습니다.
알람 확인
CPU 부하를 발생시켜 waring 알람이 재대로 동작 하는지 확인 해보앗습니다. waring을 연동한 봇에서는 알람을 정상적으로 수신할 수 있었고, 기존에 만들어둔 average을 연동한 그룹방에서는 알람을 수신받지 않았습니다.
이러한 방법으로 용도에 맞게 설정을 하여 크리티컬하지 않고 참고하여 다음날 처리해도 되는 알람들은 핸드폰에 알람을 꺼두거나 하여 퇴근 후 업무에 대한 스트레스를 조금이나마 줄일 수 있습니다.
zabbix_server.conf 파일에서 AlertScriptsPath를 확인 합니다. 디폴트 상태로 사용 하셔도 되고, 별도의 경로를 설정하고 싶다면 원하는 경로로 수정 후 zabbix-server서비스를 재시작 해주세요.
vi /etc/zabbix/zabbix_server.conf
2) 텔레그램 채팅 봇 생성
텔레그램에서 botfather를 검색하여 메세지 창을 열어주면 메세지 창에 Start 가 보이실 텐데 클릭 하시면 됩니다. 저는 이전에 연동했던 이력이 있어서 아래 이미지에 조금 차이가 있을 수 있습니다.
/newbot을 입력한 후 봇 이름과 사용자명으로 사용할 네임을 작성 해주시면 됩니다. 저는 둘 다 똑같이 했고 사용자명의 경우 마지막에 bot 단어가 들어가야 합니다.
* 아래 빨간 박스 부분에 코드가 있을텐데 코드 전체를 복사하여 메모장 등에 보관 해주세요
이제 생성했던 채팅 봇의 사용자명을 검색하면 나오게 되는데, 클릭하여 시작 버튼까지 눌러 주세요.
* 봇을 시작하는걸 생략하면 404 에러가 발생하니 꼭 진행 해주셔야 합니다.
이제 위에서 fatherbot에게 받았던 코드를 사용하여 웹 브라우저에서 아래와 같이 입력하여야 합니다. 아래 코드는 예시 입니다.
* fatherbot에게 받았던 코드를 입력하는 앞단에 "bot" 이라는 단어가 들어가야하니 주의 해주세요.
# https://api.telegram.org/bot[fatherbot에게 받았던 코드]/getUpdates
https://api.telegram.org/bot1143349:Al8CbFtPQcKXVM/getUpdates
봇을 재대로 시작하고, 정확히 코드를 입력했다면 아래와 같은 텍스트가 출력 됩니다.
3) 채팅 봇 그룹방 초대 및 메세지 접근 권한 설정
생성한 텔레그램 채팅봇 개인 메세지 우측 상단에 메뉴 버튼을 클릭 후 Add to Group을 클릭 해주세요.
이후 추가하려는 그룹방을 선택 후 초대를 완료 해주세요.
그룹방으로 이동하여 상단 매뉴 → View group info 를 클릭 해주세요.
봇을 클릭 후 Promote to admin을 클릭 해주세요.
아래 상테에서 그대로 SAVE를 클릭하면 관리자로 임명되어 메세지 접근 권한이 생기고 봇 옆에 별이 생기는것을 확인할 수 있습니다.
4) 템플릿 설치 및 설정
자빅스 서버로 되돌아 와서 아래 코드와 같이 템플릿을 설치한 후 작업을 진행 해주세요.
cd ~
git clone https://github.com/ableev/Zabbix-in-Telegram
mv Zabbix-in-Telegram/* /usr/lib/zabbix/alertscripts
이제 아래와 같이 텔레그램 채팅 id를 확인할 파이썬 파일을 하나 만들어 주어야 합니다. 위에서 브라우저에 입력할때는 father봇에게 받았던 코드 앞에 "bot" 단어를 추가 했었지만, 여기서는 따로 추가해주지 않고 그대로 사용 하시면 됩니다.
cd ~
vim chat.py
#!/usr/bin/env python
import telegram
import requests
my_token = '[father봇에게 받았던 코드]'
bot = telegram.Bot(token = my_token)
updates = bot.getUpdates()
for u in updates :print(u.message)
파이썬 3.8을 실행시켜 chat.py 파일을 실행 시켜주세요.
python3 chat.py
만약, 아무것도 출력되지 않는다면 채팅봇에게 채팅 아무렇게나 한번 치고나서 다시 시도하면 됩니다. 출력된 값에서 필요한것은 id 값의 숫자 입니다.
아래 이미지의 빨간 박스 부분이 필요한데, id는 음수로 표현되어 있고 옆의 type 필드는 group으로 되어 있습니다. 자세히 보면 그 아래에 id 필드에 양수로 적혀저 있는 부분이 있는데, 이 부분은 개인 메세지(1:1)의 id값이니 무시 하시고 음수로 표현된곳의 id값을 확인 해주세요.
* 개인 채팅은 양수, 그룹 채팅은 음수로 표현 됩니다.
chat id까지 확인 되었다면 사용할 파일을 만들어야 하는데, 샘플 파일을 복사 후 권한을 설정 해주세요.
