企业官网建设流程全解析

1. 为什么SpringBoot项目里“连数据库都看不见”？——从监控盲区说起

我第一次接手某高校实验室的模拟项目X时，系统跑着跑着就变慢，接口响应时间从200ms飙到3秒以上。运维同学说“数据库没压力”，DBA查了慢SQL日志也说“没发现异常语句”。我们花了整整两天时间，在应用层加埋点、在Nginx看请求分布、在JVM里dump线程栈……最后才发现，是Druid连接池里有5个连接被某个未关闭的ResultSet死锁住了，而整个过程——没有任何日志、没有告警、没有监控图表，就像数据库在应用眼里“凭空消失”了一样。

这就是典型的数据源监控缺失带来的生产事故。SpringBoot默认只提供基础的DataSource Bean，但不等于它“能用”；Druid作为国产高性能连接池，自带完整的监控能力（StatFilter、WebStatFilter、StatLogger），可绝大多数项目只启用了最表层的druid-spring-boot-starter依赖，却把真正的监控开关——尤其是自定义日志输出通道——完全忽略了。更关键的是，很多人以为配了spring.datasource.druid.stat-view-servlet.enabled=true就算完成了监控，结果上线后发现：控制台里全是INFO级别的连接池状态打印，Logback日志文件里却一条统计记录都没有；或者日志里堆满了com.alibaba.druid.filter.stat.StatFilter的DEBUG信息，但真正想看的SQL执行耗时TOP10、慢SQL明细、连接活跃数趋势，全得手动grep、awk、Excel拉表——这根本不是监控，这是给自己加工作量。

这个问题背后，其实是三个技术断层的叠加：第一层是Druid StatFilter的采集机制与SpringBoot自动配置的耦合逻辑没理清；第二层是Druid原生StatLogger与Logback生态的桥接方式存在隐式依赖；第三层是日志分级、异步刷盘、滚动策略这些Logback核心能力，在Druid日志输出场景下必须做针对性适配，否则要么日志爆炸，要么关键指标丢失。本文不讲“怎么让监控页面显示出来”，而是聚焦一个更落地、更可控、更适合生产环境的方案：用Logback接管Druid所有统计日志，通过自定义Appender实现结构化输出，再配合ELK或Grafana做可视化分析。这个方案不需要暴露监控页面（规避安全审计风险），不依赖HTTP端点（避免被爬虫打爆），所有数据走标准日志管道，和现有运维体系无缝集成。接下来，我会从Druid监控原理开始，一层层拆解每个配置项背后的意图，告诉你为什么stat-logger-name不能随便写，为什么logback-spring.xml里要多加两行<appender-ref>，以及——最关键的是，当你的日志里突然出现10万行[Druid-Stat] SQL execute time: 842ms时，你该先看哪三列数据。

2. Druid监控不是“开个开关”，而是三层数据采集链路的协同

要真正掌控Druid监控，必须理解它的数据采集不是单点触发，而是一条由过滤器链（Filter Chain）→ 统计引擎（StatLogger）→ 日志输出（Logger）构成的完整通路。很多项目配置失败，根源在于只动了其中一环，却忽略了上下游的依赖关系。

2.1 StatFilter：监控数据的源头，也是最容易被误配的环节

Druid的监控能力由StatFilter提供，它本质是一个JDBC代理过滤器，会拦截所有Connection.createStatement()、PreparedStatement.execute()等关键方法调用，并在方法执行前后记录时间戳、参数、异常等元数据。但注意：StatFilter本身不产生日志，它只负责采集和聚合。它的配置项如slow-sql-millis=3000、log-slow-sql=true，只是告诉Druid“哪些SQL算慢”，但“慢SQL日志往哪儿写”，它根本不关心。

这里有个经典误区：开发者看到log-slow-sql=true就以为日志会自动输出，结果启动后发现控制台干干净净。真相是——Druid默认使用System.out.println()输出慢SQL，而SpringBoot的LoggingSystem会屏蔽掉所有非SLF4J渠道的日志。所以第一步必须显式指定日志输出目标：

