Fork me on GitHub

日志框架面试题

发表于 | 分类于 | 阅读次数:
字数统计: 2,568 字 | 阅读时长 ≈ 10 分钟

更快的执行速度

基于我们先前在log4j上的工作，logback 重写了内部的实现，在某些特定的场景上面，甚至可以比之前的速度快上10倍。在保证logback的组件更加快速的同时，同时所需的内存更加少。

充分的测试

Logback 历经了几年，数不清小时数的测试。尽管log4j也是测试过的，但是Logback的测试更加充分，跟log4j不在同一个级别。我们认为，这正是人们选择Logback而不是log4j的最重要的原因。人们都希望即使在恶劣的条件下，你的登录依然稳定而可靠。

logback-classic 非常自然的实现了SLF4J

logback-classic中的登陆类自然的实现了SLF4J。当你使用logback-classic作为底层实现时，涉及到LF4J日记系统的问题你完全不需要考虑。更进一步来说，由于 logback-classic强烈建议使用SLF4J作为客户端日记系统实现，如果需要切换到log4j或者其他，你只需要替换一个jar包即可，不需要去改变那些通过

SLF4J API 实现的代码。这可以大大减少更换日记系统的工作量。

自动重新载入配置文件

Logback-classic可以在配置文件被修改后，自动重新载入。这个扫描过程很快，无资源争用，并且可以动态扩展支持在上百个线程之间每秒上百万个调用。它和应用服务器结合良好，并且在JEE环境通用，因为它不会调用创建一个单独的线程来做扫描。

优雅地从I/O错误中恢复

FileAppender和它的子类，包括RollingFileAppender，可以优雅的从I/O错误中恢复。所以，如果一个文件服务器临时宕机，你再也不需要重启你的应用，而日志功能就能正常工作。当文件服务器恢复工作，logback相关的appender就会透明地和快速的从上一个错误中恢复。

自动清除旧的日志归档文件

通过设置TimeBasedRollingPolicy 或者 SizeAndTimeBasedFNATP的 maxHistory 属性，你就可以控制日志归档文件的最大数量。如果你的回滚策略是每月回滚的，并且你希望保存一年的日志，那么只需简单的设置maxHistory属性为12。对于12个月之前的归档日志文件将被自动清除。

自动压缩归档日志文件

RollingFileAppender可以在回滚操作中，自动压缩归档日志文件。压缩通常是异步执行的，所以即使是很大的日志文件，你的应用都不会因此而被阻塞。

谨慎模式

在谨慎模式中，在多个JVM中运行的多个FileAppender实例，可以安全的写入统一个日志文件。谨慎模式可以在一定的限制条件下应用于RollingFileAppender。

Lilith

Lilith是logback的一个记录和访问事件查看器。它相当于log4j的 chainsaw，但是Lilith设计的目的是处理大量的日志记录。

配置文件中的条件处理

开发者通常需要在不同的目标环境中变换logback的配置文件，例如开发环境，测试环境和生产环境。这些配置文件大体是一样的，除了某部分会有不同。为了避免重复，logback支持配置文件中的条件处理，只需使用,和，那么同一个配置文件就可以在不同的环境中使用了。

过滤

Logback拥有远比log4j更丰富的过滤能力。例如，让我们假设，有一个相当重要的商业应用部署在生产环境。考虑到大量的交易数据需要处理，记录级别被设置为WARN，那么只有警告和错误信息才会被记录。现在，想象一下，你在开发环境遇到了一个臭虫，但是在测试平台中却很难发现，因为一些环境之间(生产环境/测试环境)的未知差异。

使用log4j，你只能选择在生产系统中降低记录的级别到DEBUG，来尝试发现问题。但是很不幸，这会生成大量的日志记录，让分析变得困难。更重要的是，多余的日志记录会影响到生产环境的性能。

使用logback，你可以选择保留只所有用户的WARN级别的日志，而除了某个用户，例如Alice，而她就是问题的相关用户。当Alice登录系统，她就会以DEBUG级别被记录，而其他用户仍然是以WARN级别来记录日志。这个功能，可以通过在配置文件的XML中添加4行。请在相关章节中查找MDCFilter

SiftingAppender

SiftingAppender是一个全能的追加器。它可以基于任何给定的实时属性分开（或者筛选）日志。例如，SiftingAppender可以基于用户会话分开日志事件，这样，可以为每一个用户建立一个独立的日志文件。

堆栈轨迹信息包含包的数据

