01. Zabbix 소개

back

Zabbix 소개

Zabbix는 오픈소스 기반의 통합 모니터링 솔루션으로, 서버, 네트워크, 애플리케이션, 클라우드 자원을 폭넓게 감시할 수 있다.
Zabbix는 Agent, SNMP를 포함해 다양한 데이터 수집 방식을 지원하며, 환경에 따라 Agent 기반 또는 Agentless 방식으로 구성할 수 있다.
Linux, Windows, macOS, FreeBSD, Solaris, AIX, HP-UX 등 다양한 운영체제 환경을 지원한다.
Web UI를 통해 Host, Template, Item, Trigger, Graph, Discovery rule, Action 등을 통합 관리할 수 있으며, 데이터 수집 정책과 알람 정책을 중앙에서 운영할 수 있다.
기본적으로 ICMP, TCP, 프로세스 상태, 웹 시나리오, CPU/Memory/Disk 같은 자원 사용량을 모니터링할 수 있으며, MySQL, NGINX, Redis, Kafka, Ceph, HAProxy, Kubernetes 등 소프트웨어 레벨의 모니터링도 지원한다.
또한 Grafana 플러그인을 이용해 Zabbix 수집 데이터를 Grafana 대시보드에서 시각화할 수 있다.

Zabbix 핵심 용어

Host: IP 또는 DNS를 기준으로 모니터링 대상이 되는 서버, 장비, 서비스 단위이다.
Host group: Host를 논리적으로 묶는 그룹으로, 권한 관리와 운영 분리에 활용된다.
Template: 하나 이상의 Host에 재사용하기 위한 Item, Trigger, Graph, Discovery rule 등의 묶음이다.
Item: Host에서 수집하려는 개별 데이터 항목이며, CPU 사용률, 디스크 용량, 응답시간 같은 메트릭을 의미한다.
Trigger: Item 값을 기준으로 장애 여부나 임계치를 판단하는 논리식이다.
Event: Trigger 상태 변경, 자동 등록, 유지보수 종료 등 Zabbix에서 의미 있는 상태 변화가 발생했을 때 생성되는 기록이다.
Action: Event 발생 시 메일, 메신저, 웹훅 등으로 어떤 동작을 수행할지 정의하는 규칙이다.
Discovery: 동적으로 변하는 자원을 자동으로 찾아서 Host나 Item을 생성하는 기능이다.
LLD (Low-Level Discovery): NIC, 파일시스템, 마운트 포인트, 디스크, 포트처럼 개수가 변할 수 있는 대상들을 자동으로 찾는 기능이다.
Graph: 수집된 Item 데이터를 시각적으로 표현한 그래프이다.
Dashboard: 여러 호스트와 지표를 한 화면에서 요약해 보여주는 운영 화면이다.
Poller: Zabbix Server 또는 Proxy가 Item 값을 실제로 조회하기 위해 사용하는 수집 워커 프로세스이다.
Proxy: 원격지나 분리된 네트워크 환경에서 데이터를 대신 수집하고 Server로 전달하는 중계 컴포넌트이다.
History / Trend: History는 원시 수집 데이터, Trend는 장기 보관을 위해 요약된 집계 데이터이다. 운영 기간과 저장 공간 산정에 중요하다.
Housekeeping: 오래된 History, Event, Problem 데이터를 정리해 저장 공간을 관리하는 기능이다.
Macro: Template나 Host에 재사용 가능한 변수로, 서버 주소나 임계값 같은 값을 유연하게 관리할 때 사용한다.
Preprocessing: 수집된 원시 데이터를 가공하거나 변환하는 단계이다.
Interface: Host와 통신할 때 사용하는 접점이며, Agent, SNMP, JMX, IPMI, HTTP 등으로 구분된다.

모니터링 항목

