📚 课程目录第3章源系统分析（一）

3. 源系统分析（一）

事故响应台账的数据源头，超过 70% 来自监控告警系统。Prometheus 与 Zabbix 作为两大主流方案，其数据模型、告警生命周期、输出接口差异显著。本章聚焦源系统分析，为后续字段映射与同步策略奠定基础。

3.1 核心数据模型对比

维度	Prometheus	Zabbix
数据模型	指标（Metric）+ 标签（Label）	监控项（Item）+ 主机（Host）+ 触发器（Trigger）
告警实体	Alert（告警对象）	Event（事件）→ Action（动作）
唯一标识	alertname + labels 组合	eventid（全局自增）
告警状态	firing / pending / resolved	PROBLEM / OK / ACKNOWLEDGED
时间精度	毫秒级（RFC3339）	秒级（Unix Timestamp）
标签/元数据	丰富的 Label 键值对	Host groups / Templates / Tags

实战要点：Prometheus 的标签体系天然适合多维聚合，但告警去重需依赖 labels 组合；Zabbix 的 eventid 是严格递增的，适合做增量同步的游标。

3.2 Prometheus 告警数据结构与输出接口

3.2.1 Alertmanager 告警对象结构

Prometheus 通过 Alertmanager 对外输出告警，标准 JSON 结构如下：

{
  "status": "firing",
  "labels": {
    "alertname": "HighCpuUsage",
    "instance": "web-01:9090",
    "severity": "critical"
  },
  "annotations": {
    "summary": "CPU 使用率超过 90%",
    "description": "实例 web-01 CPU 使用率已达 95%"
  },
  "startsAt": "2025-03-20T10:30:00Z",
  "endsAt": "0001-01-01T00:00:00Z",
  "generatorURL": "http://prometheus:9090/graph?g0..."
}

字段	类型	说明
status	string	firing / resolved
labels	map[string]string	告警唯一标识 + 路由分组依据
annotations	map[string]string	可读信息，不参与去重
startsAt / endsAt	RFC3339	告警开始/结束时间

3.2.2 输出接口

Webhook Receiver：Alertmanager 配置 webhook 接收器，将告警 POST 到台账系统 API。
API 查询：GET /api/v2/alerts 获取当前活跃告警列表。
Silence 管理：PUT /api/v2/silences 用于抑制告警，台账系统可同步静默状态。

  同步优化建议：Webhook 方式实时性最高，但需处理重复推送；API 轮询适合批量补数，建议间隔 30-60 秒。

3.3 Zabbix 告警数据结构与输出接口

3.3.1 Event 对象结构

Zabbix 通过事件（Event）驱动告警流程，核心字段如下：

{
  "eventid": "123456",
  "source": "0",
  "object": "0",
  "objectid": "7890",
  "clock": "1710916200",
  "value": "1",
  "acknowledged": "0",
  "name": "CPU load too high on web-01",
  "severity": "5"
}

字段	类型	说明
eventid	string	全局唯一，自增，适合做同步游标
value	integer	0=OK, 1=PROBLEM
clock	integer	Unix 时间戳（秒）
severity	integer	0~5，5 为 Disaster
acknowledged	integer	0/1 是否已确认

3.3.2 输出接口

Zabbix API（JSON-RPC）：调用 event.get 方法，支持时间范围、事件类型过滤。
Action 脚本：通过 Zabbix 动作配置远程命令或 Webhook，推送告警到台账系统。
数据库直连：读取 events 表（不推荐，耦合度高）。

避坑提示：Zabbix 的 eventid 在历史表（events）和告警表（alerts）中含义不同，同步时务必确认使用 events 表的 eventid 作为增量游标。

3.4 数据输出接口对比总览

3.5 同步字段映射关键点

从源系统到台账系统，以下字段必须建立映射关系：

告警唯一 ID：Prometheus 用 labels 组合，Zabbix 用 eventid。
告警标题：Prometheus 取 annotations.summary，Zabbix 取 event.name。
告警级别：Prometheus 用 labels.severity，Zabbix 用 severity 数值（需转换为台账等级）。
发生时间：Prometheus 用 startsAt，Zabbix 用 clock（需转换为台账时区）。
恢复时间：Prometheus 用 endsAt，Zabbix 通过后续 OK 事件关联。
告警状态：Prometheus 用 status，Zabbix 用 value + acknowledged 组合。

  映射陷阱：Zabbix 的 severity 是 0-5 整数，而 Prometheus 的 severity 是字符串（critical/warning/info）。台账系统需建立统一的等级枚举表，避免同步后等级错乱。

3.6 增量同步游标选择

源系统	游标字段	特点	推荐策略
Prometheus	startsAt（时间戳）	可能出现时间回溯，需配合 alertname 去重	时间窗口 + 全量比对
Zabbix	eventid（自增 ID）	严格递增，无回溯风险	游标递增 + 时间窗口兜底

注意：Prometheus 的告警在 Alertmanager 重启后可能重新推送，startsAt 不变但 endsAt 可能更新。台账系统需以 alertname + instance + startsAt 作为联合去重键。