企业官网建设流程全解析

聊到logback，大多数人第一反应就是logback.xml里那几个<appender>标签，会配置个ConsoleAppender、RollingFileAppender，再套个<pattern>格式，就算"会用"了。但真正到了高并发压测、多模块排查、生产环境告警这些场景，你会发现基础配置完全不够看。日志一多就把接口拖慢，线上查问题翻半天找不到一条完整的链路，该记录的隐私信息原样落盘到日志文件里——这些问题都不是改几行配置能解决的。

上一期咱们梳理了logback的核心组件和配置语法，属于"能用"。这期进阶篇，我把自己在生产环境里折腾过的异步日志、MDC链路追踪、过滤器体系、自定义扩展这几个方向整理一遍，还会把丢日志、级别失效、性能倒挂这些坑一起讲清楚。

1. 异步日志的核心机制：队列、丢弃策略与IO瓶颈

1.1 同步日志为什么会在高并发下拖垮服务

先想一个现象：压测的时候把日志级别调到DEBUG，吞吐量直接腰斩；关掉日志，性能又回来了。这不是logback的问题，而是同步IO在执行链条里占据了大量等待时间。

一条同步日志从业务线程发出后，要走完"格式化消息—写缓冲区—磁盘刷盘或网络传输"这条完整链路才算结束。磁盘IO的耗时通常是毫秒级甚至更高，而业务逻辑本身可能只需要几微秒。日志量大时，业务线程会成批地堵在I/O等待上，这就是吞吐量骤降的根因。

异步日志解决的思路很直白：把"写磁盘"这个慢动作交给后台线程，业务线程只负责把日志事件丢进一个内存队列，然后立刻返回继续干正事。

1.2 AsyncAppender和AsyncLogger的真实区别

logback里有两个带"异步"字眼的东西，很多人混着用，但底层逻辑不一样：

• AsyncAppender：它本身不写日志，而是包装另一个具体的Appender。业务线程调用append()时，只是把ILoggingEvent放进一个BlockingQueue，后台线程再从队列取出事件，转交给被包装的FileAppender、RollingFileAppender等真正干活的组件。
• AsyncLogger：这是在Logger层面做异步，事件产生后直接交给另一个线程处理，不需要经过Appender的队列中转。它的实现依赖LMAX Disruptor的无锁环形队列，在极致高并发下的吞吐和延迟表现更好。

实际项目里，AsyncAppender已经能满足绝大多数场景，而且不需要引入额外依赖。AsyncLogger需要单独引入Disruptor依赖，配置方式也不同，适合那些对日志路径耗时极度敏感的中间件场景。

AsyncAppender的典型配置长这样：

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs/app.%d{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender> <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>1024</queueSize> <discardingThreshold>0</discardingThreshold> <neverBlock>true</neverBlock> <maxFlushTime>30000</maxFlushTime> <appender-ref ref="FILE"/> </appender> <root level="INFO"> <appender-ref ref="ASYNC"/> </root>

这套配置里有几个参数直接决定行为边界，我逐一说明。

1.3 queueSize、discardingThreshold、neverBlock、maxFlushTime的参数搭配逻辑

• queueSize：队列容量，默认256。队列越大，抗突发能力越强，但内存占用和退出时的冲刷时间也会增加。一般设1024~2048比较合理，具体看单台实例每秒产生多少条日志。
• discardingThreshold：当队列剩余容量低于这个阈值时，为了优先保证队列不堆积，logback会直接丢弃TRACE、DEBUG、INFO级别的事件，只保留WARN和ERROR。默认值是队列容量的20%。注意，很多人期望"ERROR一条都不能丢"，结果却在极端情况下发现ERROR也消失了。原因就是discardingThreshold没调。如果业务要求关键日志不能丢，直接把discardingThreshold设为0，并配合neverBlock=false。
• neverBlock：队列满了怎么办。默认false表示队列满时业务线程会阻塞等待队列腾出空间，相当于异步退化成同步，但保证了日志不丢。设为true时，队列满就直接丢弃新事件，业务线程永远不会被阻塞，但日志会丢。这个取舍要看你是"日志不能缺"还是"接口延迟不能高"。
• maxFlushTime：应用关闭时，后台线程最多等待多久把队列里的日志全部写完，默认1000ms。如果队列里积压了大量日志，1秒钟很可能不够，JVM退出后日志就静默消失了。我的习惯是设成30000ms，宁可停机慢一点，也要把最后的日志落盘。

从生产实践经验来看：如果你只追求接口性能和吞吐量，discardingThreshold=20%加neverBlock=true是常见选择；如果日志要用于审计、计费、对账，discardingThreshold=0加neverBlock=false才是底线配置。

1.4 异步日志的适用边界：不是所有项目都需要

异步日志听着好，但不是无脑上。如果你的服务每天日志量不到几百MB，同步写盘完全没压力，引入异步反而增加了排查日志时的时序困惑。只有当日志量明显拖慢了接口响应、或者GC压力来自日志对象分配时，才值得改造成异步。

另外有个容易被忽略的点：异步日志模式下，如果服务突然宕机（kill -9或断电），队列里未消费的日志注定丢失，这是架构层面要接受的代价。对需要严格审计的场景，光靠异步队列是不够的，得在业务层面做可靠投递。

2. MDC贯穿链路：从过滤器到线程传递，看日志如何带上“身份证”

2.1 MDC的运行机制和一个最容易踩的坑

MDC（Mapped Diagnostic Context）是logback提供的一个线程局部变量Map，可以往里面放键值对，然后在布局模式里用%X{key}输出。最典型的用途就是请求唯一ID：一个请求进来，生成一个traceId放进MDC，之后这个请求在同一个线程里产生的每一条日志都会带上traceId，排查问题时一条grep就能拉出完整链路。

基础用法：

import org.slf4j.MDC; // 请求入口 String traceId = UUID.randomUUID().toString().replace("-", ""); MDC.put("traceId", traceId); try { // 业务逻辑 log.info("收到订单创建请求, orderId={}", orderId); } finally { MDC.remove("traceId"); }

配合logback配置：

<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} [%X{traceId}] - %msg%n</pattern>

