2026년 11월 5일에 Zabbix 8.0 LTS가 나왔다. 7.x까지의 Zabbix가 서버와 네트워크 장비를 긁어 모으는 인프라 모니터링 도구였다면, 8.0은 애플리케이션 트레이스와 로그까지 받겠다는 쪽으로 방향을 꺾었다. Zabbix 공식 수명주기 정책에 따르면 전체 지원은 2029년 11월 30일까지, 제한 지원은 2031년 11월 30일까지다.
공식 문서의 What's new와 업그레이드 노트를 기준으로 하나씩 살펴본다. 성능 수치처럼 벤더가 직접 말한 것은 그렇다고 적었다.
APM이 들어왔다
가장 큰 변화는 OpenTelemetry 기반 APM이다. Zabbix proxy가 OTLP/gRPC로 텔레메트리를 받고(proxy를 --with-apm 옵션으로 빌드해야 하고 APMListenIP, APMListenPort 파라미터로 수신 주소를 정한다), 프런트엔드에 APM 메뉴가 생겨서 트레이스와 메트릭, 로그를 거기서 본다. 앱이 직접 보내도 되고 이미 쓰는 OTel Collector를 proxy 쪽으로 돌려도 된다.
눈여겨볼 건 Telemetry query라는 새 아이템 유형이다. OTel 데이터를 일반 아이템처럼 트리거, 그래프, LLD에 쓸 수 있어서, 예를 들어 특정 서비스의 에러 스팬 비율로 기존 방식 그대로 알람을 걸 수 있다. 접근 제어도 기존 체계에 얹혔다. 사용자 역할로 APM 메뉴를 열어 줄지 정하고, 사용자 그룹으로 보여 줄 리소스 범위를 나눈다.
전제가 하나 있다. 텔레메트리 저장소로 ClickHouse가 필요하다. 그리고 앱 계측은 Zabbix가 대신해 주지 않으니 OpenTelemetry SDK나 에이전트를 앱에 붙이는 작업은 따로 해야 한다.
ClickHouse를 히스토리 저장소로
ClickHouse는 APM 데이터뿐 아니라 일반 아이템 히스토리의 저장소로도 쓸 수 있다. 문서는 기존 MySQL, PostgreSQL 히스토리를 옮기는 마이그레이션 스크립트도 제공한다고 밝힌다. 벤더는 성능과 저장 공간 절감을 내세우지만 수치는 벤더 측 발표이므로, 아이템이 수십만 개 넘는 환경이라면 테스트 서버에서 직접 재 봐야 한다.
설정 쪽 영향이 있다. 서버 파라미터 HistoryStorageURL, HistoryStorageTypes, HistoryStorageDateIndex가 deprecated되고 HistoryProvider로 바뀐다. 프런트엔드 설정의 $HISTORY도 $HISTORY_PROVIDERS로 바뀐다. 새 파라미터와 옛 파라미터는 섞어 쓸 수 없다. 옛 파라미터는 당장 삭제된 것이 아니라 deprecated 상태지만, Elasticsearch로 히스토리를 보내던 곳은 언젠가 옮겨야 한다.
알람 노이즈를 줄이는 이벤트 처리 엔진
복합 이벤트 처리(CEP) 엔진은 장애가 터졌을 때 알림이 우르르 쏟아지는 문제를 겨냥한다. 슬라이딩, 텀블링 시간 윈도우 안에서 이벤트를 규칙으로 처리하고, 연관된 이벤트를 원인과 증상으로 묶는다. 같은 이벤트가 너무 자주 발생할 때, 반대로 발생해야 하는데 오지 않을 때 알려 주는 조건도 지원한다. 이벤트 수명과 개수 제한도 규칙에 넣을 수 있다.
기존의 트리거 의존성이나 상관관계 규칙으로 맞추던 일을 한곳에서 선언적으로 하게 된다는 점이 실무에서 달라지는 부분이다. 다만 규칙이 많아질수록 어떤 이벤트가 왜 묻혔는지 추적하기 어려워질 수 있으니, 억제 규칙은 적게 시작하는 쪽이 안전하다.
AI 에이전트를 붙이는 MCP 서버
Model Context Protocol 서버가 들어와서 AI 에이전트가 Zabbix에 자연어로 묻고 조작할 수 있다. 문서가 드는 예는 장애 조회와 유지보수 일정 등록이다. 인증은 Zabbix API 토큰을 쓰기 때문에 에이전트는 그 토큰 소유자의 권한 안에서만 움직이고, 변경 내역은 그 사용자 이름으로 감사 로그에 남는다.
이 구조는 쓰는 사람이 권한을 정해 주면 된다는 뜻이기도 하다. 처음에는 조회 전용 역할의 토큰을 따로 만들어 연결해 보고, 확인과 유지보수 등록 같은 쓰기 권한은 나중에 열어 주는 순서가 무난하다.
화면, 템플릿, 모바일
화면에서는 테이블 뷰 커스터마이즈(컬럼 숨김과 순서 변경, 뷰 저장), 대시보드 내보내기와 가져오기, Scatter Plot 위젯, 다크 블루 테마가 들어왔다. 문제 화면에서 바로 트리거 유지보수를 만드는 기능도 있다. 환경 간 대시보드를 옮길 수 있게 된 점이 운영팀에는 반가운 변화다.
새 템플릿으로는 Claude API by HTTP, OpenAI Platform by HTTP가 눈에 띈다. LLM API 사용량도 모니터링 대상이 됐다는 뜻이다. Kubernetes Cluster by HTTP와 Kubernetes Node by HTTP는 예전 Kubernetes 템플릿을 대체하고, MariaDB, Percona, Podman 템플릿도 추가됐다. 기존 템플릿은 자동으로 올라가지 않아서 새 기능을 쓰려면 직접 갱신해야 한다. iOS, Android 모바일 앱은 푸시 알림과 문제 조회, 대응을 지원하는 것으로 문서에 소개돼 있지만 아직 나오지 않았고 곧 출시될 예정이다.
보안 기본값이 바뀌었다
신규 설치에서는 모든 역할의 API 접근이 기본으로 꺼져 있다. 기존 설치는 새로 만드는 역할에만 이 기본값이 적용된다. HTTPS에 접속하는 템플릿과 미디어 타입은 인증서를 기본으로 검증하고, {$HTTP.TLS.VERIFY} 매크로에 none, peer, full을 줄 수 있다. 사설 CA나 자체 서명 인증서로 돌리던 웹훅은 업그레이드 뒤에 갑자기 실패할 수 있으니 미리 점검해야 한다.
에이전트와 에이전트 2에는 AllowKeyRegexp, DenyKeyRegexp가 생겼다. 정규식으로 실행 가능한 아이템 키를 제한하는 기능이다. 인증 쪽에서는 SAML 인증서 가져오기, HashiCorp Vault AppRole, 역할별 로그인 후 이동 URL이 추가됐다.
업그레이드 전에 걸리는 것들
최소 요구 버전이 꽤 올랐다. 서버가 기동 자체를 거부하는 경우가 있어서 가장 먼저 확인할 부분이다.
| 항목 | 이전 최소 | 8.0 최소 |
|---|---|---|
| PHP | 8.0.0 | 8.2.0 |
| MySQL, Percona | 8.0.30 | 8.4.0 |
| MariaDB | 10.5.00 | 10.11.00 |
| PostgreSQL | 13.0 | 15.0 |
| TimescaleDB | 2.13.0 | 2.20.0 |
| Elasticsearch | 7.0.0 | 8.0.0 |
Elasticsearch가 8.0 미만이면 서버가 시작하지 않고 AllowUnsupportedDBVersions로도 우회할 수 없다고 문서가 못 박는다. MySQL에서 utf8mb3 문자셋을 쓰고 있다면 업그레이드 전에 utf8mb4와 utf8mb4_bin 콜레이션으로 바꾸기를 강하게 권장한다.
MS Teams 웹훅 미디어 타입은 Office 365 Connector에 의존했는데, Microsoft가 이 기능을 2026년 5월 22일에 종료해서 더 이상 동작하지 않는다. MS Teams Workflow 웹훅 미디어 타입으로 옮겨야 한다. API 역할도 짚어야 한다. 허용 목록이 비어 있으면 예전에는 무시됐지만 이제는 모든 메서드를 막는다. 그래서 업그레이드 과정에서 허용 목록이 빈 역할에 와일드카드 *가 자동으로 들어가는데, 이 역할은 모든 API 메서드가 열린 상태이니 필요한 메서드만 남기도록 정리해야 한다.
도입은 파일럿부터
기존 Zabbix 운영팀이라면 8.0의 매력은 APM이지만 부담도 APM에서 온다. ClickHouse를 새로 운영해야 하고 앱 계측도 별도 일이다. 그래서 첫 단계는 APM을 켜기보다 최소 버전 충족 여부, MS Teams 알림, API 역할, HistoryProvider 설정처럼 업그레이드 자체에서 깨질 것들부터 확인하는 것이다. 이후 일부 서비스만 OTLP를 proxy로 보내 Telemetry query 아이템으로 알람을 걸어 보면 기존 모니터링과 얼마나 맞물리는지 감이 온다.
Datadog이나 Grafana 같은 전용 옵저버빌리티 제품과 비교하면, 하나의 화면과 하나의 알람 체계로 인프라와 앱을 묶을 수 있다는 점이 Zabbix의 강점이다. 트레이스 분석 깊이나 UI 완성도는 이제 막 들어온 기능이라 전용 제품과 바로 견주기 어렵다. 실제 환경에서 써 본 후기가 쌓이기 전까지는 파일럿 범위에서 확인하는 것이 맞다.