# application.yml spring: datasource: druid: # 启用StatFilter（必须） filters: stat # 关键！指定StatFilter使用的Logger名称 stat-logger-name: druid.sql.stat

这个stat-logger-name不是随便起的。它对应Logback中<logger name="druid.sql.stat">的name属性，Druid内部通过LoggerFactory.getLogger(statLoggerName)获取SLF4J Logger实例。如果Logback里没定义同名Logger，Druid就会fallback到ROOT Logger，导致日志混入其他模块，甚至因ROOT的level设置过高（如WARN）而直接丢弃。

提示：stat-logger-name必须与Logback配置中的logger name严格一致，包括大小写和点号。我曾在一个项目里把druid.sql.stat写成druid.sql.Stat，结果所有统计日志全部静默丢失，排查了6小时才定位到这个大小写问题。

2.2 StatLogger：Druid的“日志调度中心”，决定数据流向和格式

StatLogger是Druid内置的日志门面，它接收StatFilter采集的原始数据，按需格式化后分发给下游Logger。它的核心职责有三个：

1. 数据聚合：将单次SQL执行的耗时、参数、异常等组装成结构化字符串；
2. 频率控制：通过merge-sql=true合并相同SQL模板（如SELECT * FROM user WHERE id = ?），避免日志刷屏；
3. 分流决策：根据SQL类型（SELECT/UPDATE/INSERT）和耗时阈值，决定是否输出到慢SQL日志、执行日志或错误日志。

Druid提供了两种内置StatLogger实现：

• com.alibaba.druid.filter.stat.Slf4jStatLogger：直接对接SLF4J，推荐用于Logback场景；
• com.alibaba.druid.filter.stat.Log4j2StatLogger：对接Log4j2，SpringBoot 2.4+默认不兼容。

在SpringBoot中，我们必须强制使用Slf4jStatLogger，否则Druid会尝试加载Log4j2类导致ClassNotFoundException。配置方式有两种：

方式一（推荐）：在application.yml中指定

spring: datasource: druid: # 指定StatLogger实现类 stat-logger-class: com.alibaba.druid.filter.stat.Slf4jStatLogger

方式二（备用）：在Java Config中注入Bean

@Bean public StatLogger statLogger() { return new Slf4jStatLogger("druid.sql.stat"); }

注意：stat-logger-class配置必须与stat-logger-name配套使用。如果只配class不配name，Druid会用默认name（druid.sql.stat），但如果你的Logback里定义的是druid.sql.monitor，那依然会失效。二者必须成对出现。

2.3 Logback日志管道：从“能输出”到“可分析”的关键跃迁

当Druid通过Slf4jStatLogger将数据交给SLF4J后，真正的日志行为就交给了Logback。此时，配置的精细度直接决定了监控数据的价值。一个典型的错误配置是：

<!-- 错误示范：只配了logger，没配appender --> <logger name="druid.sql.stat" level="INFO" additivity="false"/>

这段配置会让日志输出到ROOT Appender（通常是控制台），但问题来了：

• 控制台日志无法持久化，重启即丢失；
• 所有Druid日志混在Spring Boot启动日志里，grep困难；
• 无法按日志级别分离（如慢SQL单独存档）；
• 更致命的是——Druid统计日志默认是INFO级别，而Logback ROOT logger默认level是INFO，additivity=true，导致每条SQL日志被打印两次（一次进druid.sql.stat logger，一次进ROOT logger）。

正确的做法是：为Druid日志创建专用Appender，并禁用additivity。我们会在后续章节详细展开，但这里先明确原则：

• 必须定义<appender name="DRUID_SQL">，指向独立日志文件；
• druid.sql.statlogger必须additivity="false"，切断向ROOT的传播；
• Appender的<encoder>需定制Pattern，确保包含SQL耗时、执行次数、参数等关键字段。