这里有个关键点，很多人在实际项目中踩过：MDC.put()的键值必须成对出现，用完一定要在finally里MDC.remove()。这不是洁癖，而是因为Web容器和线程池会复用线程。上一次请求在ThreadLocal里留下的traceId，如果不清理，下一个请求复用到这个线程时，日志里就会出现别人的traceId，排查时直接精神分裂。

2.2 异步线程里MDC为什么会丢

异步日志和MDC叠加时，问题就来了。当你把业务逻辑丢进线程池执行时，新线程默认不会继承父线程的MDC，因为MDC本身是基于ThreadLocal存储的。

但logback的AsyncAppender在这点上其实做了处理，它的事件对象里存放了MDC快照，后台线程取事件打印时能恢复MDC，所以AsyncAppender里的MDC不会丢。丢MDC的场景主要出现在你自己写的线程池、CompletableFuture、消息消费者这些跨线程执行的地方。

解决方式之一是在任务提交时把父线程的MDC上下文带过去，执行完再清掉。用Spring的TaskDecorator来统一处理比较优雅：

public class MdcTaskDecorator implements TaskDecorator { @Override public Runnable decorate(Runnable runnable) { Map<String, String> contextMap = MDC.getCopyOfContextMap(); return () -> { if (contextMap != null) { MDC.setContextMap(contextMap); } try { runnable.run(); } finally { MDC.clear(); } }; } } ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setTaskDecorator(new MdcTaskDecorator());

MDC.getCopyOfContextMap()是获取当前线程MDC的副本，设置到子线程后，子线程内产生的日志就带上了traceId。finally里的MDC.clear()是防止线程池复用导致上下文互相污染。

实际经验是：在网关层或统一的Filter里生成traceId放MDC，入口和出口都清理干净，比在业务代码里到处手动MDC.put可靠得多。

2.3 MDC值的类型和空值问题

MDC的key和value都是String类型，这个限制很多人会忽略。如果你往里面放了非String对象，编译期不会报错，但运行时会发生ClassCastException。

另外，MDC.put(key, null)在logback里会直接移除这个key，而不是往里放一个null值。这个行为和HashMap完全不同，容易产生"我以为设置了null，实际是删除了"的困惑。如果想表示一个空值状态，建议放空字符串或者约定一个特殊标记，而不是直接放null。

3. 过滤器体系：日志输出前的三道分流闸

3.1 TurboFilter和Appender Filter的分工差异

logback的过滤机制分两层，很多人只见过第二层：

• TurboFilter：在Logger记录事件时就被调用，发生在事件进入Appender之前。它的特点是调用频繁，对性能敏感；同时它可以访问Logger、Level、Message等完整上下文，适合做全局策略。比如DuplicateMessageFilter做重复日志抑制，MDCFilter根据MDC值过滤。
• Appender Filter：挂在某个Appender内部，只对该Appender的事件流生效。这个层级的Filter又分LevelFilter、ThresholdFilter和EvaluatorFilter。