기본 감시 구조
요약 설명
1. Template에 정의된 Item을 기준으로 데이터를 수집한다.
2. Trigger는 수집된 데이터를 기준으로 장애 여부나 임계치 초과 여부를 판단한다.
3. Trigger 조건이 충족되면 Event가 생성되며, Action을 통해 메일, 메신저, 웹훅 등의 알림을 전송할 수 있다.
4. Host에는 하나 이상의 Template을 연결할 수 있어 공통 정책을 재사용하기 쉽다.
5. NIC, 파일시스템, 마운트 포인트, 네트워크 인터페이스처럼 동적으로 변경되는 자원은 Discovery rule(LLD, Low-Level Discovery)을 이용해 자동으로 수집할 수 있다.
6. 대규모 환경에서는 Zabbix Proxy를 이용해 분산 수집 구조를 구성할 수 있으며, 본사/지사 또는 망 분리 환경에서도 유용하다.
7. 운영 규모가 커질수록 Poller 수, DB 성능, History/Trend 보관 기간, Housekeeping 정책까지 함께 고려해야 한다.
대표적인 모니터링 대상 예시
1. Database: Apache Cassandra, MongoDB, Microsoft SQL Server, MySQL, PostgreSQL, Redis
2. Software: FTP, ICMP, HTTP, HTTPS, NTP, SMTP, SSH, Telnet, Tomcat, Kafka, Zookeeper, NGINX, RabbitMQ, Memcached, Ceph, HAProxy, Kubernetes
3. OS: FreeBSD, AIX, HP-UX, Linux, Windows, Solaris, macOS
4. Cloud: AWS, Microsoft Azure 등 클라우드 환경의 VM, DB, 스토리지 자원
5. Hardware/Server Management: Dell iDRAC, HPE iLO와 같은 하드웨어 관리 인터페이스

Zabbix 주요 구성 요소

Zabbix Server: 수집 데이터 처리, 트리거 평가, 이벤트 생성, 알림 전송을 담당하는 핵심 컴포넌트이다.
Zabbix Agent / Agent 2: 대상 서버에 설치되어 OS 및 프로세스 메트릭을 수집한다.
Zabbix Proxy: 원격지 또는 대규모 환경에서 데이터를 분산 수집하고 Server로 전달한다.
Web Frontend: 운영자가 설정, 시각화, 대시보드, 알람 정책을 관리하는 UI이다.
Database: 수집 데이터와 설정 정보를 저장하며, 성능과 확장성 측면에서 중요한 요소이다.
Poller: Server/Proxy가 Item 값을 실제로 수집하는 실행 단위이다.
Trapper: 외부 시스템이 Zabbix로 데이터를 직접 보내는 경우 사용하는 수신 방식이다.
Java Gateway: JMX 기반 Java/Tomcat 모니터링을 중계하는 구성 요소이다.
VMware collector: vCenter/ESXi 모니터링을 위한 수집 프로세스이다.
Housekeeper: 오래된 데이터를 정리하는 백그라운드 기능이다.
Discovery manager: 자동 발견 작업을 처리하는 내부 구성 요소이다.

운영 시 참고 사항

Template 중심으로 표준 정책을 설계하면 운영 일관성과 확장성이 좋아진다.
LLD를 적극적으로 활용하면 NIC 추가, 파일시스템 변경, 마운트 포인트 증감 같은 동적 변경 사항을 자동 반영할 수 있다.
운영 규모가 커질수록 Server 스펙뿐 아니라 DB 성능, 저장 기간(History/Trend), Housekeeping 정책, Proxy 사용 여부, Poller 수를 함께 고려해야 한다.
단순 Ping 감시 수준을 넘어서 애플리케이션 상태와 서비스 응답 시간을 함께 감시해야 실제 운영 품질을 높일 수 있다.
Host, Item, Trigger, Action의 관계를 먼저 이해하면 템플릿 작성과 트리거 설계가 쉬워진다.

Zabbix 스펙 산정

Metric 범위	CPU	Memory	Instance
1,000 metrics	2 vCPU	8 GiB	m6i.large 또는 동급
10,000 metrics	4 vCPU	16 GiB	m6i.xlarge 또는 동급
100,000 metrics	16 vCPU	64 GiB	m6i.4xlarge 또는 동급
1,000,000 metrics	32 vCPU	96 GiB	m6i.8xlarge 또는 동급

위 수치는 운영 환경에 따라 달라질 수 있는 예시 기준이며, 실제 산정 시에는 수집 주기, History/Trend 보관 기간, 활성 Trigger 수, Proxy 사용 여부, DB 성능을 함께 고려해야 한다.
일반적으로 1 metric은 1 item + 1 trigger + 1 graph 기준으로 산정한다.
Poller, History syncer, Preprocessing worker, Proxy 수까지 같이 보는 것이 실제 운영에는 더 정확하다.

Reference

작성일: 2026년 8월 4일 , 마지막 업데이트: 2026년 8월 13일