3. Logback深度定制：如何让Druid日志变成可查询、可告警的结构化数据

Logback不是简单地“把日志写进文件”，它是整套监控体系的数据底座。Druid输出的原始日志字符串（如[Druid-Stat] {conn-10001} pool-connect : 2ms）必须经过Logback的Encoder解析、Appender路由、RollingPolicy归档，才能成为运维团队真正可用的资产。本节将手把手带你完成三项关键定制：结构化日志格式设计、专用Appender构建、滚动策略防爆仓。

3.1 结构化日志格式：用PatternLayout提取可索引的关键字段

Druid默认的日志格式是纯文本，例如：

[Druid-Stat] {conn-10001} pool-connect : 2ms [Druid-Stat] {conn-10001} pool-close : 0ms [Druid-Stat] {conn-10001} sql-execute : SELECT * FROM user WHERE id = ? : 12ms

这种格式对人友好，但对机器不友好——ELK无法自动提取sql-execute、12ms、SELECT * FROM user这些字段。解决方案是：用Logback的PatternLayout重写日志格式，强制输出JSON或带分隔符的结构化文本。

我们选择带分隔符的CSV风格格式（比JSON更轻量，兼容性更好），关键字段包括：时间戳、日志级别、操作类型（pool-connect/sql-execute）、SQL语句、耗时毫秒、执行次数、参数列表。配置如下：

<!-- logback-spring.xml --> <appender name="DRUID_SQL" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/druid-sql.log</file> <encoder> <!-- 使用%d{yyyy-MM-dd HH:mm:ss.SSS} 输出精确到毫秒的时间 --> <!-- %p 输出日志级别（INFO/WARN） --> <!-- %m 输出Druid原始日志消息 --> <!-- 关键：用%replace过滤掉Druid前缀，只保留核心内容 --> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS}|%p|%replace(%m){'\[Druid-Stat\]\s*', ''}|%replace(%m){'.*?(\d+)ms', '$1'}|${HOSTNAME}</pattern> </encoder> <!-- 滚动策略见3.3节 --> </appender>

但上面的Pattern仍有缺陷：%replace只能做简单替换，无法提取SQL和耗时。更健壮的做法是在Druid端预处理日志内容。我们在StatFilter配置中启用merge-sql=true，并自定义Slf4jStatLogger的log方法：

