SpringBoot如何配置DataDog监控Hikari连接池事务耗时

你遇到的Hikari连接超时问题，本质是数据库连接被长事务/未及时释放的逻辑长时间占用，最终连接池耗尽，现有监控缺的是连接持有生命周期和事务执行维度的埋点，按以下步骤配置即可实现事务时长可视化、长事务精准定位，不需要大规模重构业务代码。

一、Spring 侧无侵入埋点配置 #

所有配置基于Spring Boot默认集成的Micrometer指标体系，不需要额外引入第三方依赖。

• 开启HikariCP内置指标与泄漏检测
  在服务配置文件中添加以下Hikari参数，Hikari本身已经实现了全连接生命周期的指标统计，只是默认没有暴露给监控系统：

  spring:
    datasource:
      hikari:
        metric-registry: micrometerRegistry # 自动绑定Spring内置的Micrometer注册器
        leak-detection-threshold: 5000 # 连接持有超过5秒自动打印持有堆栈，生产环境可安全开启，性能损耗<1%
        register-mbeans: true
  

  开启后会自动生成3个核心指标，直接对应故障场景：

  • hikaricp.connections.usage：连接从获取到关闭的总持有时长，和事务持有连接的时长完全对齐
  • hikaricp.connections.acquire：业务线程从连接池拿连接的等待耗时，超时错误发生前这个指标会率先飙升
  • hikaricp.connections.pending：正在等待连接的线程数，也就是故障时持续攀升的核心指标
    其中leak-detection-threshold参数是排查连接泄漏的最快手段：只要连接持有超过设定阈值，日志会直接打印获取该连接的完整代码堆栈，哪怕是第三方REST调用卡在事务中间，堆栈里也会直接显示对应调用的代码位置，不需要手动复现排查。

• 增加@Transactional注解的切面统计
  加一个轻量AOP切面，不需要修改任何业务代码，就能按方法维度统计所有事务的执行时长：

  @Aspect
  @Component
  public class TransactionDurationAspect {
    private final MeterRegistry meterRegistry;
  
    // 构造函数注入直接使用Spring自带依赖注入即可
    @Around("@annotation(transactional)")
    public Object countTransactionTime(ProceedingJoinPoint point, Transactional transactional) throws Throwable {
        long start = System.currentTimeMillis();
        String targetClass = point.getSignature().getDeclaringType().getSimpleName();
        String targetMethod = point.getSignature().getName();
        Tags metricTags = Tags.of(
            "class", targetClass,
            "method", targetMethod,
            "isReadOnly", String.valueOf(transactional.readOnly())
        );
        try {
            Object result = point.proceed();
            meterRegistry.timer("spring.tx.duration", metricTags)
                .record(System.currentTimeMillis() - start, TimeUnit.MILLISECONDS);
            return result;
        } catch (Throwable t) {
            meterRegistry.timer("spring.tx.duration", Tags.concat(metricTags, "hasError", "true"))
                .record(System.currentTimeMillis() - start, TimeUnit.MILLISECONDS);
            throw t;
        }
    }
  }
  

  这个切面统计的事务时长会打类名、方法名、是否只读、是否报错的标签，长事务可以直接定位到具体接口方法。

二、DataDog侧配置实现可视化与告警 #

• 开启Java Agent的事务链路采集
  服务启动时添加JVM参数，让DataDog Agent自动抓取事务调用的Span：

  -Ddd.trace.methods=org.springframework.transaction.interceptor.TransactionInterceptor#invoke
  

  配置后每个HTTP请求的APM链路里会单独展示事务块的执行区间，直接就能看到事务块内部是否包含了第三方REST调用、慢SQL等逻辑，各环节耗时占比一目了然。
• 配置自定义监控仪表盘
  在DataDog Metrics Explorer中新建专属监控面板，添加3个核心视图：
  • 连接持有时长视图：取hikaricp.connections.usage的p95、p99、最大值，按服务实例维度聚合，阈值设为10秒，超过即触发告警
  • 长事务Top视图：取spring.tx.duration的p99值，按class、method标签做Top N排序，直接展示耗时最长的事务方法
  • 连接等待预警视图：取hikaricp.connections.pending的实时值，只要数值大于0就触发预警，不用等30秒连接超时才感知故障
• 数据库侧指标补全
  在DataDog MySQL集成配置中开启performance_schema采集：

  instances:
    - server: 业务MySQL地址
      port: 3306
      username: datadog
      password: 对应采集账号密码
      performance_schema: true
  

  开启后可以采集到数据库侧每个活跃连接的事务执行时长、锁等待时长，和服务侧指标做交叉验证，排除慢SQL、锁等待导致的长事务场景。

三、同类故障的快速排查技巧 #

• 开启Hikari泄漏检测后，只要出现连接被长时间持有，日志会直接打印Apparent connection leak detected关键字，附带的堆栈直接指向拿连接的代码位置，不需要额外排查。
• 临时排查时可以直接在EC2实例上执行jstack打线程快照，筛选栈中包含第三方HTTP客户端调用、同时状态为WAITING/TIMED_WAITING的线程，这类线程就是持有连接等待第三方响应的问题线程。
• 如果不想加AOP代码，也可以直接在现有APM链路中统计HikarigetConnection和Connection.close两个Span的时间差，两个Span之间的间隔就是连接持有总时长，如果中间夹着第三方REST调用的Span，就是问题根因位置。

内容的提问来源于stack exchange，提问作者IcedDante