Logback中ROOT级别设为TRACE引发死循环错误，INFO级别无此问题

问题根源 #

当root日志级别设为TRACE时，Couchbase客户端的重试逻辑与日志输出形成了恶性循环：

• TRACE级别的日志覆盖范围：TRACE是Logback的最低级别，会输出所有层级的日志，包括Couchbase客户端内部的调试、追踪类日志。当Couchbase连接失败触发重试机制时，客户端会高频输出BucketOpenRetriedEvent这类重试事件日志。
• 日志IO负载加剧循环：你的配置给root绑定了7个Appender（控制台+6个文件Appender），当root为TRACE时，所有日志会被多个Appender同时处理，IO负载骤增。大量的日志写入操作会占用系统资源，导致Couchbase客户端的重试线程无法正常执行退出逻辑，反而触发更频繁的重试，最终形成死循环。
• INFO级别正常的原因：INFO级别会过滤掉DEBUG、TRACE级别的日志，Couchbase的重试事件日志属于DEBUG级别，不会被输出，因此不会触发日志与重试的恶性循环，应用可以正常终止。

配置中的潜在问题 #

你的Logback配置存在两个加剧问题的点：

1. 多Appender重复处理：root同时绑定了多个不同级别的文件Appender，每个Appender都通过ThresholdFilter过滤日志，但root级别为TRACE时，所有日志会先经过root的级别检查，再被每个Appender的过滤器二次过滤，大量日志被重复处理，IO开销翻倍。
2. Couchbase日志未单独控制：没有单独给Couchbase的包设置日志级别，导致它继承了root的TRACE级别，输出了大量内部调试日志，成为死循环的触发点。

解决方法 #

1. 单独限制Couchbase客户端的日志级别 #

在Logback配置中添加单独的logger配置，避免Couchbase继承root的TRACE级别：

<!-- 单独控制Couchbase日志级别，避免输出大量调试日志 -->
<logger name="com.couchbase" level="INFO" additivity="false">
    <appender-ref ref="CONSOLE"/>
    <appender-ref ref="INFO_FILE"/>
</logger>

这样即使root级别为TRACE，Couchbase的日志也只会输出INFO及以上级别，从根源上减少触发循环的日志量。

2. 优化Appender配置，减少重复IO #

可以用LevelFilter替代多个独立的Appender，或者使用SiftingAppender按级别分文件，减少Appender数量，降低IO开销：

<!-- 示例：单个Appender按级别过滤到不同文件 -->
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
        <fileNamePattern>${LOG_DIR}/${SERVICE_NAME}_%level.log.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
        <maxFileSize>${MAX_FILE_SIZE}</maxFileSize>
        <maxHistory>${MAX_HISTORY}</maxHistory>
    </rollingPolicy>
    <encoder>
        <pattern>${LOG_PATTERN}</pattern>
    </encoder>
</appender>

然后root只需要绑定这个Appender即可，避免多个Appender重复处理日志。

3. 调整Couchbase客户端重试策略 #

在Couchbase客户端配置中设置合理的最大重试次数和重试间隔，避免无限重试：

// 示例：Java客户端配置重试策略
ClusterEnvironment env = ClusterEnvironment.builder()
    .retryStrategy(RetryStrategy.failFast()) // 或者自定义重试次数
    .build();

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