部署在Cloud Foundry的Spring Boot应用日志级别配置更新后自动重置

可能的原因 #

• Actuator修改的日志级别仅存于内存中，当应用触发配置刷新事件（如Spring Cloud Config自动拉取更新、上下文重新加载）时，会从配置源（本地配置文件、Config Server、Cloud Foundry环境变量）重新加载默认的INFO级别。
• Cloud Foundry的Java Buildpack可能通过JAVA_OPTS或环境变量注入了固定的日志级别配置，周期性覆盖应用的内存配置。
• 应用启用了自动配置刷新机制（如@RefreshScope），导致配置被周期性重置。

解决步骤 #

1. 检查并修改持久化配置源 #

通过Cloud Foundry环境变量设置持久化的日志级别，确保应用启动和配置刷新时加载目标级别：

• 执行命令设置环境变量：

  cf set-env <你的应用名> SPRING_LOGGING_LEVEL_ROOT ERROR
  

• 重启应用使配置生效：

  cf restart <你的应用名>
  

  之后再通过Actuator修改级别时，若没有强制的配置源覆盖，修改会保持生效。

2. 排查Buildpack注入的强制配置 #

检查应用的环境变量，确认是否存在Buildpack注入的日志级别参数：

• 执行命令查看环境变量：

  cf env <你的应用名>
  

• 若JAVA_OPTS中包含-Dlogging.level.root=INFO这类参数，需要移除或修改：

  cf set-env <你的应用名> JAVA_OPTS "<原有的JAVA_OPTS内容，移除或替换日志级别参数>"
  

  重启应用生效。

3. 控制配置刷新行为 #

如果应用使用Spring Cloud Config自动刷新，调整刷新策略避免频繁重置：

• 禁用自动刷新（仅在不需要其他配置自动更新时使用）：
  设置环境变量：

  cf set-env <你的应用名> SPRING_CLOUD_CONFIG_REFRESH_ENABLED false
  

• 调整刷新周期，延长触发间隔：

  cf set-env <你的应用名> SPRING_CLOUD_CONFIG_REFRESH_INTERVAL 3600000
  

  单位为毫秒，示例设置为1小时。

4. 自定义日志级别持久化逻辑 #

若需要动态修改且持久化，可编写自定义逻辑：

• 实现LoggingLevelChangeListener，监听Actuator的日志级别修改事件，将修改后的级别写入Cloud Foundry环境变量或外部存储。
• 在应用启动时读取存储的级别，覆盖默认配置。

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