告警分类方法：按严重级、按来源、按类型

告警分类这事儿，说简单也简单，说复杂真能把你绕晕。我刚带团队那会儿，遇到过一个线上事故——半夜三点告警响成一片，值班同事根本分不清哪个该先处理。后来复盘发现，就是分类没做好。所以今天咱们聊聊，怎么把告警分门别类，让巡检和处置变得轻松。

为什么需要分类？

你想想看，一天几千条告警，如果全堆在一起，跟没告警有啥区别？分类的核心目的就两个：

• 确定优先级：哪些要立刻响应，哪些可以等上班再看
• 明确责任人：是网络组、应用组还是安全组的事

我个人习惯，分类维度至少要有三个：严重级、来源、类型。三者的关系，我画了张图，你先有个整体印象。

按严重级分类

这是最直观的分类方式。说白了就是——先救火，再补墙。我在项目中一般把严重级分成四级：

级别	定义	响应要求	典型例子
P1（致命）	业务完全中断，核心服务不可用	立即响应，5分钟内拉起线上会	支付接口挂死、数据库主库宕机
P2（严重）	重要功能受损，影响用户体验	15分钟内响应，1小时内处置	某个省份用户登录延迟、缓存雪崩
P3（警告）	非核心功能异常，业务可降级运行	1小时内确认，8小时内修复	日志采集队列积压、非关键告警阈值超限
P4（提示）	不影响业务，但需要关注	日常巡检时处理	磁盘使用率超过80%、老旧证书即将过期

按来源分类

告警从哪来的？这决定了你找谁去处理。我习惯把来源分成这几类：

• 基础设施层：服务器CPU、内存、磁盘、网络设备。曾经有一次，交换机端口CRC错误暴增，应用组和数据库组互相甩锅，最后发现是网线没插紧。
• 中间件/数据库：MySQL、Redis、Nginx、Kafka等。这类告警通常需要DBA或中间件运维介入。
• 应用层：业务接口响应慢、错误率升高、服务间调用超时。别忘了，很多应用层的根因其实在底层。
• 安全层：入侵检测、病毒扫描、异常登录。安全告警往往需要联动安全运营中心（SOC）处置。
• 业务层：订单量异常、用户投诉率飙升。这类告警需要业务产品负责人一起看。

按类型分类

类型分类告诉我们——问题到底是什么。我把常见告警类型归纳为四类：

类型	说明	举例
阈值告警	指标超过预设阈值	CPU>90%、连接数>500
变化率告警	指标在短时间内剧烈波动	流量5分钟飙升10倍、错误率突增
状态告警	服务状态切换	进程退出了、端口不通、心跳丢失
日志告警	日志中出现特定关键字	OOM、空指针、SQL语法错误

我个人觉得，变化率告警往往比阈值告警更有价值。为什么？因为阈值告警你可能会收到“CPU 91%”这种接近阈值的告警，但实际业务没受影响。而流量突然翻倍，往往意味着营销活动或者攻击，需要立刻确认。

如何组合使用？

光分类还不够，你得把它们组合起来。我在项目里是用一个标签系统来完成的：

# 以Prometheus告警规则为例
- alert: MySQL连接数过高
  expr: mysql_global_status_threads_connected > 500
  for: 2m
  labels:
    severity: P2
    source: MySQL-主库
    type: 阈值告警
  annotations:
    summary: "MySQL主库连接数超过500"
    description: "当前值: {{ $value }}"

你看，一条告警包含了三个维度的标签。这样做的好处：

• 告警聚合时按严重级+来源排序，优先处理P1+应用层的组合
• 值班同事一看标签就知道该找谁，不用再查文档
• 后期做告警收敛（告警压缩、抑制）时，更容易判断哪些告警是同一个根因

分类的自动化落地

最后聊点落地的事。手动给告警打标签？不现实，几千条你打不完。得靠自动化：

• Prometheus + Alertmanager：在告警规则中定义labels字段，天然支持
• Elasticsearch + Watcher：通过查询条件区分告警类型，输出带标签的Webhook
• 自定义脚本：从日志中提取关键字，匹配分类规则，推送至告警平台

我曾经接手过一个遗留系统，告警全是“error: something happened”，没有任何结构化信息。后来写了个脚本，用正则解析报错信息，打上“类型”标签，再通过告警平台去重和升级。效果立竿见影，值班同事说“总算知道该先修什么了”。