第4章 告警源与采集：常见告警源归纳总结
告警源，说白了就是你的“监控探头”。
它们负责从各个系统、服务、硬件里捞数据，然后转成告警事件。我做了这么多年SRE，发现一个规律：告警源选不对，后面整个流程都是白搭。你想想，数据都不准，告警怎么可能靠谱？
4.1 告警源的三大流派
现在市面上常见的告警源，我归纳下来就三类：
- 开源通用型 —— Prometheus、Zabbix、Nagios 这些。灵活，但坑也多。
- 云厂商原生型 —— 阿里云监控、腾讯云监控、AWS CloudWatch 等。省心，但容易被绑定。
- 商业/自研型 —— Datadog、Splunk、自研采集器。钱到位，事儿就少。
咱们这章重点聊 Prometheus、Zabbix 和云监控。为什么？因为这三者覆盖了 80% 以上的场景。我个人经验里，中小公司用 Prometheus 居多，传统企业偏爱 Zabbix，上云的公司基本离不开云监控。
4.2 Prometheus —— 云原生时代的标配
Prometheus 是 CNCF 毕业项目。它的核心玩法是“拉”（Pull）—— 主动去抓取目标暴露的指标。
我刚开始接触时觉得奇怪，为什么不是推（Push）？后来做了一次告警延迟排查，才发现拉模式的好处：
- 容易控制采集频率，避免被突增的推送压垮。
- 自带服务发现，K8s 里 pod 扩缩容后自动调整。
来看一个最简单的 Prometheus 抓取配置：
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']这个配置每 15 秒抓一次 localhost:9100 的机器指标。嗯，这里要注意：evaluation_interval 决定了告警规则计算的频率，我建议跟 scrape_interval 设成一样，不然容易出“数据还没到，告警却先触发了”的乌龙。
amtool 验证路由逻辑。
4.3 Zabbix —— 老牌重型武器
Zabbix 走的是“推拉结合”路线。Agent 装到被监控机器上，主动把数据推给 Server，或者 Server 主动去拉。它的强项在网络设备、传统数据库、硬件监控上。
我记得有一次给一个银行客户做监控，他们要求必须能监控 IBM 小型机的硬件状态。Prometheus 生态里没现成的 exporter，反而 Zabbix 有现成的 SNMP 模板，几分钟就搞定了。Zabbix 的模板市场确实丰富。
但 Zabbix 也有痛点：
- 配置复杂，阀值靠手动调，容易产生“告警风暴”。
- 告警去重能力弱，同一个故障可能重复发几十次短信。
我曾经在一个日活 500 万的项目里，接手过一套 Zabbix 告警系统。每次发布后，告警就在群里刷屏。后来我加了抑制规则（trigger dependencies），才把误报率降下来。
4.4 云监控 —— 开箱即用的妥协
云厂商提供的监控服务（阿里云云监控、腾讯云云监控、AWS CloudWatch），最大的好处是**不用自己部署采集器**。你买了云产品，指标就自动上报了。
但云监控的局限性也很明显：
- 只能监控云资源，不能监控自建机房。
- 告警策略灵活性差，比如自定义聚合、多条件组合往往不支持。
- 数据保留时间短，一般只存 30 天，想查半年前的指标得付费。
我建议的做法是：云资源用云监控做第一道防线，但核心业务指标同时通过 Prometheus 再采集一份，做双轨保障。下面是一个简单的对比：
| 对比维度 | Prometheus | Zabbix | 云监控 |
|---|---|---|---|
| 部署复杂度 | 中等 | 高 | 低（无需部署） |
| 采集模式 | Pull为主 | Push+Pull | 自动推送 |
| 扩展性 | 强（联邦） | 中（proxy） | 依赖云厂商配额 |
| 告警能力 | 强（Alertmanager） | 中（模板缺灵活） | 弱（规则简单） |
| 适用场景 | 云原生、微服务 | 传统基础设施 | 云上全托管 |
4.5 常见告警源采集架构总览
为了让各位有个直观感受，我用一张图把三种告警源的采集链路画出来。你品一品，它们的数据是怎么流动的：
4.6 选型建议与避坑指南
选告警源，我总结了三条原则：
- 先看基础设施 —— 如果全是虚拟机、物理机、网络设备，Zabbix 更顺手。如果全是 K8s、微服务，Prometheus 是亲爹。
- 再看告警量级 —— 每日百万级别告警？Zabbix 的数据库撑不住，Prometheus 用联邦 + 集群打底，或者直接上云监控。
- 最后看运维能力 —— 有专职 SRE 团队？用 Prometheus。只有一个运维兼任？云监控 + 告警短信，最简单。
另外，不管选哪种，**数据采集的可靠性**是底线。我个人的习惯是：
- 关键采集链路配双活（比如两台 Prometheus 同时 scrape）。
- 写一个简单的健康检查脚本，监控采集器本身是否在工作。
- 告警源的日志必须全量留存，方便事后复盘。
嗯，这一章就聊到这儿。记住：告警源没有最好的，只有最合适的。多练、多踩坑，慢慢就有感觉了。