一、三者定位与角色

工具	类型	核心职责	是否自带可视化	是否自带告警
Zabbix	一体化监控系统	数据采集 + 存储 + 告警 + 可视化	✅ 内置 Web UI	✅ 内置告警引擎
Prometheus	云原生监控平台	时间序列数据采集 + 存储 + 查询 + 告警规则	❌（需 Grafana）	⚠️ 规则定义在 Prometheus，但通知由 Alertmanager 处理
Grafana	可视化分析平台	统一展示多数据源（Prometheus、Zabbix、MySQL 等）	✅ 强大图表/仪表盘	❌（仅支持简单告警，生产用 Alertmanager 或 Zabbix）

💡 Grafana 不是监控工具，而是“监控数据的显示器”。

---

二、核心特性对比

维度	Zabbix	Prometheus + Grafana
架构	Server-Agent / SNMP / IPMI	Pull 模型 + Exporter + TSDB
数据模型	主机/模板/监控项（Item）	时间序列：metric_name{label1="a", label2="b"}
采集方式	Push（Agent 主动上报）或 Polling	Pull（主动从 /metrics 拉取）
存储	关系型数据库（MySQL/PG），需定期清理历史数据	自研 TSDB（本地），支持远程存储（Thanos, Cortex）
服务发现	网络自动发现、低级别注册	动态发现（K8s、Consul、文件、DNS 等）
查询语言	简单表达式（如 last(/host/cpu.util)）	PromQL（强大函数：rate(), increase(), topk()）
扩展性	通过模板、自定义脚本	通过 Exporter（Node、MySQL、Blackbox 等）
适用环境	物理机、VM、传统 IT	容器、微服务、Kubernetes、动态云环境

---

三、关键概念速记

✅ Zabbix 核心组件

• Host：被监控对象（服务器、网络设备等）
• Template：模板，包含 Items、Triggers、Graphs，可复用
• Item：一个监控指标（如 CPU 使用率、磁盘 IO）
• Trigger：触发条件（如 last(/host/cpu.util) > 90）
• Action：Trigger 触发后执行的操作（发邮件、执行脚本、创建工单）
• Agent：部署在被监控端，主动采集数据

✅ Prometheus 核心组件

• Metric：格式如 http_requests_total{method="POST", status="200"}
• Exporter：将第三方指标暴露为 HTTP /metrics（如 Node Exporter）
• PromQL：查询语言（例：rate(http_requests_total[5m]) > 100）
• Job / Target：配置中的采集任务和目标地址
• Alert Rule：在 prometheus.yml 或单独文件中定义
• Alertmanager：处理告警分组、抑制、路由、通知（邮件/钉钉/Webhook）

✅ Grafana 核心能力

• Data Source：支持 Prometheus、Zabbix、Loki、MySQL、InfluxDB 等
• Dashboard：可视化面板（折线图、热力图、状态图等）
• Variables：动态变量（如 $host 切换主机）
• Alerting（基础）：可基于查询结果触发通知（但复杂场景仍推荐 Alertmanager）

---

四、典型架构组合

🎯 场景 1：传统企业监控 → Zabbix 全栈

text

1[Zabbix Agent] → [Zabbix Server] → [Web UI + DB]
2                     ↓
3               [Email/WeChat Alert]

• ✅ 优点：开箱即用、告警闭环、适合静态环境
• ❌ 缺点：扩展性弱、不擅长容器监控

🎯 场景 2：云原生监控 → Prometheus + Alertmanager + Grafana

text

1[Node Exporter]     [App /metrics]
2        ↓                ↓
3   [Prometheus] ← (Service Discovery)
4        ↓ (Alert Rules)
5[Alertmanager] → Email/DingTalk
6        ↓
7    [Grafana] ← (Query Prometheus)

• ✅ 优点：动态发现、强大 PromQL、生态丰富
• ❌ 缺点：需组合多个组件，学习曲线陡

🎯 场景 3：混合监控 → Zabbix + Grafana

• 用 Zabbix 采集传统服务器数据；
• 在 Grafana 中添加 Zabbix 作为 Data Source（通过插件）；
• 统一在 Grafana 展示 Zabbix 和 Prometheus 数据。

---

五、告警机制对比

项目	Zabbix	Prometheus + Alertmanager
告警定义	Trigger（基于 Item）	Alert Rule（基于 PromQL）
通知渠道	内置（邮件、微信、短信脚本）	Alertmanager 支持 Webhook、邮件、PagerDuty、钉钉等
高级功能	基础分组、升级	分组（group_by）、抑制（inhibit）、静默（silence）
调试	Web UI 直接查看 Trigger 状态	http://prometheus:9090/alerts 查看活跃告警

---

六、如何选择？

需求	推荐方案
监控几十台物理机/VM，无容器	✅ Zabbix
Kubernetes + 微服务 + 动态扩缩容	✅ Prometheus + Grafana + Alertmanager
需要统一视图，同时有传统和云原生系统	✅ Zabbix + Prometheus + Grafana（Grafana 融合展示）
快速上线，运维人力有限	✅ Zabbix（All-in-One）
需要复杂指标计算、预测、百分位	✅ Prometheus（PromQL 强大）

---

七、高频面试问题

1. Prometheus 为什么用 Pull 而不是 Push？
   → 更可靠（避免客户端故障丢数据），便于服务发现，符合云原生理念。

2. Zabbix 和 Prometheus 能共存吗？
   → 可以！Grafana 可同时接入两者，Zabbix 监控基础设施，Prometheus 监控应用。

3. Grafana 能替代 Prometheus 吗？
   → 不能！Grafana 只是可视化工具，不采集、不存储数据。

4. 如何监控 Prometheus 本身？
   → Prometheus 提供 /metrics，可用另一个 Prometheus 或 Blackbox Exporter 监控。