第2章 监控系统与告警源：三大主流系统与数据采集原理

聊告警响应流程，绕不开数据从哪里来。你想想看，告警的本质是对监控数据的判断。如果底层的监控系统都搭错了，后面的流程再漂亮也是白搭。我个人习惯，先把数据采集这层搞清楚，再往下走流程设计。

这一章我们聚焦三个主流玩家：Prometheus、Zabbix、Datadog。它们代表了不同的架构思路和运维哲学。

2.1 数据采集的两种哲学：Pull 与 Push

先说个基本概念。监控系统怎么拿到业务数据？主要有两种思路。

• Pull 模式（拉取）：监控中心主动去各个目标机器上抓数据。典型代表是 Prometheus。
• Push 模式（推送）：目标机器上的 Agent 主动把数据发到监控中心。典型代表是 Datadog。
• 混合模式：既支持拉取也支持推送，适应不同场景。Zabbix 就是典型的代表。

2.2 Prometheus：拉取模式的神

Prometheus 现在基本是云原生监控的事实标准。它的理念很纯粹：你暴露 Metrics 端点，我来拉。数据模型是 多维时序，每一条数据由指标名 + 标签唯一标识。

采集原理：服务发现 + 主动抓取

Prometheus Server 定期从配置好的 targets 中抓取 Metrics 数据。这个 targets 列表可以静态配置，也可以通过服务发现动态获取——Kubernetes 的 Pod、Service 都能自动发现。

# prometheus.yml 采集配置片段
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

  - job_name: 'api-service'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        regex: api
        action: keep

嗯，这里有个关键点。Prometheus 的抓取间隔决定了数据粒度。默认 15s，你可以调成 5s，但要注意存储压力和网络开销。我在项目中遇到过，有人对所有服务都用 5s 抓取，结果存储直接被打爆。

告警规则：基于 PromQL 的表达式

告警写在 YAML 文件里，通过 PromQL 查询语句定义阈值条件。举个例子：

groups:
- name: node-alert
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Instance {{ $labels.instance }} CPU 使用率超过 80%"

这里的 `for: 2m` 是 Prometheus 特有的 Pending 状态机制——持续超过阈值 2 分钟才真正发出告警，避免抖动误报。我个人觉得这个设计非常优雅。

2.3 Zabbix：老牌选手的全面监控

Zabbix 是传统 IT 监控领域的老大哥，尤其在服务器、网络设备、数据库监控方面极其成熟。它的数据传输更灵活。

采集方式	说明	典型场景
Zabbix Agent	安装在目标机器上，被动或主动采集 CPU、内存、磁盘等	服务器基础监控（大部分场景）
SNMP Trap	通过 SNMP 协议从网络设备获取数据	交换机、路由器、防火墙
IPMI	通过 BMC 接口获取硬件状态	服务器硬件：风扇、温度、电源
JMX	通过 Java 管理扩展获取 JVM 指标	Java 应用监控（Tomcat、Spring Boot）
自定义脚本	Zabbix 可以执行外部脚本获取数据	定制场景，比如检查证书到期、业务日志

数据模型：Items + Triggers

Zabbix 里每个监控项叫 Item，每个 Item 定义一个 Key。比如 `system.cpu.load[all,avg1]`。触发告警靠 Trigger，表达式基于 Item 的历史值。

// Zabbix 触发器表达式举例
// 当 CPU 负载在最后 5 分钟平均值大于 5 时触发
{Server:system.cpu.load[all,avg1].avg(5m)} > 5

2.4 Datadog：SaaS 监控的全栈体验

Datadog 是商业 SaaS 监控的标杆。不用自己搭服务器，部署 Agent 就能用。它把 Metrics、Traces、Logs 三合一，非常方便。

Agent 架构：推模式 + 集成平台

Datadog Agent 安装在你的主机或容器里，默认每 15s 采集一次系统指标，通过 HTTPS 推送到 Datadog 云端。最厉害的是它的 集成平台——官方提供 700+ 种服务的开箱即用仪表盘和告警规则。比如你部署了 Nginx，装好 Agent 后就自动监控了连接数、请求速率。

# datadog.yaml 基本配置
: YOUR_
site: datadoghq.com
tags:
  - env:production
  - team:infra

# conf.d/nginx.d/conf.yaml
init_config:
instances:
  - nginx_status_url: http://localhost/nginx_status

告警：Monitor 的灵活性

Datadog 的告警叫 Monitor，图形化配置界面很友好。你还可以用公式组合多个指标、设置异常检测算法自动识别异常。

特性	Prometheus	Zabbix	Datadog
部署方式	自托管	自托管	SaaS（云端）
采集模式	Pull	Push / Pull	Push
数据模型	多维时序（Label）	Item + Key	Metrics + Tags
告警引擎	PromQL + Alertmanager	Trigger 表达式	Monitor + 异常检测
学习成本	中等（需要学 PromQL）	中等（需要理解 Item 体系）	低（图形化配置）
容器支持	原生极好	一般	极好

2.5 告警数据采集的整体逻辑

不管用哪个系统，底层原理是一样的。我画个流程图帮你理解：

1. 数据产生：应用或系统产生 Metrics、Logs、Events。
2. 数据采集：通过 Agent 或直接暴露端点，让监控系统拿到数据。
3. 数据存储：时序数据库（TSDB）、日志系统。
4. 告警评估：监控引擎周期性查询数据，比对告警规则。
5. 告警通知：触发规则后发出通知（邮件、钉钉、Slack）。

这三者选哪个？我的建议很直接：

• 团队以 Kubernetes 为主 → Prometheus 是唯一认真考虑的选项。社区支持、Operator 都成熟。
• 传统正版服务器+网络设备 → Zabbix 稳如老狗，模板丰富，批量管理方便。
• 团队小、不想自己运维监控系统 → Datadog 省心省力，但控制好预算。