Zabbix和Prometheus是主流开源监控系统,Zabbix适用于传统环境、强调图形化配置,Prometheus适配云原生、依赖Pull模型与PromQL;二者告警机制不同,Zabbix通过触发器→动作→媒介→用户链路实现,Prometheus则由Prometheus生成告警、Alertmanager负责路由与通知;实际中可通过HTTP Agent、zabbix_exporter或webhook实现联动,并用inhibit_rules降噪。
Zabbix 和 Prometheus 是目前最主流的两类开源监控报警系统,各自适用不同场景:Zabbix 更适合传统物理/虚拟机环境、强调开箱即用和图形化配置;Prometheus 则更契合云原生、微服务架构,依赖 Pull 模型与强大查询语言(PromQL)。
Zabbix 的告警流程是:触发器(Trigger)→ 动作(Action)→ 媒介(Media)→ 用户(User)。配置时需逐层打通:
last(/Linux Server/system.cpu.util[,idle]) 表示 CPU 空闲率低于 10% 持续 5 分钟(默认评估周期)即触发;建议启用“严重性”分级,便于后续动作过滤。
“触发器严重程度 = 高”或“触发器名称包含 CPU”,操作步骤中勾选“发送消息”,并指定“发送给用户”和“仅发送给”指定用户组。Prometheus 本身只负责生成告警事件,真正的分组、抑制、路由和通知由独立组件 Alertmanager 完成。二者必须协同工作:
groups:
- name: container-alerts
rules:
- alert: HighContainerMemoryUsage
expr: (container_memory_usage_bytes{image!=""} / container_spec_memory_limit_bytes{image!=""}) > 0.9
for: 3m
labels:
severity: warning
annotations:
summary: "High memory usage on {{ $labels.container }}"
rule_files: 下添加路径,如 - "rules/alert.rules.yml";重启 Prometheus 后可在 Web UI 的 “Alerts” 页面查看激活状态。alertmanager.yml,定义全局接收人(如 email_configs 或 webhook_configs),并在 route 中按标签(如 severity)分流。例如将 severity: critical 的告警推送到企业微信,而 warning 级别仅发邮件。实际生产中常需混合使用——比如用 Zabbix 监控硬件、网络设备,Prometheus 监控 Kubernetes 集群。两者可通过以下方式互补:
http://prometheus:9090/api/v1/query?query=up),解析 JSON 响应提取指标值,实现跨系统状态拉取。zabbix_exporter 将 Zabbix 数据暴露为 Prometheus 可采集的 metrics;或使用 zabbix-webhook 将 Zabbix 动作转为 HTTP POST 发送给 Alertmanager 的 webhook 接收器(需 Alertmanager 开启 --web.enable-admin-api 并配置 receiver 类型为 webhook)。inhibit_rules,例如当主机宕机(Zabbix 告警)时,自动抑制其上所有容器相关的 Prometheus 告警,避免告警风暴。告警配置后务必验证端到端链路是否通畅:
/var/log/zabbix/zabbix_server.log 是否有 “sent mail to” 或 “executed script” 日志。http://alertmanager:9093/#/alerts 查看告警列表状态(firing / inactive);用 curl -XPOST http://alertmanager:9093/api/v1/alerts 手动注入测试告警 JSON;检查 Alertmanager 日志中是否有 “Notify succeeded” 或 “Failed to notify”。