告警数据结构设计

做告警自动化脚本，第一步不是写代码。

是先把数据长什么样搞清楚。

我早期吃过这个亏。当时急着写处置逻辑，压根没管告警数据到底长啥样。结果脚本跑起来，有的告警丢字段，有的时间格式不统一，还有的把IP地址塞进描述字段里……

说白了，数据模型没设计好，后面全是坑。

从零开始定义你的告警模型

告警事件的核心是什么？

就是一个对象。这个对象包含了告警的“身份信息”和“上下文”。我们写脚本去处理它，本质上就是在解析这个对象。

所以，我先画一个最基础的数据模型。

// 我习惯用JSON来展示结构，清晰
{
  "alert_name": "CPU_Usage_High",
  "severity": "critical",
  "timestamp": "2025-04-10T14:32:00Z",
  "source": "node_exporter",
  "description": "Server web-01 CPU usage exceeded 95% for 5 minutes"
}

嗯，别看它简单。这五个字段，是你能写出靠谱脚本的基石。

你想想看，如果连告警名字都不统一，后续怎么做自动化处理？如果时间格式是乱糟糟的字符串，你怎么判断告警什么时候发生的？

五个核心字段，一个都不能少

告警名称（alert_name）

这是唯一标识。在脚本里，我经常用它来做路由——决定该调哪个处理函数。

• 命名规范：建议用大写字母+下划线，一目了然。
• 我在项目中遇到过：有人用中文名，结果脚本解析时各种编码报错。从此我只用英文。
• 类型：字符串（String），必选。

告警级别（severity）

决定了你要不要半夜爬起来。通常有这几个档次：

级别	含义	脚本处理策略（我常用的）
critical	紧急，服务挂了	立即触发自愈脚本，同时推送到电话告警
warning	警告，指标异常	自动检查三次，如果没恢复再升级
info	通知，例行事件	只在日志里记录，不处理

告警时间（timestamp）

这个字段坑最多。我曾经见过用Unix时间戳、用“2025-04-10 14:32:00”字符串、甚至用中文“下午两点三十二分”的。

告警来源（source）

这个字段告诉咱们，警报是从哪个系统跳出来的。是Prometheus？Zabbix？还是自研的监控平台？

• 来源不同，解析逻辑也不同。
• 我习惯用完整名称，比如“prometheus/alertmanager”或“zabbix/server”，而不是简称。

告警描述（description）

最灵活，也最容易“脏”。

描述里通常包含了具体信息，比如哪个IP、哪个实例、当前数值、阈值是多少。

个人习惯：用JSON来描述数据模型

你可能会问，为什么用JSON，而不是YAML或者XML？

原因很简单：Python对JSON支持最好，几乎零门槛。每个库、每个格式都能完美兼容。

# 这是我在实战中用的一个标准告警模型
{
  "alert_name": "Disk_Full",
  "severity": "warning",
  "timestamp": "2025-06-15T08:00:00Z",
  "source": "node_exporter",
  "description": "Disk /data is 85% full (threshold: 80%)",
  // 下面是我额外加的扩展字段
  "host": "web-02.example.com",
  "current_value": 85.0,
  "threshold": 80.0,
  "alert_id": "a1b2c3d4"
}

看到了吗？我加了几个字段。这是关键。

基础字段保证通用性，扩展字段保证灵活性。脚本里可以根据alert_id去重，根据current_value判断衰减趋势。

踩过的坑：那些年我见过的告警数据结构灾难

• 字段缺失：有的告警没有timestamp，脚本只能拿接收时间凑数。但接收时间可能比实际发生时间晚了几分钟。
• 级别乱写：有用数字1/2/3表示级别的，有用“P0/P1/P2”的。统一转成critical/warning/info。我通常在脚本入口做一层映射。
• 描述不结构化：比如“CPU high on server”。信息太少，脚本根本没法自动处理。我后来推动团队在描述里加上了“指标：数值：阈值”的固定格式。

嗯，先把数据模型定下来，再开始写处置逻辑。这一步不能省。