Java异常告警系统实现：拦截器与通知实战

Java异常告警该用拦截器还是AOP？

用 @ControllerAdvice + @ExceptionHandler 是最轻量、最可控的选择；拦截器（HandlerInterceptor）只能捕获到进入 DispatcherServlet 后的异常，漏掉参数解析失败、400 错误、甚至部分 RuntimeException；而 AOP 的 @Around 切 Exception 容易误切非业务异常（如框架内部重试抛的异常），还可能干扰事务传播。

• 优先写一个继承 ResponseEntityExceptionHandler 的 @ControllerAdvice 类，覆盖 handleException 和 handleMethodArgumentNotValid
• 在 @ExceptionHandler 方法里做两件事：记录带堆栈的告警日志、调用通知服务（比如发钉钉/企业微信）
• 别在拦截器的 afterCompletion 里 try-catch —— 此时异常已被处理，exception 参数为 null 是常态

告警触发条件怎么设才不吵人？

直接对每个 Exception 都发告警，等于给自己装了个闹钟炸弹。真正要告警的是「未预期的、影响可用性的、重复发生的」异常。

• 白名单机制：只对特定子类告警，比如 NullPointerException、SQLException、自定义的 ServiceUnavailableException；跳过 IllegalArgumentException、HttpRequestMethodNotSupportedException 这类客户端错误
• 加简单去重：用异常类名 + 方法签名（joinPoint.getSignature().toShortString()）作 key，5 分钟内相同 key 只发一次
• 避免在日志异步线程里发通知——Spring Boot 默认的 logging.pattern.console 不会打印异步上下文中的 MDC，告警里看不到 traceId

通知服务怎么集成才不拖慢主流程？

同步调用钉钉 Webhook 或邮件 SMTP，一旦网络抖动或对方限流，你的接口响应时间直接从 200ms 涨到 5s+，还可能引发线程池耗尽。

• 必须异步：用 @Async + 独立线程池（别共用 taskExecutor），并设置拒绝策略为 CALLER_RUNS 防止堆积
• 加降级：通知失败时，至少把结构化告警数据写进本地文件（如 /var/log/app/alerts.log），后续用 Filebeat 拉走
• 别传完整堆栈进通知内容——HTTP body 超长容易被网关截断；只传 e.getClass().getSimpleName()、e.getMessage()、traceId、发生时间、URL 和前 3 行关键堆栈

Spring Boot 3.x 下 @ControllerAdvice 告警失效？

不是失效，是默认异常处理器变了：ResponseEntityExceptionHandler 在 Spring Boot 3 中已迁移到 org.springframework.web.servlet.mvc.method.annotation 包下，且部分方法签名调整（比如 handleHttpMessageNotReadable 返回类型从 ResponseEntity 变成 Object）。

• 确认你继承的是新包路径下的 ResponseEntityExceptionHandler，IDE 里按住 Ctrl 点进去看包名
• 如果用了 spring-boot-starter-validation，@Valid 失败不再走 handleException，必须显式重写 handleMethodArgumentNotValid
• WebMvcConfigurer 中注册的 WebMvcConfigurationSupport 子类若重写了 configureHandlerExceptionResolvers，可能覆盖掉你的 @ControllerAdvice，检查是否多了一层配置

告警系统最难的从来不是“怎么发”，而是“什么时候不该发”和“发完怎么查”。留好 traceId、限制通知频次、隔离通知线程池——这三件事没做扎实，告警越全，噪音越大。