1.1 触发器核心概念#

• 告警级别：Zabbix 将严重程度分为 6 级：未分类（Not classified）、信息（Information）、警告（Warning）、一般严重（Average）、严重（High）、灾难（Disaster）。建议在企业中明确分级，例如仅“严重”和“灾难”级别才触发半夜电话呼叫。
• 状态流转：触发器只有两个基础状态：OK 和 PROBLEM。当指标在临界值附近反复横跳时，触发器状态会疯狂切换，这就是所谓的告警闪烁（Flapping）。

1.2 表达式语法完全手册#

Zabbix 触发器表达式的通用结构为：函数(/主机/键值, 参数) 运算符 常量

1
# 组合报警：CPU 负载过高 且 内存剩余不足 20%
2
last(/web01/system.cpu.load[all,avg1]) > 5 and last(/web01/vm.memory.size[pavailable]) < 20

1.3 告警防抖：滞回（Hysteresis）机制#

为了防止告警在阈值附近反复触发（告警风暴），Zabbix 提供了**恢复表达式（Recovery expression）**功能。

场景：CPU 超过 90% 报警，低于 80% 才恢复。

• 问题表达式：avg(/web01/system.cpu.util, 5m) > 90
• 恢复表达式：avg(/web01/system.cpu.util, 5m) < 80

依赖触发器（Dependencies）

如果交换机宕机，其下挂的 100 台服务器会瞬间触发“Agent 无法连接”的告警，造成告警风暴。 解决方案：将服务器的 Ping 触发器“依赖”于交换机的 Ping 触发器。一旦交换机触发告警，Zabbix 会自动抑制其下属所有服务器的网络告警，实现精准定位。

2.1 动作体系架构#

完整的动作配置包含三个核心部分：

1. 条件（Conditions）：例如“仅当主机组为 Database 且告警级别 >= 严重 时”。
2. 操作（Operations）：问题发生时执行（如发送微信消息给 DBA 组）。
3. 恢复操作（Recovery operations）：问题解决时发送恢复通知。

2.2 告警媒介（Media Type）配置：企业微信/钉钉接入#

现代企业极少使用邮件告警，Webhook 集成是绝对主流。以企业微信群机器人为例：

1. 在企微群添加一个机器人，获取 Webhook URL。
2. 在 Zabbix -> 告警媒介类型 -> 创建媒介类型：
   • 类型：Webhook
   • 参数：
     • Message => {ALERT.MESSAGE}
     • URL => https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx
   • 脚本（JavaScript）：

1
var req = new HttpRequest();
2
var params = JSON.parse(value);
3
var payload = {
4
    "msgtype": "markdown",
5
    "markdown": {
6
        "content": params.Message
7
    }
8
};
9
req.addHeader('Content-Type: application/json');
10
var resp = req.post(params.URL, JSON.stringify(payload));
11
return resp;

2.3 告警升级（Escalation）与自愈#

Zabbix 支持按时间轴逐级升级告警（Escalation）：

• Step 1 (第 0 分钟)：执行远程命令，重启 Nginx 服务。
• Step 2 (第 5 分钟)：如果问题未恢复，发送企微告警给一线运维。
• Step 3 (第 30 分钟)：如果问题仍未恢复，发送短信或拨打电话给运维总监。

执行远程命令的权限陷阱

要让 Zabbix Server 远程重启 Agent 上的服务，必须在 Agent 端配置文件中开启 EnableRemoteCommands=1，并且赋予 zabbix 用户免密 sudo 权限，否则命令将执行失败。

3.1 网络自动发现（Network Discovery）#

Server 主动扫描指定的 IP 网段（如 192.168.1.0/24），通过 Ping 或 SNMP 探测存活的主机，一旦发现，自动将其加入 Zabbix 并绑定模板。

• 缺点：轮询扫描网段消耗大量 Server 资源，且对于禁 Ping 的机器无效。

3.2 活跃 Agent 自动注册（Active agent auto-registration）#

强烈推荐的企业级做法！ 配置新机器上线时，Agent 主动向 Server 报到，并携带自己的元数据（如 HostMetadata=Linux-Web-Nginx）。 Server 端配置自动注册动作，匹配到该元数据后，自动将主机加入 Web-Servers 组并关联 Nginx 模板。真正实现云主机的“秒级上线纳管”。

案例 1：MySQL 数据库深度监控#

除了存活监控，DBA 更关心连接数与慢查询。推荐使用 Zabbix 官方的 MySQL by Zabbix agent 模板。

前置授权配置：

1
CREATE USER 'zbx_monitor'@'%' IDENTIFIED BY 'complex_password';
2
GRANT REPLICATION CLIENT,PROCESS,SHOW DATABASES,SHOW VIEW ON *.* TO 'zbx_monitor'@'%';

配置文件下发： 将连接凭证写入 Agent 端的 .my.cnf，防止密码泄露。

案例 2：Nginx Web 服务监控#

基于 Nginx 自带的 stub_status 模块进行数据拉取。

第一步：Nginx 开启状态页

1
server {
2
    listen 80;
3
    location /basic_status {
4
        stub_status on;
5
        allow 127.0.0.1;
6
        deny all;
7
    }
8
}

第二步：关联模板 在 Zabbix 中为该主机链接 Nginx by Zabbix agent 模板，系统会自动发现并绘制出 Active connections、Requests per second (QPS) 等核心报表。

案例 3：业务接口可用性监控#

对于核心电商接口（如 https://api.example.com/health），可使用 Zabbix 的 Web 场景监控（Web Scenarios）。

