Zabbix FAQ
内容：基础、核心原理、实战场景、故障排查、架构设计。
- Zabbix Server：核心服务，负责数据收集、触发器评估、事件处理。
- Zabbix Agent/Agent2：采集系统和应用数据。
- Zabbix Proxy：分布式采集，缓冲、转发数据。
- Database：存储监控数据（历史、趋势、事件）。
- Frontend：Web UI。
| 项目 | Agent | Agent2（推荐） |
|---|---|---|
| 实现语言 | C | Go |
| 性能 | 中 | 更好 |
| 插件 | 不支持 | 支持（MySQL、Redis 等） |
| 扩展性 | 差 | 强 |
| JSON处理 | 弱 | 强 |
总结：生产优先使用 Agent2。
- Item：监控项（CPU Load / Free Mem）
- Trigger：条件判断（当 CPU load > 5）
- Action：触发动作（邮件/微信/钉钉告警）
它们的关系：
Item 收集数据 -> Trigger 判断 -> Action 告警
被动模式（被 Server 轮询）：
- Server -> Agent 请求
- 不适用于防火墙复杂环境
主动模式（Agent 主动发送数据）：
- Agent -> Server
- 适合云主机、容器、跨机房
最佳实践：使用主动模式 + TLS
自动发现机制，用于自动监控：
- 磁盘
- 网卡
- Docker 容器
- 数据库表
- K8S Pod
因为所有数据都写入 DB，包括：
- 历史指标（history）
- 趋势数据（trends）
- 事件（events）
- 通知记录（alerts）
结论：数据库性能决定 Zabbix 性能。
流程：
Agent -> Server poller -> Preprocessing -> DB -> Trigger -> Event -> Action
Server 使用 Poller 线程并发采集，类型包括：
- poller
- http poller
- pinger
- discoverer
- unreachable poller
Proxy 作用：
- 采集并缓存数据
- 减轻 Server 压力
- 网络断开自动缓存（保证数据不丢）
- 支持分布式监控
适用：
- 多机房
- 多地域
- 设备数量 > 500
- 内网隔离场景
| 类型 | 保存的数据 | 用途 |
|---|---|---|
| history | 原始监控数据 | 精细分析（秒级） |
| trends | 1h 的 min/max/avg | 长期视图（天/月/年） |
大量数据时必须依赖 trends，否则数据库会炸。
方法：
- 使用趋势值（avg(5m)）
- 触发器加 hysteresis（迟滞）
- 监控周期不要太短（>30s）
- 使用 preprocessing 过滤噪声
方法：
- 使用 Zabbix Agent2 插件（最推荐）
- SNMP（设备型）
- 用户参数 UserParameter
- 外部脚本（不推荐）
- HTTP agent（HTTP API）
- system.cpu.load[]
- vm.memory.size[]
- vfs.fs.size[]
- net.if.in[]
- proc.num[]
- log[]
- agent.ping
- system.uptime
使用：
- log[]
- logrt[] (带日志滚动)
可以结合：
- 正则匹配
- LLD
- 多指标聚合
使用 UserParameter：
zabbix_agent2.conf：
UserParameter=redis.status[*],/usr/local/bin/redis_check.sh $1
脚本输出必须是纯数值或 JSON。
- 使用静默期（Maintenance）
- 告警分级
- 迟滞（hysteresis）
- 使用增量告警（PROBLEM -> OK）
- Action 中限制重复通知
数据库最关键：
- PostgreSQL + SSD
- 开启 TimescaleDB
- 调整 DB 参数（shared_buffers 等）
Server 调优：
- 增加 poller 数量
- 增加 preprocessing worker
- Proxy 分担压力
Agent 调优：
- 使用 Agent2
- 使用主动模式
Housekeeper 是清理历史数据的任务。
自动模式性能差，会导致：
- 数据库卡顿
- CPU 飙高
- 监控延迟加大
最佳实践：关闭自动，改用 TimescaleDB 或手动清理。
TimescaleDB 是基于 PostgreSQL 的时间序列扩展，提供：
- 自动分区（hypertable）
- 数据压缩
- 快速查询
对 Zabbix 来说：
- 数据量大
- 时间序列结构非常适配
查看 /var/log/zabbix/zabbix_server.log：
如果出现：
poller processes more busy than 75%
说明 poller 数量不足，需要调大：
StartPollers=50
StartHTTPPollers=10
StartDiscoverers=10
StartPingers=10
<5000 主机：SQLite（默认）
5000 主机：PostgreSQL
理由：
- SQLite 在大量数据写入下性能不足
- SQLite 不支持 TimescaleDB
可能原因：
- key 写错
- agent 不支持这个 key
- 权限不足
- 没有打开 UserParameter
- 命令输出不是数字
排查命令：
zabbix_agent2 -t system.cpu.load
说明表单格式不正确，例如：
- 触发器表达式错误
- 时间格式错误
- key 格式错误
检查：
- 格式是否符合要求
- 使用 “Check now” 测试 item
排查：
- Media 配置是否正确
- 外部脚本是否有执行权限
- 是否被 Action 条件过滤
- Server 是否能访问外部网络
- 查看日志 /var/log/zabbix_server.log
检查：
telnet server 10051
检查 TLS 配置是否一致。
排查：
- 用户名密码
- 权限（建议创建只读 user）
- MySQL socket 路径
- Agent2 是否支持 MySQL 插件
推荐：
FrontEnd x 2 (HA)
PostgreSQL 主从 + TimescaleDB
Zabbix Server x 2 (HA)
Proxy A（机房A）
Proxy B（机房B）
Proxy C（云）
Agent2 主动模式
Grafana 展示
- Server + Frontend + DB 三层 HA
- Proxy 缓冲数据
- 分区表/TimescaleDB
- 定期备份 DB
- 使用 Pacemaker / Keepalived 实现 Server HA
- Nginx + SSL 保护前端
常见坑：
- 不使用 Proxy 导致 Server 卡死
- 使用 MySQL 而非 PostgreSQL
- 没有开启 TimescaleDB
- 用外部脚本过多导致超时
- LLD 规则数量太多，生成上万监控项
- 告警配置不分级，消息爆炸
- Housekeeper 自动清理导致数据库拥堵