最近有一点时间了于是便开始做以前自己想做但是没有完成的事情。之前我其实就一直想写一个通用一点的告警推送组件把项目里的异常信息、慢请求、状态码异常、JVM 指标甚至数据库慢 SQL 这些内容统一收集起来然后直接推送到飞书、钉钉、企业微信这类 IM 工具里。这样做有两个好处一个是出了问题能第一时间知道另一个是后面如果再结合 Prometheus、Grafana甚至再结合 OpenClaw 这类智能体去做自动处理整个链路就能慢慢闭环起来。所以这次我把它重新整理了一下做成了一个可以直接接入 Spring Boot 项目的 starter名字叫pcm-prometheus-alert。本文就来介绍一下这个项目是做什么的有哪些功能怎么使用以及在业务里可以怎么落地。项目地址先简单说下它解决的问题。我们平时做项目最怕的其实不是报错而是报错了没人知道。很多时候服务已经异常了接口已经慢了线程已经堆起来了但是如果没有专门去看日志、看监控就很容易错过。所以我做这个项目的目的很明确就是让业务项目只需要引入一个 starter再配一个 webhook 地址就能具备基础的告警推送能力。目前它主要支持下面这些能力自动捕获未处理异常并推送告警统计慢请求并推送告警监控 HTTP 状态码比如 500、502、503、504采集 JVM 内存、线程等指标支持 Druid 慢 SQL 告警和连接池状态监控支持飞书、钉钉、企业微信等 webhook 推送支持告警去重避免同一类问题反复刷屏支持内置一个简单的仪表盘页面可以继续扩展 Prometheus、SkyWalking、ELK说白了它不是想替代完整的监控平台而是想先把最常用、最直接、最容易落地的告警能力沉淀成一个通用组件。二、为什么我要做这个项目这个项目其实不是为了炫技而是因为业务里确实有这种需求。以前碰到线上问题很多时候还是靠人去盯日志、看群消息、查监控。项目一多之后这种方式很容易漏。尤其是一些小问题可能还没到系统彻底挂掉的程度但是已经开始慢慢恶化了比如某个接口偶发报错某个请求耗时突然变长某个机器内存使用率持续升高某个 SQL 执行越来越慢这些问题如果能在第一时间被推送出来很多时候就能提前处理不会等到影响面变大了再去救火。我自己一直比较喜欢做一些实用型的东西所以这个项目的思路也比较简单先把最核心的告警能力做出来尽量做到接入简单不强依赖太多外部系统后续有需要再往外扩展。三、项目结构整个项目采用的是 Maven 多模块结构拆分得比较清晰。pcm-prometheus-alert/ ├── pcm-prometheus-alert-core ├── pcm-prometheus-alert-spring-boot-starter ├── pcm-prometheus-alert-sql-starter ├── pcm-prometheus-alert-extensions └── pcm-prometheus-alert-demo各模块的作用大概如下pcm-prometheus-alert-core核心模型和告警处理逻辑pcm-prometheus-alert-spring-boot-starterSpring Boot 自动装配pcm-prometheus-alert-sql-starterDruid 慢 SQL 和数据源监控pcm-prometheus-alert-extensionsPrometheus、SkyWalking、ELK 等扩展pcm-prometheus-alert-demo本地测试示例这样拆的好处也比较直接就是业务项目按需引入不需要的功能不用带上。四、主要功能这里把我目前已经做好的核心功能简单列一下。1. 异常告警这个是最基础的能力。项目里如果出现没有处理的异常会自动捕获并生成告警消息然后推送到 webhook 对应的群里。这样做的好处是不用等到用户反馈自己就能先看到异常。而且我这里还加了两个比较实用的小功能支持排除指定异常支持堆栈截断这样可以避免一些参数校验类异常也跟着一起刷屏。2. 慢请求告警这个也很实用。很多线上问题不是直接报错而是接口越来越慢。通过请求过滤器统计耗时后只要超过阈值就会自动触发告警。同时也支持排除一些不需要监控的路径比如/actuator/**/health/favicon.ico这样就不会把一些无意义的请求也统计进去。3. HTTP 状态码告警有些问题不会抛异常但是最后返回的是 500 或者 503这种情况如果只看异常日志未必第一时间能注意到。所以这里也把状态码告警加进去了默认会关注这些状态码5005025035044. JVM 指标告警目前支持的主要是 JVM 堆内存、线程数这些比较常用的指标。如果堆内存占用过高或者线程数超过阈值就会自动推送告警。对一些内存持续上涨、线程池堆积这类问题还是比较有帮助的。5. SQL 告警如果项目里本身用的是 Druid那么可以进一步把慢 SQL 和连接池状态也接进来。这个场景在业务里也很常见因为很多时候接口慢根子其实不在 Java 代码本身而是在 SQL 执行慢、连接池等待时间长。6. 多平台 webhook 推送目前支持默认 JSON飞书钉钉企业微信也就是说不管你们团队平时主要用哪一种 IM 工具基本都可以直接接入。7. 告警去重这个功能我觉得很重要。如果一个异常在几秒钟之内连续触发很多次而每一次都推送很快群里就会被刷满最后反而没人愿意看。所以这里做了冷却窗口去重同一类告警在一段时间内只会推送一次尽量做到有用而不是打扰。8. 内置仪表盘这个我自己也比较喜欢。为了方便本地测试和快速查看运行状态starter 里内置了一个很轻量的页面访问http://localhost:{port}/pcm-alert/就可以看到当前服务的一些基础信息比如 JVM 内存、线程信息、系统信息和告警状态。效果图如下五、如何使用这个部分我尽量写得直接一点。1. 先把项目拉下来git clone https://gitee.com/XuWuJing/pcm-prometheus-alert.git cd pcm-prometheus-alert mvn clean install -DskipTests因为现在项目代码已经完整了所以你可以先在本地安装一遍然后再在业务项目里引用对应的 starter。2. 业务项目引入 starter如果你只是想先用基础告警能力那么直接引入下面这个依赖就可以了dependency groupIdcom.pcm.alert/groupId artifactIdpcm-prometheus-alert-spring-boot-starter/artifactId version0.1.0-SNAPSHOT/version /dependency如果你还想接慢 SQL 和数据源告警那么再额外引入dependency groupIdcom.pcm.alert/groupId artifactIdpcm-prometheus-alert-sql-starter/artifactId version0.1.0-SNAPSHOT/version /dependency3. 配置 application.yml最基础的配置其实很少先把总开关和 webhook 配上就行。pcm: alert: enabled: true webhook: https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxx webhook-format: feishu service-name: order-service environment: prod如果想把常用能力都一起带上可以参考下面这个配置pcm: alert: enabled: true webhook: https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxx webhook-format: feishu service-name: ${spring.application.name} environment: ${spring.profiles.active} publisher: async: true queue-size: 100 timeout-ms: 3000 dedupe: enabled: true cooldown-seconds: 300 exception: enabled: true stack-trace-max-lines: 20 exclude-exceptions: - org.springframework.web.bind.MissingServletRequestParameterException - org.springframework.web.method.annotation.MethodArgumentTypeMismatchException request: enabled: true slow-threshold-ms: 1000 status-code-alert-enabled: true status-code-alert-thresholds: - 500 - 502 - 503 - 504 exclude-paths: - /actuator/** - /health - /favicon.ico metric: enabled: true interval-seconds: 30 jvm-memory-threshold: 0.8 thread-threshold: 500 cpu-enabled: false recovery-enabled: false dashboard: enabled: true4. 启动后就能直接生效这个项目的目标之一就是尽量减少接入成本。所以正常情况下业务项目只要引入依赖配置 webhook启动服务基础告警能力就能直接生效不需要你再写一堆额外代码。六、在业务场景里可以怎么用我觉得这个部分比单纯讲代码更重要所以单独说一下。1. 线上异常第一时间通知这个是最直接的场景。比如某个接口突然出现空指针、参数转换异常或者某个下游服务调用失败系统就会自动把异常信息推送到群里。这样开发、测试、运维都能第一时间看到不用再等别人截图或者口头反馈。2. 慢接口预警有些问题在最开始并不会报错只是接口慢了。比如原来 100ms 能返回的接口突然开始稳定跑到 2 秒以上这种时候虽然系统还没挂但其实已经是风险信号了。这个 starter 可以先把这种问题暴露出来让你在用户集中投诉前先看到。