3、告警标准化：告警字段设计、告警级别定义（P0-P4）、告警分类与标签、告警去重与聚合策略
告警标准化，说白了就是给告警立规矩。
我见过太多团队，告警系统跑了一年，结果每天收到几千条告警，运维兄弟直接躺平——「反正都是噪音，看了也白看」。这其实不是工具的问题，是告警本身没做好标准化。
今天我们就聊聊，怎么把告警从「垃圾堆」变成「作战地图」。
3.1 告警字段设计：每个字段都得有用
一个告警长什么样？我习惯用「5W1H」来定义字段：
- Who：谁触发的？主机名、服务名、容器ID
- What：发生了什么？指标名、阈值、当前值
- When：什么时候发生的？时间戳（精确到毫秒）
- Where：在哪个环境？机房、集群、命名空间
- Why：为什么触发？规则ID、规则描述
- How：严重程度如何？级别、影响范围
举个例子，一个标准的告警JSON长这样：
{
"alert_id": "a7f3b2c1-9d8e-4f5a-6b7c-8d9e0f1a2b3c",
"rule_name": "CPU使用率过高",
"severity": "P1",
"status": "firing",
"starts_at": "2025-03-20T14:32:00.000Z",
"ends_at": null,
"generator_url": "http://prometheus:9090/graph?g0...",
"labels": {
"host": "web-01",
"service": "nginx",
"env": "production",
"region": "us-east-1"
},
"annotations": {
"summary": "CPU使用率超过90%",
"description": "主机 web-01 的CPU使用率当前为 95.2%，已持续5分钟",
"runbook_url": "http://wiki/runbooks/cpu-high.md"
}
}
我的经验： 字段别贪多。我见过有人加了20多个字段，结果告警解析都卡了。核心字段控制在10个以内，够用就行。
3.2 告警级别定义（P0-P4）：别把小事当大事
告警级别，是运维的「红绿灯」。我习惯用P0到P4五级：
| 级别 | 定义 | 响应时间 | 举例 |
|---|---|---|---|
| P0 | 核心服务完全不可用，影响所有用户 | 立即响应（5分钟内） | 数据库宕机、支付接口超时 |
| P1 | 核心服务部分不可用，影响部分用户 | 15分钟内 | 某个API响应延迟超过5秒 |
| P2 | 非核心服务异常，或核心服务有潜在风险 | 1小时内 | 磁盘使用率超过85% |
| P3 | 不影响业务，但需要关注 | 24小时内 | 证书即将过期（7天内） |
| P4 | 信息性告警，无需立即处理 | 下一个迭代 | 日志中出现少量WARN |
避坑指南： 我曾经见过一个团队，把所有告警都设成P0。结果呢？真正的P0来了，大家反而没感觉了。这叫「告警疲劳」。记住：P0是核弹，别当鞭炮放。
3.3 告警分类与标签：给告警打上「身份证」
告警分类，说白了就是给告警分堆。我习惯按三个维度分：
- 按来源：基础设施、应用、网络、安全
- 按类型：可用性、性能、容量、安全
- 按影响：用户影响、系统影响、无影响
标签呢？我建议用键值对。比如：
labels:
team: "sre"
service: "payment"
env: "prod"
region: "cn-north-1"为什么要这么搞？你想想看，有了标签，你就能快速过滤：
- 只看「payment」服务的告警
- 只看「prod」环境的P0告警
- 只看「cn-north-1」区域的告警
我的习惯： 标签别超过5个。多了反而乱。我一般固定用 team、service、env、region 四个，够用了。
3.4 告警去重与聚合策略：别让告警刷屏
告警去重，是运维的「降噪耳机」。我见过最夸张的案例：一个磁盘满了，结果触发了2000条告警——每个文件系统都报一次。这谁受得了？
常用的去重策略有几种：
- 时间窗口去重：同一个规则，5分钟内只发一次
- 标签去重：相同标签的告警，合并成一条
- 内容去重：告警内容完全一样，只保留最新一条
聚合策略呢？我习惯用「根因聚合」：
# 示例：如果主机宕机，所有依赖它的服务告警都聚合到主机告警下
- 主机宕机 (P0)
- 服务A不可用 (P1)
- 服务B响应超时 (P1)
- 服务C连接失败 (P1)这样，你只需要处理主机宕机这一个告警，其他都是「子告警」。嗯，这里要注意：子告警不是不重要，而是告诉你「别重复造轮子」。
我曾经踩过的坑： 去重策略太激进，把不同原因的告警也合并了。结果排查问题时，发现告警数量少了，但问题反而更难定位。所以，去重要「去重不丢信息」，聚合要「聚合不掩盖根因」。
3.5 实战建议：从0到1搭建告警标准化
如果你现在要从头开始，我建议分三步走：
- 先定字段：把告警的「5W1H」定下来，写进规范文档
- 再定级别：和业务方一起，把P0-P4的定义对齐
- 最后定策略：去重和聚合，先保守再激进
说白了，告警标准化不是技术问题，是管理问题。你想想看，如果团队里每个人对「P0」的理解都不一样，那告警系统再牛也没用。
我个人习惯，每季度做一次告警复盘：看看哪些告警是噪音，哪些级别定错了，哪些标签该调整。嗯，持续迭代，才能让告警系统真正好用。
核心一句话： 告警标准化的目标，不是「减少告警数量」，而是「让每条告警都有价值」。