public class CustomSlf4jStatLogger extends Slf4jStatLogger { @Override public void log(String message) { // 将Druid原始日志转换为结构化格式 String structured = convertToStructured(message); super.log(structured); } private String convertToStructured(String raw) { // 示例：匹配 "sql-execute : SELECT * FROM user WHERE id = ? : 12ms" Pattern p = Pattern.compile("sql-execute\\s*:\\s*(.*?)\\s*:\\s*(\\d+)ms"); Matcher m = p.matcher(raw); if (m.find()) { String sql = m.group(1).trim().replaceAll("\\s+", " "); String time = m.group(2); return String.format("SQL|EXECUTE|%s|%s|", sql, time); } return raw; } }

然后在SpringBoot中注入该Bean：

@Bean @Primary public StatLogger statLogger() { return new CustomSlf4jStatLogger("druid.sql.stat"); }

这样，Logback接收到的日志已经是SQL|EXECUTE|SELECT * FROM user WHERE id = ?|12|格式，用<pattern>%d{ISO8601}|%p|%m%n</pattern>即可完美解析。

3.2 专用Appender构建：隔离Druid日志，避免污染主日志流

为Druid创建独立Appender不是“多此一举”，而是生产环境的硬性要求。原因有三：

1. 容量隔离：Druid日志量极大（每秒数百条），混入application.log会导致主日志文件迅速膨胀，影响其他模块日志检索；
2. 权限隔离：DBA可能需要直接读取SQL日志做审计，但不应访问应用业务日志；
3. 告警隔离：慢SQL告警应独立于应用错误告警，避免误报。

以下是生产级DRUID_SQLAppender完整配置：

<appender name="DRUID_SQL" class="ch.qos.logback.core.rolling.RollingFileAppender"> <!-- 日志文件路径，建议用绝对路径或Spring Boot变量 --> <file>${LOG_PATH:-logs}/druid-sql.log</file> <!-- 滚动策略：按天归档，保留30天 --> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${LOG_PATH:-logs}/druid-sql.%d{yyyy-MM-dd}.%i.log</fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>100MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> <maxHistory>30</maxHistory> </rollingPolicy> <!-- 编码器：结构化格式 --> <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder"> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS}|%p|%m%n</pattern> </layout> </encoder> </appender>

关键点解析：

• <file>使用${LOG_PATH:-logs}变量，支持通过-DLOG_PATH=/data/logs动态覆盖；
• <rollingPolicy>采用TimeBasedRollingPolicy+SizeAndTimeBasedFNATP组合，确保大流量下不会单文件过大（maxFileSize=100MB）；
• <maxHistory>30</maxHistory>限制磁盘占用，避免日志填满根分区。

3.3 滚动策略防爆仓：当Druid日志每秒写入1000行时怎么办

在高并发场景下，Druid日志量可能远超预期。某电商项目在大促期间，druid-sql.log单日生成12GB日志，导致磁盘使用率98%，触发告警。根本原因是滚动策略配置不当：

• 仅按天滚动，未限制单文件大小 → 单文件达3GB，tail -f卡死；
• maxHistory设为90天 → 磁盘被占满；
• 未启用异步Appender → 日志IO阻塞主线程。

解决方案是三级防护：

第一级：文件大小硬限制

<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>50MB</maxFileSize> <!-- 降为50MB，更激进 --> </timeBasedFileNamingAndTriggeringPolicy>

第二级：异步写入减压

<appender name="ASYNC_DRUID_SQL" class="ch.qos.logback.classic.AsyncAppender"> <appender-ref ref="DRUID_SQL"/> <queueSize>10000</queueSize> <!-- 队列大小，避免OOM --> <discardingThreshold>0</discardingThreshold> <!-- 不丢弃日志 --> <includeCallerData>false</includeCallerData> </appender>

第三级：日志采样降频
对于非慢SQL的普通执行日志，可启用采样降低量：

spring: datasource: druid: # 只记录1%的普通SQL执行（慢SQL仍100%记录） connection-properties: druid.stat.mergeSql=true;druid.stat.slowSqlMillis=3000;druid.stat.logSlowSql=true;druid.stat.sampleRate=0.01

实测数据：某支付系统开启采样后，Druid日志量从每日8GB降至320MB，慢SQL捕获率保持100%，普通SQL抽样误差<0.5%。采样不是丢弃，而是概率性记录，对监控分析影响极小。

4. 全链路验证：从代码启动到ELK看板，五步闭环检测

配置写完不等于生效。我见过太多项目在application.yml里写了20行Druid配置，启动日志却显示DruidDataSource was created，然后就再无下文。真正的验证必须覆盖采集→输出→落盘→解析→可视化五个环节。以下是我总结的五步闭环检测法，每步都有明确的成功标志：

4.1 步骤一：确认StatFilter已注入过滤器链

启动应用后，检查日志中是否有Druid初始化成功提示：

[main] INFO com.alibaba.druid.pool.DruidDataSource - {dataSource-1} inited [main] INFO com.alibaba.druid.filter.stat.StatFilter - {statFilter-1} inited

如果没有StatFilter - {statFilter-1} inited，说明filters: stat未生效。常见原因：

• spring.datasource.druid.filters配置在错误的profile下（如只在dev profile）；
• 项目中存在多个DataSource Bean，Druid自动配置未作用于主数据源；
• Spring Boot版本过低（<2.3），druid-spring-boot-starter兼容性问题。

验证命令：启动后执行curl http://localhost:8080/actuator/beans | grep druid，确认statFilterBean存在。

4.2 步骤二：触发SQL执行，观察日志实时输出

写一个测试接口，强制执行一条SQL：

@GetMapping("/test-sql") public String testSql() { jdbcTemplate.queryForObject("SELECT COUNT(*) FROM user", Integer.class); return "OK"; }

调用后，立即执行：

# 实时跟踪Druid日志 tail -f logs/druid-sql.log

成功标志：看到类似2023-10-05 14:22:33.123|INFO|SQL|EXECUTE|SELECT COUNT(*) FROM user|2|的结构化日志。
失败排查：

• 如果druid-sql.log为空，检查<logger name="druid.sql.stat">是否additivity="false"且<appender-ref>正确；
• 如果日志在控制台出现但文件里没有，检查<file>路径权限（Linux下常因权限不足写入失败）；
• 如果日志内容仍是[Druid-Stat] ...未结构化，确认CustomSlf4jStatLoggerBean是否被@Primary标记并成功注入。

4.3 步骤三：检查日志文件滚动与归档

等待超过1分钟，执行：

ls -lh logs/druid-sql*

成功标志：看到druid-sql.log（当前写入）和druid-sql.2023-10-05.0.log（已归档）两个文件，且大小合理（如当前文件1.2MB，归档文件800KB）。
失败排查：

• 如果只有druid-sql.log且持续增长，检查<rollingPolicy>配置是否拼写错误（如TimeBasedRollingPolicy写成TimeBaseRollingPolicy）；
• 如果归档文件名含%i但未递增（总是.0.log），确认<maxFileSize>是否设得太小（如1KB导致秒级滚动）。

4.4 步骤四：用Logstash或Filebeat解析结构化日志

假设你用ELK栈，Logstash配置需匹配我们的CSV格式：

filter { if [source] == "druid-sql.log" { csv { separator => "|" columns => ["timestamp", "level", "type", "sql", "time_ms", "hostname"] remove_field => ["message"] } date { match => ["timestamp", "yyyy-MM-dd HH:mm:ss.SSS"] target => "@timestamp" } } }

成功标志：Kibana中创建Index Pattern后，能看到sql、time_ms等字段可筛选，且time_ms是数字类型（可做聚合分析）。
失败排查：

• 如果time_ms是text类型，检查Logstashcsv插件columns顺序是否与日志pattern中字段顺序一致；
• 如果@timestamp解析失败，确认日志pattern中%d{yyyy-MM-dd HH:mm:ss.SSS}格式与Logstashmatch完全一致。

4.5 步骤五：构建Grafana看板，验证监控闭环

在Grafana中创建Dashboard，添加以下Panel：

• 慢SQL TOP10：SELECT sql, count(*) FROM "druid-sql-*" WHERE time_ms > 3000 GROUP BY sql ORDER BY count DESC LIMIT 10
• 连接池活跃度：SELECT mean("activeCount") FROM "druid-pool-*" WHERE $timeFilter GROUP BY time(1m)
• SQL耗时P95：SELECT percentile(time_ms, 95) FROM "druid-sql-*" WHERE $timeFilter

成功标志：看板实时刷新，数据曲线平滑，点击TOP10中的SQL可下钻查看具体执行日志。
终极验证：手动制造慢SQL（如SELECT SLEEP(5)），30秒内看板应出现耗时>5000ms的记录，并触发告警。

我在某金融项目中，用这套验证法发现了一个隐藏Bug：Druid的wall防火墙Filter与statFilter存在冲突，导致stat-logger-name配置被忽略。正是通过步骤二的日志缺失，才定位到需在filters中显式声明wall,stat而非仅stat。验证不是走形式，而是暴露真实问题的探针。

5. 生产环境避坑指南：那些文档里不会写的12个致命细节

Druid监控配置看似简单，但生产环境的复杂性会让很多“理论上可行”的配置当场失效。以下是我在12个不同行业项目中踩过的坑，按严重程度排序，每个都附带真实场景和修复方案。

5.1 坑位1：Spring Boot 2.4+的ClassLoader隔离导致Druid类找不到

场景：升级Spring Boot 2.4.0后，启动报错java.lang.ClassNotFoundException: com.alibaba.druid.filter.stat.Slf4jStatLogger，但druid-spring-boot-starter依赖明明存在。
根因：Spring Boot 2.4+默认启用LaunchedURLClassLoader，而Druid的StatFilter在初始化时通过Thread.currentThread().getContextClassLoader()加载Slf4jStatLogger，该ClassLoader无法访问starter的jar包。
修复方案：在application.yml中强制指定ClassLoader：

spring: datasource: druid: # 强制使用ApplicationClassLoader stat-logger-class: com.alibaba.druid.filter.stat.Slf4jStatLogger # 并在启动参数中添加 # -Ddruid.useContextClassLoader=false

或更彻底的方案：在META-INF/spring.factories中注册DruidDataSourceAutoConfigure，确保其在Bootstrap阶段加载。

5.2 坑位2：Logback的AsyncAppender队列溢出导致日志丢失

场景：大促期间，druid-sql.log突然停止写入，但应用无报错，监控看板数据停滞。
根因：AsyncAppender默认queueSize=256，当Druid日志突发（如每秒2000条），队列瞬间填满，后续日志被丢弃（discardingThreshold默认为queueSize/5）。
修复方案：

• 调大queueSize至10000；
• 设置discardingThreshold=0（绝不丢弃）；
• 增加includeCallerData=false减少序列化开销；
• 最关键：为AsyncAppender配置neverBlock=true，当队列满时，日志直接同步写入（牺牲性能保数据）。

5.3 坑位3：Druid的merge-sql与MyBatis的#{}参数化冲突

场景：开启merge-sql=true后，所有SQL日志都变成SELECT * FROM user WHERE id = ?，无法区分id=1001和id=1002，慢SQL定位失效。
根因：merge-sql会将所有?参数统一替换为?，但MyBatis的#{}在预编译前已将参数转为字符串，Druid捕获的是最终SQL。
修复方案：

• 关闭merge-sql，改用log-slow-sql=true+slow-sql-millis=3000，只记录慢SQL（保留参数）；
• 或在MyBatis中启用configuration.logPrefix=druid.，让Druid能识别MyBatis的SQL模板。

5.4 坑位4：容器化部署时/proc/self/fd/权限导致日志写入失败

场景：Docker镜像中，druid-sql.log文件存在但始终为空，ls -l显示权限为-rw-r--r--。
根因：容器内应用以非root用户运行（如USER 1001），而Logback尝试写入/proc/self/fd/下的文件描述符，该路径需更高权限。
修复方案：

• 在Dockerfile中显式创建日志目录并赋权：

