Zabbix vs Prometheus

zabbix와 prometheus는 두개 다 충분히 좋은 모니터링 도구이다.
보통 사람들은 아래와 같은 이유로 k8s 나 MSA 구조에서는
prometheus를 선호한다.

항목PrometheusZabbix
수집 모델HTTP pull(Pushgateway 보조), 서비스 디스커버리Agent/Agent2, SNMP/Trap, IPMI, JMX, HTTP, VMware 등
데이터/쿼리시계열 + PromQL로 집계·경향 분석항목(Item)/트리거 기반 임계치, 비주기 데이터도 용이
알림Alertmanager (그룹핑/억제/라우팅)내장 알림/에스컬레이션/원격 커맨드
시각화Grafana 등 외부 주로 사용내장 대시보드/그래프/맵/리포트/Grafana
확장/보관장기보관·수평확장엔 Thanos/Cortex/Mimir 등 추가 스택단일 서버+DB 구조, Proxy로 분산 수집/격리, 7.0은 Proxy HA
K8s표준(노드/파드/어플 지표 + Exporter 생태계)7.0+ Helm+Proxy+에이전트 가이드/템플릿 제공


다시 말하지만 둘 다 충분히 좋은 도구이다.
모니터링에 있어서 나만의 개똥철학을 하나 얘기하고자 한다

모니터링에 있어서 무엇보다 중요한건 어떤 지표를 긁고 분석할 수 있냐 없느냐의 능력이
그 사이트의 시스템 가용성과 신뢰성을 보장하는데 중요한 역할을 한다고 나는 본다.

그래서 가장 중요한건 지표를 얼마나 잘 다루는지에 달려 있다.
결국은 엔지니어에게 달려 있다는 말이다. 자기 철학과 능력이 있어야만 한다.

prometheus가 할 수 있는건 zabbix도 할 수가 있고.
zabbix가 할 수 있는건 prometheus도 할 수 있다.
둘 다 서로 장단점이 있는 분야에 쉽게 가느냐 조금 돌아서 가느냐의 차이다.


결론은 결국 사람이다.
어떤 도구를 선택하느냐는 간단하다.
앞서 얘기한 기준에 부합되는 엔지니어가 선택하는 도구를 쓰면 될 뿐이다.
zabbix를 잘 다루면 zabbix로 prometheus를 잘 다루면 prometheus를
단지, 사람에 휘둘리지 않도록 운영.구축에 대한 문서화가 잘 이루어지고
엔지니어에 대한 교육이 잘 따라와 주어야 한다.

잡설이 길었다.
그래서 나는 어느쪽일지 궁금할 것이다.
나는 prometheus가 존재하지도 않던 시절부터 zabbix를 다뤄왔던 사람이고.
zabbix가 더 익숙하다.
zabbix로 적어도 모니터링 체계에 있어서는 나름 체계있게 구축하고
운영해왔다고 자부한다.

K8S/application/OS/Network/HW/전력사용량 인프라와 운영에 관련된 영역에
있어서는 부치고자 하면 zabbix로 모든걸 커버하고 운영해온 이력이 있으며

앞으로
이러한 부분을 기반으로 실무 베이스로 해서 zabbix 사용법을 공유해 나가려 한다.

ⓒ 2025 엉뚱한 녀석의 블로그 [quirky guy's Blog]. 본문 및 이미지를 무단 복제·배포할 수 없습니다. 공유 시 반드시 원문 링크를 명시해 주세요.
ⓒ 2025 엉뚱한 녀석의 블로그 [quirky guy's Blog]. All rights reserved. Unauthorized copying or redistribution of the text and images is prohibited. When sharing, please include the original source link.

🛠 마지막 수정일: 2025.09.18