防告警风暴的核心是控制告警频率、条件和粒度，而非校验异常内容重复；需分层过滤（白名单/黑名单）、同源异常聚合限流（caffeine滑动窗口）、告警通道分级（prometheus指标+alertmanager高优路由）。
在 Spring Boot 全局异常处理中防止告警风暴，核心不是“校验异常内容是否重复”，而是**控制告警触发的频率、条件和粒度**。重复报警（如 1 秒内连续抛出 100 次 NullPointerException）往往源于上游问题未修复或下游服务雪崩，直接在异常处理器里做字符串比对或缓存判重，既不可靠又容易掩盖真实问题。
关键思路：分层过滤 + 限流降噪 + 上游归因
真正有效的做法是把“防告警风暴”拆解为三个可落地的环节：
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
-
不告无意义的异常：在全局异常处理器中，对日志级别、HTTP 状态码、异常类型做白名单/黑名单过滤。例如，400 类参数错误、401/403 认证异常、业务自定义的
ValidationException默认不触发告警；只对 500、503、SQLException、TimeoutException等系统级异常记录并上报。 -
同源异常聚合限流：用轻量缓存（如 Caffeine）按异常类名 + 请求路径（或关键业务 ID）做滑动窗口计数。例如：5 分钟内同一
UserService.findUserById抛出NullPointerException超过 5 次，才发首次告警，并记录“已抑制 N 次”。注意缓存 key 要带时间戳或哈希前缀，避免长生命周期导致内存泄漏。 -
告警通道分级兜底：不要让所有异常都走企业微信/短信。配置多级通道：高频低危异常 → 写入 Prometheus 指标（
app_exception_total{type="NPE",path="/api/order"}），配合 Grafana 设置“5 分钟突增 300%”才触发通知；真正严重异常 → 直接触发 Alertmanager 的高优先级路由（如电话+钉钉+邮件）。
代码层面的典型实现要点
在 @RestControllerAdvice 中集成限流逻辑时，注意以下细节：
- 使用
Caffeine.newBuilder().expireAfterWrite(5, TimeUnit.MINUTES).maximumSize(1000)构建本地缓存，避免 Redis 引入额外依赖和延迟； - 计算 key 时建议组合：
exception.getClass().getSimpleName() + ":" + request.getRequestURI() + ":" + StringUtils.substring(request.getRemoteAddr(), 0, 15)，兼顾类型、接口、来源 IP 段； - 不要在
@ExceptionHandler方法里直接发告警，而是调用统一的AlertService.alertIfThresholdExceeded(key, exception)，把判断和发送解耦； - 务必记录原始堆栈到日志（INFO 或 WARN 级别），但告警消息体中只传摘要，如 “NPE in /api/user/update, 5min×12 (suppressed:7)”，避免敏感信息泄露。
更治本的做法：从源头减少重复异常
全局异常处理器只是最后一道闸门。要根治告警风暴，必须配合以下措施：
- 对频繁失败的下游 HTTP 调用，加熔断（Resilience4j）和退避重试，避免失败请求持续打穿本服务；
- 数据库连接池、Redis 客户端等中间件配置合理的超时与连接数，避免线程卡死引发连锁异常；
- 用 Actuator + Micrometer 暴露
counter.exception.total指标，结合 Prometheus 告警规则识别“单实例异常率 > 5% 持续 2 分钟”，而非只看绝对次数。
