告警等级须按业务影响划分：p0（critical）对应服务不可用等严重问题，需电话+钉钉+短信即时触达；p1（warning）为性能劣化或资源临界，邮件+钉钉30分钟响应；p2（info）属潜在风险，仅群内推送、工作日处理；须统一用labels.severity字段及英文值，避免混用，并配置alertmanager差异化路由与通知策略。
告警等级不是随便填的标签，而是影响响应节奏、通知渠道甚至值班安排的关键决策。核心逻辑就一条：等级决定谁看、怎么看、什么时候看。
按业务影响定等级
等级必须锚定在真实业务后果上，而不是技术指标本身。
- P0（严重/危险）：服务不可用、核心链路中断、数据丢失风险。比如 API 响应成功率跌到 0%、数据库连接池耗尽、集群 etcd 不可用。这类告警必须立刻触达值班人，走电话+钉钉+短信三通道。
- P1（警告/高）：性能明显劣化但未中断，或资源逼近临界点。比如 CPU 持续 90% 超过 5 分钟、磁盘剩余不足 10%、Pod 重启频率突增。适合邮件+钉钉推送，要求 30 分钟内响应。
- P2（信息/中低）：潜在风险或非关键组件异常。比如某非核心服务延迟升高、某个节点负载偏高但仍有冗余、日志错误率小幅上升。可仅推送到团队群，工作日处理即可。
用 labels 统一标识等级
在 Prometheus 告警规则里，用 labels.severity 字段标准化等级，别写成 level、priority 或 urgency。
- 统一值建议用：critical、warning、info —— 这和 Alertmanager 内置路由逻辑兼容，也方便后续对接运维平台。
- 避免混用英文和中文，比如不要出现 "严重" 和 "critical" 并存的情况。
- 可在同一规则里叠加其他业务标签，如 service: payment、team: backend，便于 Alertmanager 按 severity + team 路由到不同接收组。
不同等级配不同通知策略
等级不光是标在告警上，更要落实到 Alertmanager 的路由配置中。
- critical 告警：匹配后直接走 root route，启用 repeat_interval: 15m（防止重复打扰），并设置 group_by: [alertname, cluster] 避免淹没。
- warning 告警：可归入一个中间 route，group_wait: 60s + group_interval: 5m，聚合同类问题再发，减少干扰。
- info 告警：建议关闭即时推送，只写入日志或同步到内部看板，不触发任何外部通知。
警惕“等级通胀”陷阱
所有告警都标 critical，等于没有等级。常见误操作包括：
- 把单个 Pod 重启标为 P0 —— 实际应看 Deployment 整体可用副本数是否达标；
- 对测试环境照搬生产等级 —— 测试环境 warning 可降为 info；
- 用阈值高低代替影响判断 —— CPU 95% 在批处理任务里可能是正常态，但在网关服务里就是 P0。