实际项目中最常见的组合是：用TurboFilter做全局级别开关（比如压测时临时关掉某类日志），用EvaluatorFilter在具体Appender上做精细化排除（比如不打印健康检查接口的日志）。

3.2 EvaluatorFilter + JaninoEventEvaluator：表达式过滤实战

EvaluatorFilter是功能最强大的Appender Filter，它配合JaninoEventEvaluator可以写Java表达式来判断是否接受或拒绝某个事件。比如我要在文件Appender里过滤掉所有包含"HEALTH"的日志：

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/app.log</file> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator class="ch.qos.logback.classic.booleans.JaninoEventEvaluator"> <expression>event.getMessage() != null &amp;&amp; event.getMessage().contains("HEALTH")</expression> </evaluator> <onMatch>DENY</onMatch> <onMismatch>NEUTRAL</onMismatch> </filter> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender>

Filter链的处理规则要记牢：onMatch表示表达式成立时怎么处理，onMismatch表示不成立时怎么处理。取值有三类：

• ACCEPT：立即接受该日志，不再进入后续Filter判断。
• DENY：立即拒绝，日志不会出现在该Appender里。
• NEUTRAL：交给链上的下一个Filter判断；如果已经是最后一个Filter，默认放行。

所以上面的配置意味着：只要消息包含"HEALTH"，直接拒绝；其他日志正常输出。

这个表达式里还支持MEC、MCE、MDC等对象，比如可以用MDC值判断某个请求路径：

<expression>mdc.get("requestURI") != null &amp;&amp; mdc.get("requestURI").contains("/health")</expression>

这种方式很适合在线上把健康检查、心跳探测之类的噪音日志剔除出去，又不用改业务代码。

注意，JaninoEventEvaluator依赖Janino库，pom.xml里要加：

<dependency> <groupId>org.codehaus.janino</groupId> <artifactId>janino</artifactId> <version>3.1.10</version> </dependency>

别漏了，漏了启动时直接报ClassNotFoundException。

3.3 用LevelFilter和ThresholdFilter做日志分级存储

有时候需求很简单：INFO以上的日志进一个文件，ERROR以上的进另一个文件，方便告警和问题回溯。这种场景用LevelFilter最直接：

<appender name="ERROR_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/error.log</file> <filter class="ch.qos.logback.classic.filter.LevelFilter"> <level>ERROR</level> <onMatch>ACCEPT</onMatch> <onMismatch>DENY</onMismatch> </filter> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender>

这段配置的含义是"只接受ERROR级别"。INFO进不了这个文件，WARN也进不了，因为onMismatch直接DENY了。

ThresholdFilter则不一样，它是"阈值"概念：<level>WARN</level>表示只接受WARN及以上级别（WARN和ERROR），INFO及以下全部被过滤。

这两个Filter的区别一句话总结：LevelFilter是精确匹配单个级别，ThresholdFilter是范围匹配。

4. 自定义扩展：手写脱敏Converter和推送Appender

4.1 自定义Converter：解决日志脱敏的通用方案

日志脱敏是个高频需求，手机号、身份证号、银行卡号不能原样打到日志文件里。虽然可以在业务代码里手动脱敏后再输出，但漏网之鱼太多。更可靠的方式是写一个自定义Converter，在日志格式化阶段统一处理。

实现思路是继承ClassicConverter，重写convert()方法，对event.getFormattedMessage()做正则替换，然后注册成一个新的转换符：

import ch.qos.logback.classic.pattern.ClassicConverter; import ch.qos.logback.classic.spi.ILoggingEvent; import java.util.regex.Matcher; import java.util.regex.Pattern; public class MaskConverter extends ClassicConverter { private static final Pattern PHONE_PATTERN = Pattern.compile("1[3-9]\\d{9}"); @Override public String convert(ILoggingEvent event) { String message = event.getFormattedMessage(); Matcher matcher = PHONE_PATTERN.matcher(message); if (matcher.find()) { return matcher.replaceAll("138****0000"); } return message; } }

然后在配置里声明这个转换符：

<conversionRule conversionWord="mask" converterClass="com.example.log.MaskConverter"/> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/app.log</file> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %mask%n</pattern> </encoder> </appender>

之后日志里凡是匹配到手机号格式的内容，都会自动替换成脱敏串。这个方法的好处是业务代码零改动，新增脱敏规则也只改Converter类。

实际要注意：这个方案只能脱敏格式化后的最终消息，如果脱敏规则与参数的位置、类型强相关（比如"第3个参数必须是手机号"），那就得在业务层做结构化处理。另外，正则规则不能太宽，否则会把正常的数字串误伤。我自己还会加一层对Trace ID、请求流水号这类敏感业务标识的脱敏规则。

