6.1 开源监控工具

6.1 开源监控工具

本节摘要：监控工具的开源生态里，Prometheus + Grafana + Alertmanager 是当下最主流的一套，传统派还有 Zabbix、Nagios 各自坐镇。本节把这几个家伙的分工、起步门槛、适合场景逐一比清楚，给一套从 Prometheus 起步的采集—存—看—警接线快速上手，并用一张决策图帮你对号入座。

你该从哪个工具起步

先给结论：只要你不是有必须在 Zabbix 上延续的存量，优先从 Prometheus 生态起步。 它抓准了现代监控的核心——Pull 模型 + 时序 + 丰富的生态插件，是云原生时代的默认答案。不是说 Zabbix 不好，它在传统 IT 监控、网络设备监控上很成熟，但它的开发范式是"传统监控体系"，对于要上云的团队，Prometheus 生态的学习曲线和社区资源都更平滑。

Prometheus + Grafana + Alertmanager：铁三角

这套组合三件套各管一段，把"采集-存储-视觉-告警"补齐了。

Prometheus：核心监控服务器。用 Pull 模式去各目标拉指标，内部带一套时序存储，还有一套强大的查询语言 PromQL（画曲线、做计算、配告警表达式都靠它）。它是这套体系的"数据中心"。

Grafana：可视化看板。不负责采集数据，只负责把 Prometheus（以及其它数据源）的数据画成图表和看板。第二章讲的仪表盘设计，就是靠它在 Grafana 里落地。

Alertmanager：告警管理。Prometheus 里配好"何时触发告警"的表达式（rules），触发了推给 Alertmanager；Alertmanager 管收敛、抑制、静默，并按规则通知到各渠道（邮件、IM、Webhook）。第四章讲的噪声治理，就是编排 Alertmanager。

一句话接线：Exporter 采指标 → Prometheus 存与查 → Grafana 画给看 → Prometheus rules + Alertmanager 负责叫醒。 三件套配合，胶水正是它们都懂 Prometheus 的数据格式，所以生态里的 Exporter（node_exporter、mysqld_exporter 无数个）即插即用。

node_exporter  →  抓     →  Prometheus  →  查询     →  Grafana
 mysqld_exporter →            │  rules 触发告警
                        └→  Alertmanager → 邮件/IM/Webhook
​

传统派：Zabbix 与 Nagios

Zabbix：老牌的全面监控平台，写明了"主机-指标-图形-告警"的一体化。它对传统 IT 环境（网络设备、服务器、SNMP 协议）支持极好，收拢式的架构适合"一个平台管全部"的运维。弱在哪？它的时序能力和云原生/容器生态远不如 Prometheus,二次开发成本较高。

Nagios：更古老，以插件机制闻名，非常灵活但要高度手配。它是"我愿意为自定义付代价，别帮我做太多事"的那类工具。如今更多团队把它当历史遗留维护，新项目很少首选。

一张图给你对号入座

从零起步的一贯接法

给一支刚起步的团队一个可照抄的最小接线：一台机器上跑 node_exporter（采系统指标）+ Prometheus（scrape + 存储）+ Grafana（可视化 node exporter 面板），三个进程就能有一块"基础设施健康看板"。再配一条 Prometheus rule："node_filesystem_avail_bytes 小于总量 10% 且持续 5 分钟"→ Alertmanager → 邮件/群通知。这条最快三十天就能让团队看到"指标 > 看板 > 告警"整套环是怎么转的，后面再逐步加 mysqld_exporter、应用指标、链路。

我的判断：Prometheus 生态是当下性价比最高的起步点，先跑起来再谈扩展；对既有 Zabbix 的存量别急着推翻,让旧系统和新生态暂时共存,逐步过渡,别为"全面接管"冒大风险。

采现成的 Exporter，还是自己写

Prometheus 生态最省心的地方,是现成的 Exporter 几乎遍地都是:系统用 node_exporter、MySQL 用 mysqld_exporter、Redis 用 redis_exporter、Kafka 用 kafka_exporter,官方都维护好了,直接抓就行。真正的取舍在"官方没有的那种怎么来"——两条路:要么找社区 exporter(注意看维护活跃度、star、issue 有没有人回),要么自己写(官方有 textfile collector 和 client 库,门槛不高)。我的建议是自定义指标优先用 Prometheus 的 client 库让应用直接暴露 /metrics,而不是写一个新 exporter 去抓——后者常常是重复造轮子,还多一个要盯的采集出口。

集群大了,单机 Prometheus 扛不住怎么办

单机 Prometheus 在几台机器、几十个目标以内很从容,但当你上百个目标、几十万时间序列,单机就会开始吃力——查询慢、内存涨。这时候的升级路径有两条：一是用远程存储(VictoriaMetrics、Thanos、Mimir 这类)把长周期数据卸到独立存储,保留 Prometheus 的查询体验;二是分库,按部门或业务拆多套 Prometheus,再上层聚合。别一上来就上大动作——先用工具自带的监控看 Prometheus 自己的资源,到顶了再动,否则纯属提前造复杂度。

本节要点回顾

• 先结论：没存量就优先 Prometheus 生态。
• 铁三角分工：Prometheus 存查、Grafana 视觉、Alertmanager 告警。
• 接线顺序：采集 → 存储 → 看板 → 告警。
• 插件即插即用：生态里 Exporter 海量,都懂 Prometheus 格式。
• Zabbix 适合传统 IT：平台一体化,但云原生弱、二开贵。
• Nagios 高度灵活：但手配成本高,更多是历史遗留。
• 先用起来再扩展：一台机器就能把整套环转起来。

监控的班子定了，下一步配日志。——下一节看 ELK 与 Loki 这条日志路线怎么选、怎么分工。