可能看到这个标题，读者会问：要修改日志的级别，不是直接修改log.xxx就好了吗？为何要搞那么复杂呢？所以，先说一下场景，为什么要通过TurboFilter去动态的修改日志级别。我们在使用Java开发各种项目的时候必然的会引入很多框架，这些框架通过堆叠的方式完成所要提供的业务服务（一个服务请求在进入后会在这些框架中兜一圈，然后返回结果），当一个比较底层的框架在处理过程中抛出了异常之后，这个异常会不断的向上传递。这个时候，有的框架直接throw，继续向上抛，而有的在throw之前还会自己打印一下error日志，这就导致了当出现异常的时候，往往会出现一连串类似的错误日志记录。如果对接了错误日志告警，就会出现重复告警的现象。为了解决类似这样的问题，修改源码重新编译最直接，但是不可取。所以希望可以有更好的手段去控制这些已经被编码固化的日志打印信息。当我们使用Logback的时候，TurboFilter就是解决该问题的工具之一。

当我们需要对日志的打印要做一些范围的控制的时候，通常都是通过为各个Appender设置不同的Filter配置来实现。在Logback中自带了两个过滤器实现：ch.qos.logback.classic.filter.LevelFilter和ch.qos.logback.classic.filter.ThresholdFilter，用户可以根据需要来配置一些简单的过滤规则，下面先简单介绍一下这两个原生的基础过滤器。

ch.qos.logback.classic.filter.LevelFilter过滤器的作用是通过比较日志级别来控制日志输出。下面是一个只记录日志级别为ERROR的例子：

通过之前的入门示例，我们已经为trace-1和trace-2引入了Spring Cloud Sleuth的基础模块spring-cloud-starter-sleuth，实现了为各微服务的日志信息中添加跟踪信息的功能。但是，由于日志文件都离散的存储在各个服务实例的文件系统之上，仅仅通过查看日志文件来分析我们的请求链路依然是一件相当麻烦的差事，所以我们还需要一些工具来帮助我们集中的收集、存储和搜索这些跟踪信息。引入基于日志的分析系统是一个不错的选择，比如：ELK平台，它可以轻松的帮助我们来收集和存储这些跟踪日志，同时在需要的时候我们也可以根据Trace ID来轻松地搜索出对应请求链路相关的明细日志。