1~2편에서 Zabbix 서버를 구동하고 알림 채널을 연결했다면, 이제 실제 모니터링 항목을 만들 차례입니다. 그 전에 Zabbix의 핵심 구조를 이해하지 않으면 설정이 복잡해질수록 어디서 무엇이 잘못됐는지 파악하기 어렵습니다.
이번 편에서는 아이템, 트리거, LLD 세 가지 개념을 실전 관점에서 정리합니다.
아이템(Item): 데이터를 수집하는 단위
아이템은 Zabbix가 수집하는 개별 데이터 포인트입니다. 하나의 아이템이 하나의 메트릭에 대응합니다. 아이템 타입에 따라 데이터를 수집하는 방식이 달라집니다.
주요 아이템 타입 비교
| 타입 | 방향 | 설명 | 주요 용도 |
|---|---|---|---|
| Zabbix Agent (Passive) | Zabbix → Agent | 서버가 에이전트에게 요청 | 일반 서버 모니터링 |
| Zabbix Agent (Active) | Agent → Zabbix | 에이전트가 서버에 데이터 전송 | 방화벽 안쪽 서버 |
| Trapper | 외부 → Zabbix | zabbix_sender로 밀어넣기 | 커스텀 스크립트 |
| External Check | Zabbix → 스크립트 | Zabbix가 스크립트 실행 후 결과 수집 | API 폴링 |
| SNMP | Zabbix → 장비 | SNMP OID 폴링 | 네트워크 장비 |
이 시리즈에서 주로 사용하는 타입은 Trapper입니다. Proxmox, iLO, iDRAC 모두 외부 Python 스크립트가 API를 호출해 데이터를 수집하고, zabbix_sender로 Zabbix에 밀어넣는 구조입니다.
Trapper 아이템 생성 시 주의점
Trapper 아이템은 Zabbix가 능동적으로 수집하지 않습니다. 외부에서 데이터를 보내주기 전까지 값이 없습니다. 따라서 아이템 생성 시 Update interval을 설정할 필요가 없고, 설정해도 의미가 없습니다.
값 타입(Value type) 선택 기준:
| 수집 데이터 | Value type |
|---|---|
| CPU 사용률, 온도, 카운트 | Numeric (float) 또는 Numeric (unsigned) |
| 노드명, 상태 문자열 | Text 또는 Character |
| JSON (LLD용) | Text |
문자열 타입(Text, Character)은 트렌드(Trends) 저장을 지원하지 않습니다. 아이템 생성 시 Trends 항목을 비워두거나 0으로 설정해야 오류가 발생하지 않습니다.
트리거(Trigger): 조건에 따라 알림을 발생시키는 규칙
트리거는 아이템 값이 특정 조건을 만족할 때 알림을 발생시킵니다.
Zabbix 7.0 트리거 표현식 문법
Zabbix 6.0부터 트리거 표현식 문법이 변경됐습니다. 기존 문법으로 작성된 자료를 참고할 때 주의가 필요합니다.
기존 문법 (6.0 이전):
{hostname:key.func()} > 값신규 문법 (6.0 이후, 7.0 포함):
func(/hostname/key, 파라미터) > 값실제 예시로 비교하면:
# 구버전 (동작 안 함)
{proxmox-cluster:proxmox.node.cpu[pve11].last()} > 90
# 신버전 (올바른 형식)
last(/proxmox-cluster/proxmox.node.cpu[pve11]) > 90Zabbix API로 트리거를 생성할 때도 동일합니다. 구버전 형식을 사용하면 Invalid parameter 오류가 반환됩니다.
자주 쓰는 트리거 함수
| 함수 | 설명 | 예시 |
|---|---|---|
last() | 가장 최근 값 | last(/host/key) > 90 |
avg(#3) | 최근 3회 평균 | avg(/host/key,#3) > 80 |
min(5m) | 최근 5분 최솟값 | min(/host/key,5m) = 0 |
nodata(10m) | 10분간 데이터 없음 | nodata(/host/key,10m) = 1 |
순간 스파이크에 의한 오탐을 줄이려면 last() 대신 avg(#3) (최근 3회 평균)을 쓰는 것이 효과적입니다.
트리거 심각도 설계
| 심각도 | 사용 기준 |
|---|---|
| Information | 참고용, 알림 불필요 |
| Warning | 주의 필요, 슬랙 알림 |
| Average | 즉시 확인 필요 |
| High | 서비스 영향 가능성 |
| Disaster | 서비스 중단 |
Warning 이상부터 Slack 알림을 받도록 Action을 설정하면 불필요한 알림을 줄일 수 있습니다.
LLD(Low Level Discovery): 동적으로 아이템을 생성하는 메커니즘
LLD는 Zabbix에서 가장 강력한 기능 중 하나입니다. 모니터링 대상 목록이 동적으로 변할 때 아이템을 일일이 수동으로 만들지 않아도 됩니다.
동작 원리
- Discovery Rule: JSON 형태의 목록을 반환하는 아이템을 정의
- Item Prototype: 발견된 각 항목에 대해 생성할 아이템 템플릿
- Trigger Prototype: 발견된 각 항목에 대해 생성할 트리거 템플릿
- Zabbix가 Discovery Rule을 주기적으로 실행 → JSON 파싱 → Prototype 기반으로 아이템/트리거 자동 생성
Discovery JSON 형식
[
{"{#NODE}": "pve11", "{#IP}": "10.0.92.11"},
{"{#NODE}": "pve12", "{#IP}": "10.0.92.12"},
{"{#NODE}": "pve13", "{#IP}": "10.0.92.13"}
]중괄호로 감싼 대문자 키({#NODE})가 매크로입니다. Item Prototype에서 이 매크로를 키나 이름에 사용하면 발견된 항목마다 아이템이 생성됩니다.
Item Prototype 키 예시:
proxmox.node.cpu[{#NODE}]pve11, pve12, pve13이 발견되면 Zabbix가 자동으로 아래 세 아이템을 만듭니다:
proxmox.node.cpu[pve11]
proxmox.node.cpu[pve12]
proxmox.node.cpu[pve13]zabbix_sender로 Discovery 데이터 전송
zabbix_sender로 Discovery JSON을 전송할 때는 일반 아이템과 동일하게 키와 값을 전달합니다.
import json, subprocess
lld = [
{"{#NODE}": "pve11", "{#IP}": "10.0.92.11"},
{"{#NODE}": "pve12", "{#IP}": "10.0.92.12"},
]
subprocess.run(
["docker", "exec", "zabbix-server",
"zabbix_sender", "-z", "127.0.0.1", "-p", "10051",
"-s", "proxmox-cluster",
"-k", "proxmox.node.discovery",
"-o", json.dumps(lld)],
capture_output=True, timeout=30
)Discovery Rule의 키(proxmox.node.discovery)가 Trapper 타입으로 등록되어 있어야 합니다.
Trapper 아이템의 stale value 문제
Trapper 아이템을 운영할 때 반드시 알아야 할 특성이 있습니다.
Zabbix는 Trapper 아이템의 마지막 값을 무기한 유지합니다.
외부 스크립트가 데이터를 보내지 않으면 이전 값이 그대로 남습니다. 이것이 문제가 되는 경우는 모니터링 대상이 변경됐을 때입니다.
실제 발생한 사례
서버에서 RAID 컨트롤러를 P440ar(HP Smart Array)에서 LSI 9217(HBA)으로 교체했습니다. P440ar에 연결된 물리 드라이브 8개의 health 아이템이 Zabbix에 등록되어 있었는데, 교체 후 스크립트가 P440ar 드라이브 정보를 더 이상 수집하지 못하게 됐습니다.
결과: 기존 8개 아이템에 degraded 상태 값이 그대로 남아 있어 “Physical drive health degraded” 알림이 계속 발생했습니다.
해결 방법
단기 해결: 해당 아이템을 수동으로 삭제하거나 최신 값을 강제 업데이트합니다.
장기 해결: 트리거 조건에 nodata() 를 추가합니다.
# stale value 방지: 데이터가 30분 이상 없으면 트리거 비활성화
last(/host/proxmox.node.disk.health[pve13,sda]) >= 1
and nodata(/host/proxmox.node.disk.health[pve13,sda], 30m) = 0또는 LLD Discovery를 활용해 존재하지 않는 항목은 자동으로 제거되도록 Keep lost resources period를 적절히 설정합니다.
정리: 커스텀 모니터링 구현 전 체크리스트
- [ ] 수집 방식에 맞는 아이템 타입 선택 (커스텀 스크립트 → Trapper)
- [ ] 문자열 값은 Trends 저장 비활성화
- [ ] 트리거 표현식은 Zabbix 7.0 신규 문법 사용
- [ ] 동적 대상(노드, 디스크 등)은 LLD로 구현
- [ ] Trapper 아이템은 stale value 가능성 고려
마치며
아이템 타입의 차이, 트리거 문법 변경, LLD 구조, stale value 문제까지 이해했다면 다음 편부터 본격적인 Proxmox 모니터링 구현으로 넘어갑니다.
다음 편에서는 Proxmox API 토큰 발급과 권한 설계를 다룹니다. 어떤 권한을 어느 경로에 부여해야 하는지, 잘못 설정했을 때 어떤 오류가 발생하는지를 실제 경험 기반으로 설명합니다.