4.2 自定义Appender：把日志送进告警通道

有些场景日志不只往文件里写，还要主动推送。比如ERROR日志触发企业微信群机器人告警，或者把关键日志写入Kafka供下游消费。这些也可以靠复用来做，但自己写一个Appender并不难。

实现AppenderBase<ILoggingEvent>，重写append()方法即可：

import ch.qos.logback.core.AppenderBase; import ch.qos.logback.classic.spi.ILoggingEvent; public class WebhookAppender extends AppenderBase<ILoggingEvent> { private String webhookUrl; @Override protected void append(ILoggingEvent event) { // 只处理ERROR级别 if (!event.getLevel().toString().equals("ERROR")) { return; } String message = event.getFormattedMessage(); // 发送到企业微信/钉钉群机器人 // 这里建议用独立的线程池异步发送，不要阻塞日志线程 } public String getWebhookUrl() { return webhookUrl; } public void setWebhookUrl(String webhookUrl) { this.webhookUrl = webhookUrl; } }

配置里直接写：

<appender name="WEBHOOK" class="com.example.log.WebhookAppender"> <webhookUrl>https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxx</webhookUrl> <filter class="ch.qos.logback.classic.filter.LevelFilter"> <level>ERROR</level> <onMatch>ACCEPT</onMatch> <onMismatch>DENY</onMismatch> </filter> </appender>

自定义Appender最容易犯的错误是在append()方法里做重操作：发起HTTP请求、写数据库、同步调用外部接口。因为append()是业务线程在调用，一个慢请求就会把整个日志链路和业务线程一起拖住。我的做法是：append()里只做简单判断和入队，真正的外部调用放到内部线程池里；同时要加超时控制、熔断和失败降级，否则告警机器人接口一抖动，反而拖垮业务进程。

4.3 通过代码动态调整日志级别

配置文件里的级别是"写死"的，但线上排查问题的时候经常需要临场把某个包的级别调到DEBUG几分钟，看完了再调回去。用logback.xml改完还要reload，麻烦且不可控。更推荐的方式是通过代码动态调整：

import ch.qos.logback.classic.Level; import ch.qos.logback.classic.LoggerContext; import org.slf4j.LoggerFactory; public void setLogLevel(String loggerName, String level) { LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory(); ch.qos.logback.classic.Logger logger = context.getLogger(loggerName); logger.setLevel(Level.valueOf(level)); }

对Logger.ROOT_LOGGER_NAME（即root）设置整体级别，对具体的包路径设置局部级别。Spring Boot Actuator暴露的/loggers端点本质也是在做这件事。如果你有配置中心，还可以把"哪个包什么级别"做成动态配置，调整时实时刷新，这对定位线上问题帮助非常大。

5. 高频事故现场：日志丢失、顺序错乱、级别失效

5.1 日志丢失：多半是队列参数背锅

生产环境最怕"关键日志没了"。异步日志模式下，日志丢失有三种常见原因：

第一种是discardingThreshold导致的丢弃。日志量突发增长，队列快要满时，logback会优先丢弃低级别日志。如果此时业务故障恰恰产生大量INFO日志用于排查，等你想看的时候已经没了。对策是把discardingThreshold设为0，或者按5.1节间歇设置。

第二种是neverBlock=true加队列满，新日志直接进不了队。这本质上是容量规划问题。我见过一次线上故障：错误日志每秒产生几千条，队列设了512，neverBlock=true，结果告警短信收到一堆"队列已满，日志被丢弃"的提示，真正的故障日志反而没记下来。

第三种是应用关闭时maxFlushTime设置太短。K8s滚动更新或发布重启时，队列里的日志还没来得及消费完，JVM就退出了。正常现象看起来是"每次重启后，最后几十秒的日志消失了"。把maxFlushTime调大，并在应用关闭流程里预留足够时间，能明显改善。

5.2 日志顺序错乱：先搞清楚"顺序"本来就不存在

有人用了AsyncAppender后发现日志时间戳和实际打印顺序对不上，觉得是bug。这里要泼一盆冷水：多线程业务在同步模式下，日志顺序也是不保证的！磁盘IO调度、线程调度、锁竞争都会导致先出发的日志晚落盘。

异步模式只是把这个无序性问题放大了一点。真正需要关心的是"同一个线程内的业务日志顺序"是否保持。AsyncAppender的BlockingQueue是FIFO的，后台线程按队列顺序消费，所以单线程内的事件进入队列的顺序和消费顺序一致。如果想确认某条链路内日志的先后关系，建议在MDC里放一个自增序号，或者依赖时间戳和thread名一起判断。

5.3 日志级别失效：检查additivity和继承关系

级别不对，除了配置本身写错，还有一个隐蔽原因是additivity=false。additivity控制的是"是否把日志继续向上传递给祖先Logger"。

有的团队为了让某个子包只输出到独立文件，把子Logger的additivity设为false，并配置了独立的Appender，但忘了给它设置Level。结果子Logger继承了root的输出级别，而root又设置了某个Appender，导致子包的日志同时打印了两份，一份进独立文件，一份进root的Appender，看着就像"级别设置没生效"。排查的时候先用LoggerContext在代码里打印每个Logger的实际配置和继承关系，比猜配置快得多。

还有一个常见问题：从配置文件里改了级别，但应用没重启，代码里却是用旧的LoggerContext在跑。logback在启动时加载配置，之后的代码修改如果直接改配置文件而不触发reload，是不会生效的。解决方式是设置<configuration scan="true" scanPeriod="30 seconds"/>，让logback自动监听配置文件变更并重新加载。

6. 落地取舍：格式化开销优化与我的默认配置

6.1 最常见的性能杀手：%class、%method、%line

Pattern里有很多转换符，但开销天差地别：

• %msg、%n、%d：基本是廉价操作。
• %thread、%level：代价很小。
• %logger：会做包名缩写，代价中等。
• %class、%method、%line：这三个是性能杀手。因为它们要求logback生成调用栈信息StackTraceElement，而生成栈信息是非常昂贵的操作，在高并发下日志吞吐量会明显下降。

这就是为什么很多生产配置里，Pattern只保留%logger{36}而不是%class。我自己线上默认格式是：

%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} [%X{traceId}] - %msg%n

保留%logger{36}是为了定位代码模块，去掉%line是为了性能。如果你确实需要定位到具体代码行，建议只在开发、测试环境开启，生产环境用Logger名+MDC里的业务标识来定位。

6.2 用isXxxEnabled避免无谓的格式化开销

这类开发习惯的性能收益被低估了。比如某段循环里打印大量DEBUG日志，但当前级别是INFO，这时如果直接写log.debug("用户信息={}", user)，logback仍然会执行字符串拼接——因为它要先构造参数数组和消息模板，再判断级别是否允许输出。在高频调用下，这种浪费是实打实的。

正确的写法是先用级别判断包一层：

if (log.isDebugEnabled()) { log.debug("用户信息={}", user); }

注意要在循环外部做判断，避免每次循环都判断。另外，logback的占位符{}本身有延迟求值的优化，参数是引用传递的，但如果参数是字符串拼接表达式，依然会先执行拼接。所以传入对象引用，不要传拼接好的字符串。

经验法则：在性能敏感的循环或高频调用路径上，先判断级别再打日志；普通业务代码可以放心使用占位符。

6.3 配置自动加载和异步搭配方案

最后给出一套我实践中比较顺手的基础模板，可直接参考：

<configuration scan="true" scanPeriod="30 seconds"> <conversionRule conversionWord="mask" converterClass="com.example.log.MaskConverter"/> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs/app.%d{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} [%X{traceId}] - %mask%n</pattern> </encoder> </appender> <appender name="ERROR_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/error.log</file> <filter class="ch.qos.logback.classic.filter.LevelFilter"> <level>ERROR</level> <onMatch>ACCEPT</onMatch> <onMismatch>DENY</onMismatch> </filter> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs/error.%d{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender> <appender name="ASYNC-FILE" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>2048</queueSize> <discardingThreshold>0</discardingThreshold> <neverBlock>false</neverBlock> <maxFlushTime>30000</maxFlushTime> <appender-ref ref="FILE"/> </appender> <root level="INFO"> <appender-ref ref="ASYNC-FILE"/> <appender-ref ref="ERROR_FILE"/> </root> </configuration>

这套配置的思路是：全量日志走异步文件，ERROR单独落一份同步文件用于告警和快速检索；traceId必须在格式里，脱敏Converter挂上。关于异步的那份，我之所以把discardingThreshold设为0，是因为在日志审计场景里"不丢"比"不阻塞"更重要；如果你更在意的是接口延迟，可以回调neverBlock=true。

最后再分享一个我个人的习惯：每次调整完日志配置，不要只盯着"有没有生效"，而是主动去验证三件事——打几条不同级别的日志确认输出正常，压一下最高日志流量看队列水位和丢失量，以及观察日志文件里有没有出现脱敏不了的数据格式。日志框架这东西平时默默无闻，出了问题才觉得它重要，所以把配置和参数吃透，省下的都是深夜排查的命。