当logback打印一个异常，堆栈轨迹信息将包含包的相关数据。下面是一个通过 logback-demo 生成的堆栈信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14:28:48.835 [btpool0-7] INFO  c.q.l.demo.prime.PrimeAction - 99 is not a valid value
java.lang.Exception: 99 is invalid
  at ch.qos.logback.demo.prime.PrimeAction.execute(PrimeAction.java:28) [classes/:na]
  at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) [struts-1.2.9.jar:1.2.9]
  at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) [struts-1.2.9.jar:1.2.9]
  at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) [struts-1.2.9.jar:1.2.9]
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) [jetty-6.1.12.jar:6.1.12]
  at ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44) [classes/:na]
  at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) [jetty-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) [jetty-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) [jetty-6.1.12.jar:6.1.12]

从上面的信息，你可以发现这个应用使用Struts 1.2.9 而且是使用 jetty 6.1.12部署的。所以，堆栈轨迹信息将快速的告诉读者，关于异常发生的类还有包和包的版本。当你的客户发送一个堆栈轨迹信息给你，作为一个开发人员，你就不需要让他们告诉你他们正在使用的包的版本。这项信息已经包括在堆栈轨迹信息中。详细请参考 “%xThrowable” conversion word.

这项功能可以非常有帮助的说明，有些用户误以为这是IDE的功能。

Log-back-access模块，提供了通过HTTP访问日志的能力，是logback不可或缺的部分

最后但绝非最不重要的是，作为logback发布包的一部分，logback-access模块可与Jetty或者Tomcat进行集成，提供了非常丰富而强大的通过HTTP访问日志的功能。因为logback-access模块是logback初期设计方案中的一部分，因此，所有你所喜欢的logback-classic模块所提供的全部特性logback-access同样也具备。

logback的优点

  • 内核重写、测试充分、初始化内存加载更小，这一切让logback性能和log4j相比有诸多倍的提升
  • logback非常自然地直接实现了slf4j，这个严格来说算不上优点，只是这样，再理解slf4j的前提下会很容易理解logback，也同时很容易用其他日志框架替换logback
  • logback有比较齐全的200多页的文档
  • logback当配置文件修改了，支持自动重新加载配置文件，扫描过程快且安全，它并不需要另外创建一个扫描线程
  • 支持自动去除旧的日志文件，可以控制已经产生日志文件的最大数量

logback加载

我们简单分析一下logback加载过程，当我们使用logback-classic.jar时，应用启动，那么logback会按照如下顺序进行扫描：

  • 在系统配置文件System Properties中寻找是否有logback.configurationFile对应的value
  • 在classpath下寻找是否有logback.groovy（即logback支持groovy与xml两种配置方式）
  • 在classpath下寻找是否有logback-test.xml
  • 在classpath下寻找是否有logback.xml

以上任何一项找到了，就不进行后续扫描，按照对应的配置进行logback的初始化，具体代码实现可见ch.qos.logback.classic.util.ContextInitializer类的findURLOfDefaultConfigurationFile方法。

当所有以上四项都找不到的情况下，logback会调用ch.qos.logback.classic.BasicConfigurator的configure方法，构造一个ConsoleAppender用于向控制台输出日志，默认日志输出格式为”%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n”。

logback的configuration

logback的重点应当是Appender、Logger、Pattern，在这之前先简单了解一下logback的，只有三个属性：

  • scan：当scan被设置为true时，当配置文件发生改变，将会被重新加载，默认为true
  • scanPeriod：检测配置文件是否有修改的时间间隔，如果没有给出时间单位，默认为毫秒，当scan=true时这个值生效，默认时间间隔为1分钟
  • debug：当被设置为true时，将打印出logback内部日志信息，实时查看logback运行信息，默认为false

与

先从最基本的与开始。

用来设置某一个包或者具体某一个类的日志打印级别、以及指定。可以包含零个或者多个元素，标识这个appender将会添加到这个logger。仅有一个name属性、一个可选的level属性和一个可选的additivity属性：

  • name：用来指定受此logger约束的某一个包或者具体的某一个类
  • level：用来设置打印级别，五个常用打印级别从低至高依次为TRACE、DEBUG、INFO、WARN、ERROR，如果未设置此级别，那么当前logger会继承上级的级别
  • additivity：是否向上级logger传递打印信息，默认为true

也是元素，但是它是根logger，只有一个level属性，因为它的name就是root。

坚持原创技术分享，您的支持将鼓励我继续创作！