• 步骤：配置请求 URL -> 设定超时时间 -> 要求响应状态码为 200 -> 校验返回的 JSON 体中必须包含字符串 "status":"UP"。
• 配合触发器：last(/host/web.test.fail[API Health Check]) > 0，实现接口宕机秒级告警。

案例 4：日志关键字监控#

排查 Java 应用抛出的 OutOfMemoryError 异常：

1. 监控项类型：Zabbix agent (active)
2. 键值：log[/var/log/app/error.log,"OutOfMemoryError",,,skip]
3. 触发器表达式：last(/host/log[...]) <> 0

日志监控核心参数

键值中的 skip 参数非常关键！它指示 Agent 每次重启后仅从文件末尾开始读取，防止系统重启时将历史旧日志重新拉取一遍导致疯狂误报。

案例 5：Redis 缓存深度监控#

Redis 作为企业核心缓存组件，除了监控存活状态，还需要重点关注内存碎片率、命中率以及慢查询。推荐使用 Zabbix 官方的 Redis by Zabbix agent 2 模板，得益于 Agent 2 原生内置的插件架构，配置变得异常简单。

核心监控指标：

• Keyspace hits/misses：缓存命中率（低于 80% 需要警惕缓存穿透）。
• Memory fragmentation ratio：内存碎片率（大于 1.5 建议排查，或在业务低峰期执行 MEMORY PURGE）。
• Connected clients：并发连接数。

配置方法： 在 Agent 2 的配置文件中（如 /etc/zabbix/zabbix_agent2.d/plugins.d/redis.conf），配置 Redis 的连接凭证：

1
Plugins.Redis.Sessions.WebCache.Uri=tcp://127.0.0.1:6379
2
Plugins.Redis.Sessions.WebCache.Password=your_redis_password

随后在 Zabbix Web 界面为目标主机链接 Redis by Zabbix agent 2 模板，系统即可自动发现所有数据库实例并生成看板。

案例 6：JVM 与 Tomcat 监控实战 (JMX)#

对于 Java 业务，单纯的 CPU 和内存等系统级监控无法反映真实的 GC 情况与线程池状态。Zabbix 提供了 Zabbix Java Gateway 专门用于拉取 JMX 数据。

第一步：Java 应用开启 JMX 暴露 在 Tomcat 或 Spring Boot 的启动脚本中加入 JMX 参数：

1
-Dcom.sun.management.jmxremote \
2
-Dcom.sun.management.jmxremote.port=12345 \
3
-Dcom.sun.management.jmxremote.authenticate=false \
4
-Dcom.sun.management.jmxremote.ssl=false

第二步：Zabbix Server 部署 Java Gateway 在 Server 端安装并启动 Gateway 服务：

1
yum install zabbix-java-gateway -y
2
systemctl enable --now zabbix-java-gateway

修改 Server 配置文件以对接 Gateway：

1
# 指定 Java Gateway 地址与轮询进程数
2
JavaGateway=127.0.0.1
3
JavaGatewayPort=10052
4
StartJavaPollers=5

第三步：关联 JMX 模板 在主机配置界面添加 JMX interfaces 并填入应用端暴露的 12345 端口，关联 Generic Java JMX 模板。重点关注 Heap Memory Usage 与 MarkSweepCompact (Full GC) 次数。

5.1 数据库终极优化：表分区与 TimescaleDB#

Zabbix 最庞大的表是 history 和 trends。使用原生的 MySQL，删除 1 亿条过期数据会导致极高的 IO 负载。 最佳实践：抛弃 MySQL，使用 PostgreSQL + TimescaleDB 插件。它能在底层将历史数据按时间分片，清理过期数据等同于直接 DROP 分区表，耗时从几个小时缩短至毫秒级。

5.2 Server 进程与缓存调优#

观察 Zabbix 的内置监控仪表盘（Zabbix server health），如果发现某种进程经常达到 100% 繁忙，需修改 zabbix_server.conf：

1
# 增加处理被动请求的轮询器
2
StartPollers=100
3

4
# 如果自动发现/注册处理缓慢，增加进程
5
StartDiscoverers=10
6

7
# 增大各级内存缓存（极其重要，视物理机内存而定）
8
CacheSize=2G
9
HistoryCacheSize=512M
10
ValueCacheSize=256M

5.3 突破地域限制：Proxy 分布式代理#

如果企业在阿里云、腾讯云、AWS 都有 VPC，千万不要让所有 Agent 跨公网连接总部的 Server，网络延迟会导致大面积误报。 架构改造：在每个云环境的 VPC 部署一台 Zabbix Proxy。区域内的 Agent 将数据汇报给 Proxy，Proxy 在本地进行数据压缩和缓存后，通过单条 TCP 隧道安全地推送给总部 Server。这不仅极大降低了总部的并发连接数，还具备断网续传功能。

5.4 告警风暴抑制：维护周期与事件关联#

企业在进行应用大版本发版或机房网络割接时，往往会瞬间触发成百上千条“服务不可用”的无效告警。

1. 维护周期（Maintenance） 在变更操作前，务必在 Zabbix 数据收集 -> 维护 中创建维护窗口：

• 可以选择 带数据收集（图表正常绘制，但不触发动作发送告警）或 无数据收集。
• 绑定受影响的主机或主机组，避免一线运维人员在割接时遭遇“夺命连环 Call”。

2. 全局事件关联（Event Correlation） 当某个核心汇聚交换机宕机时，其下挂的几十台服务器必然也会随之报“网络不可达”。通过在 告警 -> 事件关联 中配置规则，Zabbix 能够识别拓扑关系，自动将“业务接口超时”、“数据库断连”等衍生告警抑制，仅向外发送“核心交换机宕机”这一个根因事件，实现精准定界。