2. 报警源与分类：基础设施报警、应用层报警、业务报警、自定义报警
报警系统设计的第一步，就是搞清楚「谁在报警」。
很多人一上来就写规则，结果报警铺天盖地，全是噪音。我见过最夸张的项目，一天报警两万条，运维直接躺平。为什么会这样？说白了，就是没把报警源和分类搞清楚。
我个人习惯，先把报警分成四大类。每一类的处理方式、响应速度、责任人都不一样。你想想看，基础设施挂了和某个用户下单失败，能是一个处理流程吗？
核心原则：报警分类决定了响应策略。基础设施报警要自动化恢复，业务报警要人工介入。混在一起，就是灾难。
2.1 基础设施报警
这是最底层、最直接的报警。服务器宕机、磁盘写满、网络不通、CPU 跑满——这些都是基础设施报警。
我记得有一次，凌晨三点被电话吵醒。告警说某台数据库服务器的磁盘使用率到了 95%。我迷迷糊糊登录上去一看，好家伙，日志文件把磁盘撑爆了。这就是典型的基础设施报警。
基础设施报警的特点：
- 指标明确：CPU、内存、磁盘、网络、IO 等，都有明确的阈值
- 自动化程度高：很多场景可以自动恢复，比如重启服务、清理日志
- 影响范围大：基础设施出问题，往往波及整个应用
我的经验：基础设施报警的阈值不要设得太死。比如磁盘使用率，我一般设 80% 警告、90% 严重、95% 紧急。留出缓冲时间，别等到满了才处理。
2.2 应用层报警
应用层报警关注的是服务本身的健康状况。比如接口响应时间变长、错误率飙升、某个微服务挂了、数据库连接池耗尽。
这类报警比基础设施报警更「软」一些。为什么？因为应用层的问题，原因可能很复杂。可能是代码 bug，可能是依赖的服务出了问题，也可能是流量突增。
应用层报警的常见指标：
| 指标 | 说明 | 典型阈值 |
|---|---|---|
| 响应时间（P99） | 99% 的请求在多少毫秒内完成 | 超过 500ms 告警 |
| 错误率 | HTTP 5xx 或业务异常的比例 | 超过 1% 告警 |
| 请求量 | QPS 或 TPS 的波动 | 突增 50% 或突降 50% 告警 |
| 连接数 | 数据库、缓存、消息队列的连接数 | 接近上限时告警 |
我曾经遇到过一个案例：某个服务的错误率突然从 0.1% 飙升到 5%。排查了半天，发现是上游的一个配置中心挂了，导致服务拿不到配置，全部走默认值。嗯，这就是应用层报警的典型场景——问题出在依赖上。
注意：应用层报警最容易产生「告警风暴」。一个服务挂了，可能引发几十个依赖服务的报警。我建议做「依赖链收敛」，只报警根因，不报警现象。
2.3 业务报警
业务报警是最「值钱」的报警。它直接反映业务是否正常运转。比如：订单量突然下降、支付成功率降低、用户注册失败、核心交易链路中断。
这类报警和基础设施、应用层报警最大的区别是什么？
业务报警关注的是「结果」，而不是「过程」。服务器 CPU 高不高不重要，重要的是用户能不能下单。
业务报警的设计思路：
- 定义核心指标：每个业务线都有自己的北极星指标。比如电商的 GMV、内容平台的 DAU、金融系统的交易成功率
- 设置基线：对比历史同期数据。比如今天上午 10 点的订单量，比上周同时间下降了 30%，就要报警
- 分层告警：轻微波动发通知，严重下降发紧急告警，完全中断直接电话
实战案例：我之前负责的一个支付系统，业务报警规则是「连续 5 分钟支付成功率低于 99%」触发紧急告警。有一次真的触发了，排查发现是银行接口升级，返回了一个新的错误码，我们的系统没处理。业务报警帮我们提前发现了问题，避免了更大范围的损失。
2.4 自定义报警
自定义报警，说白了就是「你想怎么报就怎么报」。
有些场景，标准指标覆盖不了。比如：
- 某个定时任务跑了超过 30 分钟还没结束
- 某个关键用户的登录频率异常
- 某个数据报表的产出延迟了
- 某个第三方 API 的调用次数超过了合同限制
自定义报警的实现方式：
# 伪代码示例：自定义报警脚本
def check_custom_alert():
# 检查定时任务执行时间
job_duration = get_job_duration("daily_report")
if job_duration > 30 * 60: # 超过30分钟
send_alert("定时任务执行超时", severity="warning")
# 检查关键用户登录频率
login_count = get_user_login_count("admin", time_window="5m")
if login_count > 10:
send_alert("关键用户登录异常", severity="critical")
# 检查第三方API调用次数
api_calls = get_api_call_count("payment_gateway", today=True)
if api_calls > 10000:
send_alert("API调用次数接近上限", severity="info")我的建议：自定义报警不要滥用。每加一条自定义规则，都要问自己三个问题：这个指标真的重要吗？有没有标准指标可以替代？报警之后谁来处理？我曾经见过一个团队，自定义报警写了 200 多条，最后没人看。
2.5 四大报警分类的关系
这四类报警不是孤立的。它们之间有明显的层级关系。
基础设施报警是「地基」，应用层报警是「墙体」，业务报警是「装修」。地基不稳，墙体和装修都会出问题。但反过来，装修出了问题，不一定是因为地基。
我画了一张图，帮你理解它们之间的关系：
从这张图你可以看到：
- 基础设施报警在最底层，是基础保障
- 应用层报警在中间，反映服务状态
- 业务报警在最顶层，直接体现业务价值
- 自定义报警像一把瑞士军刀，可以插入任意层级
避坑指南：我曾经犯过一个错误——把所有报警都设成同一个级别。结果基础设施的磁盘告警和业务的订单告警混在一起，运维不知道先处理哪个。后来我学乖了：基础设施报警走自动化恢复，应用层报警走值班响应，业务报警直接拉群开会。分类清晰了，效率反而高了。
嗯，以上就是报警源与分类的核心内容。记住一句话：分类对了，处理流程就顺了。
最后一个小技巧：每季度做一次报警分类的「健康检查」。看看哪些报警已经没用了，哪些报警需要调整阈值，哪些报警应该升级或降级。报警系统不是建好就完事的，它需要持续维护。
公众号:蓝海资料掘金营，微信deep3321