Zabbix 最佳实践

内容覆盖：架构、安装、性能、监控规范、告警、数据存储、Proxy、Agent、模板、触发器、维护等所有核心最佳实践。

1. 架构规划最佳实践

1.1 使用 Proxy（强烈推荐）

适用：

多机房
设备数量 ≥ 300
网络复杂、跨地域
需要降低 Zabbix Server 压力

Proxy Benefits：

减少数据库压力
减轻 Server 采集压力
断网自动缓存数据
分布式架构更健壮

2. 数据库最佳实践（最关键部分）

Zabbix = 重数据库应用，90% 的性能问题都源于 DB。

2.1 使用 PostgreSQL（优于 MySQL）

原因：

写入性能更强
原生支持分区
TimescaleDB 插件极佳

2.2 使用 SSD（数据库必须在 SSD）

提升：

写入 TPS
历史数据查询
Housekeeper 速度

2.3 开启 TimescaleDB（推荐）

历史表自动分区 + 压缩，提升 10 倍性能。

2.4 最佳 PostgreSQL 参数

shared_buffers = 25% 内存
work_mem = 32MB
maintenance_work_mem = 256MB
wal_buffers = 16MB
max_connections = 500
effective_cache_size = 50% 内存

2.5 Housekeeping 建议关闭自动

HousekeepingFrequency=0

使用 TimescaleDB 或 cron 清理更高效。

3. Zabbix Server 最佳实践

3.1 StartPollers 调优

核心并发配置：

StartPollers=50
StartIPMIPollers=10
StartPollersUnreachable=10
StartPingers=10
StartDiscoverers=10
StartHTTPPollers=20

3.2 本地安装 Server+Frontend

减少网络延迟。

3.3 高可用建议

使用 Pacemaker/Keepalived 做 Server HA
PostgreSQL 做主从复制（流复制）

4. Zabbix Proxy 最佳实践

4.1 每个区域部署 Proxy

提升稳定性。

4.2 Proxy 使用 SQLite（最多 5000 主机）

更轻量；>5000 主机建议 PostgreSQL Proxy。

4.3 Proxy 缓存磁盘使用 SSD

避免断网时写入堵塞。

5. Zabbix Agent / Agent2 最佳实践

5.1 使用 Zabbix Agent2（强烈推荐）

优点：

性能更好
插件更丰富（MySQL、Redis、Nginx）
原生支持 Go 插件扩展

5.2 使用主动模式 + TLS

主动模式：

无需防火墙开 inbound 端口
更适合容器、多云环境

启用加密：

TLSConnect=psk
TLSAccept=psk

5.3 自定义监控建议使用 UserParameter

最佳实践：

JSON 输出
一次脚本返回多指标（减少调用开销）

6. 模板最佳实践（非常关键）

6.1 强烈建议使用官方模板，而不是自建

官方模板特点：

自动发现（LLD）
已含上百个监控项
已优化告警阈值
CPU/内存/IO 都有图表

官方模板：

Template OS Linux
Template OS Windows
Template DB MySQL
Template DB PostgreSQL
Template App Nginx
Template App Redis

6.2 自建模板规范

命名规范：

Template App XXX {CompanyName}
Template VM KVM {CompanyName}

模板内必须包含：

监控项（Item）
触发器（Trigger）
LLD（自动发现）
Item Prototype（自动创建）
Graph（图表）

7. Item 最佳实践

7.1 监控周期不要太短

7.2 避免外部脚本（太慢）

尽量使用：

Zabbix agent 内置 key
agent2 插件
SNMP / HTTP Agent

7.3 使用 Preprocessing

减少触发器误报：

JSONPath
正则过滤
数值过滤（discard below）

8. Trigger 最佳实践

8.1 设置迟滞（hysteresis）

避免频繁上下波动告警。

示例：

{host:vfs.fs.size[/,pfree].last()}<20
{host:vfs.fs.size[/,pfree].last()}<25

8.2 使用趋势值减少波动

avg(5m)
min(10m)

8.3 禁止使用过于敏感的阈值

内存低到 10% 不代表不好，大量缓存是正常的。

推荐阈值：

CPU load > (核心数 * 1.5)
内存可用 <20%
磁盘使用率 >85%
inode 使用 >90%
TCP CLOSE_WAIT > 100

9. 告警最佳实践（非常关键）

9.1 使用 Webhook（推荐）

优于邮件：

企业微信 WebHook
钉钉机器人
飞书机器人
Telegram

9.2 告警分级

级别：

Disaster：必须立即处理（服务不可用）
High：严重（磁盘 >95%）
Average：一般
Warning：轻微

9.3 告警收敛（减少噪音）

同一事件不连续发送
禁止重复通知
使用维护窗口 suppress

10. 数据存储最佳实践

10.1 数据保留周期

历史数据：30 天
趋势数据：365 天
事件数据：90 天

10.2 开启 TimescaleDB 压缩

减少 70% 存储空间。

11. 安全最佳实践

11.1 HTTPS 访问 Frontend

Nginx + Let’s Encrypt。

11.2 TLS 保护 Agent 通信

避免中间人攻击。

11.3 API Token 最小权限

不要给超级管理员 token。

12. 可观测性最佳实践

组合监控：

Zabbix + Prometheus（时序数据）
Zabbix + Grafana （展示）
Zabbix + ELK （日志）
Zabbix + Jaeger（链路追踪）

13. 维护最佳实践

13.1 定期清理无效主机

自动发现删除停用设备。

13.2 定期检查 LLD 是否过多

过多 LLD -> 数据库存储暴涨。

13.3 每周查看 top 20 监控项耗时

优化慢脚本 / SNMP 延迟。

13.4 定期备份

PostgreSQL 全备
Zabbix 配置备份（SQL dump + /etc/zabbix）

总结：企业级 Zabbix 最佳实践（15 条必做）

使用 Proxy 按地域/机房分布。
数据库必须使用 PostgreSQL + SSD。
使用 TimescaleDB 分区与压缩。
使用 Agent2 + 主动模式 + TLS。
尽量使用官方模板而不是自建。
监控周期最短 30s，不要太密。
使用趋势值与 hysteresis 避免震荡。
告警采用 Webhook，分级管理。
历史数据仅保留 30 天，趋势保留 1 年。
禁止使用大量外部脚本监控。
Proxy 使用 SSD 缓存。
禁止自动 Housekeeping。
使用 Grafana 做可视化更美观。
Zabbix Server 需要调高 poller 线程。
定期清理无效主机、失效 LLD、垃圾事件。