一次线上问题排查引发的日志级别调整
上周三下午，团队突然收到报警，生产环境的某个核心服务响应变慢，部分接口超时。运维同事第一反应是查监控，CPU、内存、网络都没明显异常，数据库查询也正常。问题似乎出在应用内部。
我们立刻登录日志系统，想看看有没有错误堆栈或异常请求，结果发现当前日志级别是 INFO，大量常规操作日志刷屏，真正可疑的调用链被淹没了。这时候才意识到：平时为了减少日志存储开销，把级别设得太高了，关键时刻反而看不清问题。
临时提升日志级别定位问题
我们决定临时将服务的日志级别从 INFO 调整为 DEBUG。这个服务基于 Spring Boot，配置方式很简单。通过修改配置中心的参数：
logging.level.com.zhiyitong.service=DEBUG配置推送后，服务自动加载新配置（借助 Spring Cloud Config + @RefreshScope），很快就在日志中捕捉到一个频繁出现的远程调用慢请求，最终定位到是第三方天气 API 在高峰时段响应延迟升高。
动态调整避免重启服务
很多人习惯改完配置就重启服务，但在生产环境这太冒险。我们用的是 Logback + Spring Boot Actuator 的组合，支持运行时动态调整日志级别。通过调用 actuator 的 endpoint：
POST /actuator/loggers/com.zhiyitong.service
{"configuredLevel": "DEBUG"}这样不用重启，几秒内就能生效。问题解决后，再调回 INFO，避免长时间输出过多 DEBUG 日志影响性能和磁盘。
建立日常日志策略
这次事件后，我们做了两件事：一是对不同模块设置差异化日志级别，核心交易保持 INFO，外围模块可设为 WARN；二是建立了“问题期间自动升級日志级别”的预案，配合告警系统触发，让日志更聪明地配合排障。
日志不是越详细越好，也不是越安静越好。关键是在需要的时候，能迅速拿到想要的信息。服务配置日志级别调整，看似是个小操作，真到了关键时刻，可能就是排查效率的分水岭。