如何用Spring Logback截断超长日志？解决Elastic搜索性能问题

一、先排查PatternLayout失效原因 #

你配置的%.30msg没生效，核心原因是Spring Boot默认的base.xml已经定义了整套Appender和Logger规则，你自定义的Console Appender要么没被目标Logger关联，要么优先级被默认配置覆盖了。比如base.xml里可能已经有同名的Console Appender，你的配置没替换掉它。

二、有效限制日志长度的方案 #

1. 修复PatternLayout配置，确保生效 #

要让长度限制规则生效，需针对特定日志源（比如产生超大GET请求的REST接口包）单独配置Appender，避免和默认规则冲突：

<include resource="org/springframework/boot/logging/logback/base.xml"/>

<!-- 新增专门用于截断日志的Appender -->
<appender name="LIMITED_LOG" class="ch.qos.logback.core.ConsoleAppender">
    <layout class="ch.qos.logback.classic.PatternLayout">
        <!-- 保留基础日志字段，同时限制msg最大长度为10万字符 -->
        <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %.100000msg%n</Pattern>
    </layout>
</appender>

<!-- 针对产生超大日志的REST接口所在包配置Logger -->
<logger name="com.yourproject.rest.controller" level="INFO" additivity="false">
    <appender-ref ref="LIMITED_LOG"/>
    <!-- 如果需要输出到Elastic对应的Appender，也在这里引用 -->
    <appender-ref ref="ELASTIC_APPENDER"/>
</logger>

<!-- 根Logger保持原有默认配置 -->
<root level="INFO">
    <appender-ref ref="CONSOLE"/>
    <appender-ref ref="FILE"/>
</root>

2. 用TurboFilter提前拦截/截断日志 #

如果某些超长日志本身就不需要完整记录，用TurboFilter在日志生成阶段直接处理，减少性能开销：

<!-- 自定义TurboFilter标记需要截断的日志 -->
<turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter">
    <Marker>TRUNCATE_LARGE</Marker>
    <OnMatch>ACCEPT</OnMatch>
</turboFilter>

<!-- 注册自定义截断转换器 -->
<conversionRule conversionWord="truncatedMsg" 
                converterClass="com.yourproject.logback.TruncatedMsgConverter"/>

<!-- 关联到Elastic的Appender -->
<appender name="ELASTIC_APPENDER" class="...">
    <layout class="ch.qos.logback.classic.PatternLayout">
        <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %truncatedMsg{100000}%n</Pattern>
    </layout>
</appender>

对应的自定义转换器代码：

public class TruncatedMsgConverter extends ClassicConverter {
    private int maxLength = 100000;

    @Override
    public void start() {
        String maxLenStr = getFirstOption();
        if (maxLenStr != null) {
            try {
                maxLength = Integer.parseInt(maxLenStr);
            } catch (NumberFormatException e) {
                addError("无效的最大长度配置：" + maxLenStr, e);
            }
        }
        super.start();
    }

    @Override
    public String convert(ILoggingEvent event) {
        String msg = event.getFormattedMessage();
        if (msg.length() > maxLength) {
            return msg.substring(0, maxLength) + "... [已截断]";
        }
        return msg;
    }
}

3. REST请求日志专项优化 #

• 只记录关键信息：不要直接打印完整的GET请求URL和参数，提取请求ID、接口路径、用户ID等核心字段即可，避免冗余内容。
• 用MDC存储上下文：将请求ID、用户信息放入MDC，日志中仅打印MDC字段，不输出超长参数。
• 调整日志级别：非关键的请求日志，把级别从INFO降为DEBUG，仅在调试时开启，减少生产环境的超大日志量。

三、Elasticsearch侧辅助优化 #

即使截断了日志，也可以在Elastic端进一步优化：

• 对message字段设置ignore_above参数，超过长度的内容自动截断，避免索引体积过大。
• 针对超长字段，合理选择字段类型（比如keyword类型限制长度，或text类型配置精简分词策略）。

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