zabbix와 prometheus는 두개 다 충분히 좋은 모니터링 도구이다. 보통 사람들은 아래와 같은 이유로 k8s 나 MSA 구조에서는 prometheus를 선호한다.
항목
Prometheus
Zabbix
수집 모델
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.
답글 남기기
댓글을 달기 위해서는 로그인해야합니다.