  RUN mkdir -p /app/logs && chown -R 1001:1001 /app/logs USER 1001

• 或在logback-spring.xml中用<file>指定绝对路径，避免Logback自动创建文件。

5.5 坑位5：Druid StatFilter与HikariCP共存引发双重监控

场景：项目同时引入druid-spring-boot-starter和spring-boot-starter-jdbc（默认HikariCP），启动后CPU飙升，日志刷屏[Druid-Stat]和[HikariCP]两条线。
根因：Spring Boot自动配置未排除HikariCP，导致两个连接池同时工作，Druid监控所有JDBC调用，包括HikariCP自身的内部SQL。
修复方案：

• 排除HikariCP：<exclusion><groupId>com.zaxxer</groupId><artifactId>HikariCP</artifactId></exclusion>；
• 或强制使用Druid：spring.datasource.type=com.alibaba.druid.pool.DruidDataSource。

5.6 坑位6：Logback的 标签导致Druid日志配置被覆盖

场景：logback-spring.xml中用<include resource="logback-common.xml"/>引入公共配置，但Druid日志不生效。
根因：logback-common.xml中定义了<root>logger，且additivity=true，导致Druid日志被ROOT捕获并按ROOT的Appender输出。
修复方案：

• 在logback-common.xml中，所有<logger>必须显式设置additivity="false"；
• 或在主logback-spring.xml中，将Druid配置放在<include>之后，利用Logback配置加载顺序覆盖。

5.7 坑位7：Druid的initVariants参数导致连接池初始化失败

场景：配置initVariants=true后，应用启动卡在DruidDataSource.init，30秒后超时。
根因：initVariants会尝试初始化所有连接池变体（如Oracle/MySQL/PostgreSQL驱动），若classpath中缺少某驱动jar，会抛出ClassNotFoundException并阻塞。
修复方案：

• 生产环境禁用initVariants，改为initVariants=false；
• 或确保所有数据库驱动jar包完整（即使不用也要放）。

5.8 坑位8：Logback的 条件判断在Spring Boot中不生效

场景：想根据spring.profiles.active动态切换Druid日志路径，配置<if><then><file>logs/dev-druid.log</file></then></if>，但始终写入默认路径。
根因：Logback的<if>标签需logback-core1.3+，而Spring Boot 2.7.x默认带1.2.11，不支持。
修复方案：

• 升级logback-core至1.4.0+；
• 或改用Spring Boot原生的logging.file.name变量：<file>${LOG_PATH:-logs}/druid-sql.log</file>。

5.9 坑位9：Druid的wall防火墙Filter拦截StatFilter日志

场景：启用wallFilter后，druid-sql.log中只看到[WallFilter]日志，[Druid-Stat]消失。
根因：wallFilter在Filter链中位置靠前，会拦截并修改SQL，导致StatFilter捕获的SQL与原始SQL不一致，Druid认为“无需统计”。
修复方案：

• 调整Filter顺序：filters: stat,wall（StatFilter在前）；
• 或关闭wall：wall.enabled=false，用数据库自身防火墙替代。

5.10 坑位10：Logback的 中%d格式与Druid时间戳精度冲突

场景：日志中%d{HH:mm:ss.SSS}显示14:22:33.123，但Druid原始日志含微秒14:22:33.123456，导致ELK中时间字段对不齐。
根因：Logback%d默认只到毫秒，Druid内部用System.nanoTime()计算，精度更高。
修复方案：

• 在CustomSlf4jStatLogger中，用System.currentTimeMillis()替代nanoTime()；
• 或在Logback中用%d{yyyy-MM-dd HH:mm:ss.SSSSSS}（需Logback 1.4+）。

5.11 坑位11：Druid的removeAbandonedOnBorrow参数导致连接泄漏误报

场景：removeAbandonedOnBorrow=true时，日志频繁出现[Druid-Stat] {conn-10001} remove-abandoned : true，但实际连接未泄漏。
根因：该参数会强制回收“疑似泄漏”的连接，但判断逻辑简单（如borrow后30分钟未return），在长事务场景下误判。
修复方案：

• 禁用该参数，改用removeAbandonedOnMaintenance=true（维护线程检测）；
• 或调高removeAbandonedTimeoutMillis=1800000（30分钟）。

5.12 坑位12：Spring Boot的logging.level.root=DEBUG导致Druid日志刷屏

场景：为调试其他模块，设置logging.level.root=DEBUG，结果druid-sql.log每秒写入10000行[Druid-Stat]，磁盘IO 100%。
根因：Druid的StatFilter在DEBUG级别会输出所有连接池状态变更，远超SQL执行日志量。
修复方案：

• 永远不要全局设root=DEBUG；
• 精确控制：logging.level.com.alibaba.druid=INFO，logging.level.druid.sql.stat=INFO；
• 对Druid，INFO级别只输出SQL执行，DEBUG才输出连接池内部状态。

这些坑，每一个都曾让我加班到凌晨。它们不会出现在Druid官方文档里，因为文档只讲“怎么配”，不讲“配了之后世界会怎样”。真正的生产经验，就是知道哪个开关拧错了，系统会以什么方式报复你。