乐维官网
zabbix unreacheable poller解决思路
13607zabbix是一个功能强大的网络监控工具，它可以监控各种网络设备、服务器、应用程序等。zabbix监控数据的收集和处理通过轮询器进程完成，这些进程运行在zabbix server和zabbix proxy上。但是，有时候可能会遇到无...
View detailsZabbix 8.0 LTS 功能解读：APM、ClickHouse、MCP Server 三块新能力，附完整安装部署指南
11 月 5 日，Zabbix 8.0 LTS 正式 GA。这不是一个”多加几个仪表盘组件”的版本：APM、ClickHouse、复杂事件处理、MCP Server 四件事同时进入主线，意味着 Zabbix 正在从”设备与指标的监控工具”往”应用与链路可观测平台”挪位置。
对国内运维团队来说，影响有两层。第一层是能力：采集对象从主机指标扩展到 trace、日志和事件的上下文。第二层更现实——升级门槛被抬高了：MySQL 最低要 8.4、PHP 最低要 8.2，不少跑了三四年的旧环境，光装包就会卡住。
下面分两部分：前半段把 6 个真正改变用法的功能讲清楚，并标明哪些是已经 Ready 的；后半段给出 RHEL 9 与 Ubuntu 24.04 两套可直接复制的安装命令、升级前的门槛清单，以及上线后最容易踩的坑。
更多zabbix、prometheus资料，可以关注乐维社区
01 先说结论：三类团队三种动作
版本号只是表象，先判断自己属于哪一类，再决定要不要跟进。
- 新装环境：直接上 8.0.0。这是当前唯一值得起步的 LTS 基线，后面 8.0.x 只做修复与小幅增强，不存在”刚装完就要跨大版本”的问题。
- 存量 7.x 环境：不要在生产上直接动。先在测试环境跑通”数据库版本、PHP 版本、历史存储配置”三项核对，这三项是 8.0 升级失败的主要原因。
- 只做主机监控的小团队：8.0 的即时收益不在 APM，而在 ClickHouse 历史库、触发器级按需维护、以及 Proxy 限流逻辑的调整。前者解决历史数据膨胀，后两者减少误报和抖动。
另外提醒一句：APM 与 ClickHouse 历史库都只在 server 侧 提供完整支持，Proxy 在 8.0 里新增的是”采集端”角色。看架构图时别把这两件事混在一起。
02 六个值得关注的新功能
2.1 APM：用 OpenTelemetry 把 trace 收进来
这是 8.0 最有分量的一项。Zabbix 现在支持基于 OpenTelemetry 的应用性能监控：Proxy 可以直接通过 OTLP/gRPC 接收应用或 OpenTelemetry Collector 上报的遥测数据，并写入指定数据源。
落地路径由三块拼起来：
- 数据源：在 Administration 下新增的 Data source 里指定 ClickHouse，作为遥测数据的存储端。
- 展示：前端新增 APM 菜单，按 trace 列表、Span 树、Span 详情三个层次看请求耗时与瓶颈。
- 告警：新增 telemetry query 类型的监控项，可以把 trace 数据直接用在触发器和图表里，不用再从外部系统绕一圈。
配置侧新增的参数比较密集，server 有 TelemetryProvider、StartTelemetryQueryPollers；proxy 侧除了这两个，还有 StartAPMCollectors、APMListenIP、APMListenPort 以及三个 TLS 相关参数（APMTLSCAFile、APMTLSCertFile、APMTLSKeyFile）；前端对应 $TELEMETRY_PROVIDERS[]。自行编译 Proxy 时必须带 –with-apm 编译选项，官方包是否包含该能力要按包安装说明确认。
2.2 ClickHouse：历史数据不再是单点瓶颈
ClickHouse 在 8.0 里有两个身份：一是作为后端数据库存监控项的历史值，二是作为 APM 的遥测数据源。官方支持区间为 26.3.0.0 到 26.9.X.X，如果要用作遥测数据源，需要 26.8.17.4 或更高版本。
还有一个容易被忽略的前提：Zabbix server 与 ClickHouse 的系统时间必须同步，否则遥测查询可能丢数据，或者把同一条数据返回两次。做容器化部署时，NTP 和时区这一项要单独检查。
已有 MySQL 或 PostgreSQL 环境想把历史数据迁过去，官方提供了 schema 与历史数据迁移脚本，可以在不停机的前提下分批搬。对历史数据已经上亿行的环境，这是 8.0 里最实用的一项改造。
2.3 CEP：把”一堆相关告警”变成一条因果链
复杂事件处理（Complex Event Processing）用滑动时间窗做规则化的事件分析。一个 10 分钟窗口内落入的所有事件构成一个上下文，窗口前移时旧事件被移出、新事件进入。
窗口的进入、离开、以及”匹配到某种模式”这三个时点，都可以挂操作：提升或降低严重度、增删标签、激活抑制。这意味着过去需要靠动作和脚本硬拼的逻辑，现在可以在事件层直接表达，典型场景包括：
- 把一串相关事件里最早的那条标为 cause，其余标为 symptom，让告警列表只显示根因。
- 为事件设定 TTL，超过时限自动关闭，避免长期悬挂的僵尸告警。
- 同一位置在窗口内连续出现相似事件时才通知，减少重复打扰。
- 某类事件在窗口内出现过于频繁或根本没出现时触发通知，用来兜住”该报没报”。
需要说明的是，官方文档中 CEP 的详细说明会随稳定版逐步补齐，规则的具体写法以正式文档为准，不要在测试环境之外先大规模铺开。
2.4 MCP Server：用自然语言查监控
8.0 引入了 Zabbix MCP Server，通过 Model Context Protocol 把 AI 助手接到监控数据上。可以直接问”数据库服务器上还有哪些未确认的告警””web-01 从今早开始为什么一直报问题”，也可以让它”把 Linux servers 组的主机今晚 22 点到 02 点放进维护”。
权限设计是这项功能能不能进生产的关键：Agent 用 Zabbix API Token 连接，只能访问 Token 所有者被授权的范围，所有变更都记在该用户名下的审计日志里。换句话说，不需要为 AI 单开一套旁路权限。
2.5 移动端 App
Zabbix 移动 App 配套 8.0 上线，支持查看问题列表、问题详情、更新问题，以及推送通知。后端配套三个变化：Users 与 User settings 下新增 Devices 管理页；新增 Push notification 媒体类型；新增 bridge adapter 组件负责 server 与 App 之间的通信，对应 server 参数 BridgeAdapterURL 与 EnableMobileDevices。
2.6 界面与维护体验
几个不起眼但每天都会用到的改动：
•触发器级按需维护：维护周期现在可以定义到触发器或事件名这一级，也能从事件菜单直接一键发起，维护对象可以是主机、触发器、事件名或标签。
•深蓝主题：新增深蓝色主题，可作为默认主题下发。
•散点图组件：仪表盘新增散点图，用来看两个指标之间的相关性、聚集与离群点。
•触发器 operational data 上限提升到 2048 字符，排查时能带上更完整的上下文。
03 升级门槛：先核对再动手
8.0 抬高了多个组件的最低版本，这是升级前必须先过的一道关。下表按官方 Requirements 整理，与 7.x 相比的变化列出来供对照。
| 组件 | 8.0 支持版本 | 与 7.x 相比 |
| MySQL / Percona | 8.4.0 – 9.7.X | 下限从 8.0.30 提到 8.4，Ubuntu 24.04 自带的 8.0.x 不达标 |
| MariaDB | 10.11.00 – 12.3.X | 下限从 10.5 提到 10.11，RHEL 9 默认版本不达标 |
| PostgreSQL | 15.0 – 18.X | 下限从 13 提到 15 |
| TimescaleDB | 2.20.X – 2.29.X | 需社区版，压缩能力才可用 |
| ClickHouse | 26.3.0.0 – 26.9.X.X | 新增；作遥测数据源需 26.8.17.4 及以上 |
| Elasticsearch | 7.X | 仅存历史数据、仅 server 支持，官方标注为实验性 |
| PHP | 8.2.0 – 8.5.X | 下限从 8.0 提到 8.2，前端白屏多半出在这里 |
| Apache / Nginx | 2.4+ / 1.20+ | 基本无变化 |
硬件配置不因新功能而变化，仍按监控指标数量估算。官方给出的起步规格如下，其中”监控指标”的经验口径是 1 指标 ≈ 1 监控项 + 1 触发器 + 1 图表。
| 规模 | 监控指标 | CPU / vCPU | 内存 | 参考云实例 |
| 小型 | 1,000 | 2 核 | 8 GiB | m6i.large / m6g.large |
| 中型 | 10,000 | 4 核 | 16 GiB | m6i.xlarge / m6g.xlarge |
| 大型 | 100,000 | 16 核 | 64 GiB | m6i.4xlarge / m6g.4xlarge |
| 超大型 | 1,000,000 | 32 核 | 96 GiB | m6i.8xlarge / m6g.8xlarge |
04 安装部署：两套可直接复制的流程
以下以全新安装为主，操作系统分别取 RHEL 9 系与 Ubuntu 24.04。数据库选型建议：RHEL 9 环境用 MySQL 8.4（系统自带版本不达标，需从官方仓库装）；Ubuntu 环境更省事的做法是用 PostgreSQL 16，自带的就满足 15 到 18 的区间。
# 1. 安装官方仓库 rpm -Uvh https://repo.zabbix.com/zabbix/8.0/release/rhel/9/noarch/zabbix-release-latest-8.0.el9.noarch.rpm dnf clean all # 2. 安装 server、前端、SQL 脚本与 agent dnf install -y zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-sql-scripts zabbix-agent2 # 3. 数据库（MySQL 8.4，务必来自官方仓库或 MySQL 官方源） dnf install -y mysql-server
4.1 RHEL 9 系：仓库 + 组件 + 数据库
PHP 这一步是 RHEL 9 最容易翻车的地方。系统 AppStream 里的默认版本低于 8.2，需要切到 8.2 及以上的源，否则前端向导会白屏或直接报版本不满足。
4.2 初始化数据库与导入 schema
mysql -uroot -p CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER ‘zabbix’@’localhost’ IDENTIFIED BY ‘Zabbix_2026’; GRANT ALL PRIVILEGES ON zabbix.* TO ‘zabbix’@’localhost’; SET GLOBAL log_bin_trust_function_creators = 1;
# 导入初始 schema，数据量大的环境会跑几分钟 zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix # 导入完成后把参数改回去
字符集必须是 utf8mb4 配 utf8mb4_bin，这一项写错不会在导入阶段报错，而是在后端出现中文乱码或唯一索引异常，排查成本很高。
4.3 配置 server 并启动服务
# /etc/zabbix/zabbix_server.conf DBHost=localhost DBName=zabbix DBUser=zabbix
systemctl restart zabbix-server zabbix-agent2 httpd php-fpm systemctl enable zabbix-server zabbix-agent2 httpd php-fpm
4.4 Ubuntu / Debian：换成 apt 流程
# 1. 安装官方仓库 wget https://repo.zabbix.com/zabbix/8.0/release/ubuntu/24.04/pool/main/z/zabbix-release/zabbix-release_latest+ubuntu24.04_all.deb dpkg -i zabbix-release_latest+ubuntu24.04_all.deb apt update # 2. 安装组件（用 PostgreSQL 时可换成 zabbix-server-pgsql）
# 3. 初始化 PostgreSQL 并导入 schema sudo -u postgres createuser –pwprompt zabbix sudo -u postgres createdb -O zabbix -E Unicode -T template0 zabbix
之后同样在 /etc/zabbix/zabbix_server.conf 里把 DBHost、DBName、DBUser、DBPassword 按 PostgreSQL 的配置改好，再重启 zabbix-server 与 php-fpm。Ubuntu 24.04 自带 PHP 8.3，落在 8.2 到 8.5 区间内，这一步不用额外处理。
4.5 Agent 与容器化
Agent 2 是 8.0 的主推形态，安装包名分别为 zabbix-agent2（RHEL）与 zabbix-agent2（Debian 系）。配置文件里至少写对两项：ServerActive 指向 server 地址，Hostname 与前端登记的主机名完全一致，否则主动模式下主机一直显示不可用。
容器部署方面，官方提供 server、proxy、agent、web 各组件的镜像与 compose 示例。8.0 新增的能力需要在 compose 中额外声明：APM 相关的端口映射与 TLS 证书挂载加在 proxy 服务上；ClickHouse 作为历史库或遥测数据源时，单独起一个 ClickHouse 服务并保证与 server 的时间同步。
4.6 上线前的最小验证清单
1.Reports 下的 System information 里，server 运行状态正常，没有 “not running” 字样。
2.队列页面 Queue 中，10 分钟以上积压接近 0；若持续堆积，先查 history cache 与数据库写入。
3.internal 类型的监控项有数据，说明 server 自身指标采集正常。
4./var/log/zabbix/zabbix_server.log 无持续报错，尤其关注数据库连接与 schema 版本相关提示。
5.新增一台测试主机，主动与被动两种模式都能取到数据，再做一次触发器告警到通知的闭环。
05 六个最容易踩的坑
•数据库版本没达标就开工。Ubuntu 24.04 自带 MySQL 8.0.x、RHEL 9 自带 MariaDB 10.5，都卡在 8.0 的下限以下。先升级数据库，再装 Zabbix。
•PHP 版本被忽略。前端在 8.1 及以下会直接不满足要求，表现为白屏、向导中止或模板渲染异常。
•导入 schema 失败。常见原因是没开 log_bin_trust_function_creators，或库的排序规则不是 utf8mb4_bin。
•历史存储配置照抄旧环境。8.0 调整了历史存储 provider 的配置写法，ClickHouse 与 Elasticsearch 两套部署都会受影响，直接复制 7.x 的配置会导致服务起不来。
•Proxy 想用 APM 却没重编。自行编译的 proxy 必须带 –with-apm，官方包是否内置要按包说明确认。
•时间不同步导致遥测异常。server 与 ClickHouse 的时间偏差会让 trace 查询丢数据或重复返回，容器环境尤其要注意。
另外，8.0 细化了 Proxy 限流逻辑：history cache 达到阈值后 server 仍会停止接收 proxy 数据，但当缓存回落到 60% 时开始处理限流队列，期间仍可能拒收约 1 万条以上的大批量上传。这个行为变化会影响”告警突然集中恢复”时的数据完整性预期，压测时建议按这个阈值设计批量大小。
07 常见问题FAQ
Q：8.0 和 7.4 是什么关系？
8.0.0 从 7.4.0 延续而来，属于 LTS 版本，后续以 8.0.x 形式提供修复与小幅增强。功能演进的下一条线是 8.2 之类的非 LTS 版本。
Q：能不能直接从老版本升到 8.0？
官方升级说明中写明支持从 2.0.x 及之后版本升级到 8.0.x。但实际生产操作仍建议按 7.x 逐级验证，尤其涉及数据库引擎、模板变更和历史存储配置时，跨多级升级的排障成本远高于分步升级。
Q：APM 一定要配 ClickHouse 吗？
是。遥测数据源在 8.0 中指定为 ClickHouse，且作为遥测数据源要求 26.8.17.4 及以上版本。只做主机监控、不上 APM 的环境，可以不引入 ClickHouse。
Q：ClickHouse 能替代 MySQL 吗？
不能。ClickHouse 在 8.0 中承担的是历史值存储与遥测数据源，配置数据仍需要 MySQL、MariaDB 或 PostgreSQL。它是”加一层”，不是”换掉”。
Q：移动端现在就能用吗？
8.0 已经提供了 App 对应的后端能力，包括 Devices 管理、Push notification 媒体类型和 bridge adapter。App 本身的可用状态与上架情况以官方发布为准，部署时先把 BridgeAdapterURL 与 EnableMobileDevices 规划好。
HelloPlease log in