log4j日志级别

第一部分 脑图 第二部分 知识点总结 （1）市面上的日志框架均采用日志规范（接口）+日志框架（实现类）设计，和JDBC-数据库驱动设计思想相似；使用时只需调用接口API，导入实现类即可 （2）常见日志框架介绍 日志规范——slf4j 日志框架——log4j（旧，已经适配到slf4j）、logback（推荐） 其他日志规范——jcl、Jboss-logging 其他日志框架——jul（java.util.logging）、log4j2、commons-logging Spring默认日志框架是commons-logging、Hibernate默认日志框架是JBoss-logging SpringBoot则选用了slf4j规范+logback日志框架；并通过中间包统一其他日志框架到slf4j规范 SpringBoot在引入其他框架时需要先排除该框架所依赖的日志框架；否则中间包会与引入的日志框架冲突；框架整合时已经帮我们做了 如何让系统中所有的日志框架都统一到slf4j规范： 1，将其他日志框架先排除（maven的exclusion排除） 2，用中间包替换被排除的日志框架 3，导入需要的日志框架，如logback 日志框架切换图： http://www.slf4j.org/manual.html http://www.slf4j.org/legacy.html （3）slf4j

日志记录器(Logger)是日志处理的核心组件。 log4j具有5种正常级别(Level)。 日志记录器(Logger)的可用级别Level (不包括自定义级别 Level)， 以下内容就是摘自log4j API ( http://jakarta.apache.org/log4j/docs/api/index.html ): public static final Level TRACE The TRACE Level designates finer-grained informational events than the DEBUG . Since:1.2.12 static Level DEBUG DEBUG Level指出细粒度信息事件对调试应用程序是非常有帮助的。 static Level INFO INFO level表明 消息在粗粒度级别上突出强调应用程序的运行过程。 static Level WARN WARN level表明会出现潜在错误的情形。 static Level ERROR ERROR level指出虽然发生错误事件，但仍然不影响系统的继续运行。 static Level FATAL FATAL level指出每个严重的错误事件将会导致应用程序的退出。 另外，还有两个可用的特别的日志记录级别: (以下描述来自log4j API http:/

1、日志框架 小张；开发一个大型系统； 1、System.out.println("")；将关键数据打印在控制台；去掉？写在一个文件？ 2、框架来记录系统的一些运行时信息；日志框架 ； zhanglogging.jar； 3、高大上的几个功能？异步模式？自动归档？xxxx？ zhanglogging-good.jar？ 4、将以前框架卸下来？换上新的框架，重新修改之前相关的API；zhanglogging-prefect.jar； 5、JDBC---数据库驱动； 写了一个统一的接口层；日志门面（日志的一个抽象层）；logging-abstract.jar； 给项目中导入具体的日志实现就行了；我们之前的日志框架都是实现的抽象层； 市面上的日志框架； JUL、JCL、Jboss-logging、logback、log4j、log4j2、slf4j.... 左边选一个门面（抽象层）、右边来选一个实现； 日志门面： SLF4J； 日志实现：Logback； SpringBoot：底层是Spring框架，Spring框架默认是用JCL；‘ SpringBoot选用 SLF4j和logback； 2、SLF4j使用 1、如何在系统中使用SLF4j https://www.slf4j.org 以后开发的时候，日志记录方法的调用，不应该来直接调用日志的实现类，而是调用日志抽象层里面的方法；

logback配置 参考 # logback官网 http://logback.qos.ch/manual/index.html # logback新认识(一)：logback主要组件appender、rollingPolicy和triggeringPolicy的使用和理解 http://blog.itcrud.com/blogs/2018/12/logback-first logback配置方式 logback可以编程配置，也可以通过xml或groovy配置文件配置。 classpath下找 logback-test.xml 没找到，classpath下找 logback.groovy 没找到，classpath下找 logback.xml 没找到，classpath下找 META-INF\services\ch.qos.logback.classic.spi.Configurator 文件获取 ch.qos.logback.classic.spi.Configurator 接口的实现类信息。 没找到，使用默认配置类， ch.qos.logback.classic.BasicConfigurator 实例 日志文件滚动 <appender name="pullLog" class="ch.qos.logback.core.rolling.RollingFileAppender">

明天要去学习的 1.学习springBoot的自动装配，并且知道spring是如何自动去加载log4j的流程 https://blog.csdn.net/satomiyo/article/details/100040235 log4j配置文件 了解日志-->slf4j的介绍-->log4j的介绍-->logback的介绍-->springboot中slf4j+log4j的使用-->springboot中slf4j+logback的使用 一、前言 我觉得能够加强自己的开发能力，首先必须学会去配置一些文件，而不是crud。在springBoot项目中，一般会有log4j.properties的配置文件，该配置文件是记录项目中的日志的配置信息。 日志是一个项目中必不可少的灵魂，没有日志的项目是没有灵魂的，因此掌握基础的日志编写是非常有必要的。 二、为什么需要日志 我们最开始使用的是System.out.prinlt()进行输出我们的调代码的信息，用来监控具有什么信息，System.out.println()其实是对业务无关的代码，这些对业务无关的代码都是对业务代码的一些intercupt。 我们必须要明确，日志不仅仅System.out.prinlt(s) ,s的信息，同时日志包括一些额外的上下文，上下文信息是非常重要的，这些信息具有 访问时间、对应的类、行、产生的线程等

目前，java下应用最广泛的日志系统主要就是两个系列: log4j和slf4j+logback 。 其中,slf4j只包含日志的接口，logback只包括日志的具体实现，两者加起来才是一个完整的日志系统。Log4j则同时包含了日志接口和实现。 这两套日志系统之间有可以相互兼容的组件，分别是slf4j-log4j12和 log4j-over-slf4j，引入之后就可以用log4j打出slf4j接口的日志，或者用logback打出log4j接口的日志。 背景知识介绍到这里，再简单说一下标题里提到的问题。问题的现象就是我们在war包里配置了log4j的日志级别为info, 但在catalina里却一直在打大量的debug日志。初看现象肯定很诡异，前期各种研究tomcat配置也没什么头绪。直到磁盘压力太大，去看jstack发现大量进程是等待在Logback代码中，才发现之前关注错了重点。再去具体了解了java下的日志系统后，问题也就很明了了。 先把几个事实摆出来： 1. 打出的debug日志都是用slf4j写的，根据堆栈得知logback具体执行了日志打印 2. logback在无配置文件时默认debug级别 3. 我们的war包中同时包含logback,log4j和slf4j-log4j12 4. Slf4j无法主动选择具体的日志实现 想必看到这里，大家也明白了问题所在。根据我们引入的包

Log4J对系统性能的影响 主要体现： 1、日志输出的目的地，输出到控制台的速度比输出到文件系统的速度要慢。 2、日志输出格式不一样对性能也会有影响，如简单输出布局(SimpleLayout)比格式化输出布局(PatternLayout)输出速度要快。可以根据需要尽量采用简单输出布局格式输出日志信息。 3、日志级别越低输出的日志内容就越多，对系统系能影响很大。 4、日志输出方式的不同，对系统系能也是有一定影响的，采用异步输出方式比同步输出方式性能要高。 5、每次接收到日志输出事件就打印一条日志内容比当日志内容达到一定大小时打印系能要低。 优化方式： 1、组装输出内容之前可对logger的输出级别先进行判断而不要完全依赖log4j控制，因为组装输出日志内容也是要损耗效率的。 //若log4j并未开启info级日志记录，直接返回 if(!monitorLogger.isInfoEnabled()){ return; } 来源： https://www.cnblogs.com/ngrzr/p/11906354.html

https://www.cnblogs.com/hanszhao/p/9754419.html 1.SLF4J(Simple logging Facade for Java) 意思为简单日志门面，它是把不同的日志系统的实现进行了具体的抽象化，只提供了统一的日志使用接口，使用时只需要按照其提供的接口方法进行调用即可，由于它只是一个接口，并不是一个具体的可以直接单独使用的日志框架，所以最终日志的格式、记录级别、输出方式等都要通过接口绑定的具体的日志系统来实现，这些具体的日志系统就有log4j,logback,java.util.logging等，它们才实现了具体的日志系统的功能。 如何使用SLF4J? 既然SLF4J只是一个接口，那么实际使用时必须要结合具体的日志系统来使用，我们首先来看SLF4J和各个具体的日志系统进行绑定时的框架原理图： 其实slf4j原理很简单，他只提供一个核心slf4j api(就是slf4j-api.jar包)，这个包只有日志的接口，并没有实现，所以如果要使用就得再给它提供一个实现了些接口的日志包，比 如：log4j,common logging,jdk log日志实现包等，但是这些日志实现又不能通过接口直接调用，实现上他们根本就和slf4j-api不一致，因此slf4j又增加了一层来转换各日志实现包的使 用，当然slf4j-simple除外。其结构如下：

默认情况下，Spring Boot会用 SLF4J + Logback 来记录日志，并用 INFO 级别输出到控制台。 SLF4J，即简单日志门面（Simple Logging Facade for Java），它可以看做是一个接口框架，并不提供具体的实现，具体的实现由类似于Log4j，Log4j2，Logback等等这样的日志框架去完成。 SLF4J让你的代码独立于任何特定的日志记录API，可以让我们的程序更加的健壮，不会让你因为不同日志的实现而导致的问题去分心。 如果我们在一个Spring Boot 的程序中去使用SLF4J，因为spring-boot-starter中就已经包含了有关slf4j的jar包。我们只需要通过LoggerFactory去获取即可： private static final Logger logger = LoggerFactory.getLogger(ResponseAop.class); 默认情况下，Spring Boot将日志输出到控制台，不会写到日志文件。如果要编写除控制台输出之外的日志文件，则需在application.yml中设置logging.file或logging.path属性。但是这俩属性同时配置的时候，只有logging.file生效！ 生产环境会单独配一个日志文件，如果要在日志文件中读取application.xml中属性要注意

在任何系统中，日志都是非常重要的组成部分，它是反映系统运行情况的重要依据，也是排查问题时的必要线索。绝大多数人都认可日志的重要性，但是又有多少人仔细想过该怎么打日志，日志对性能的影响究竟有多大呢？今天就让我们来聊聊Java日志性能那些事。 说到Java日志，大家肯定都会说要选择合理的日志级别、合理控制日志内容，但是这仅是万里长征第一步……哪怕一些 DEBUG 级别的日志在生产环境中不会输出到文件中，也可能带来不小的开销。我们撇开判断和方法调用的开销，在 Log4J 2.x的性能文档 中有这样一组对比： logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); logger.debug("Entry number: {} is {}", i, entry[i]); 上面两条语句在日志输出上的效果是一样的，但是在关闭 DEBUG 日志时，它们的开销就不一样了，主要的影响在于字符串转换和字符串拼接上，无论是否生效，前者都会将变量转换为字符串并进行拼接，而后者则只会在需要时执行这些操作。Log4J官方的测试结论是两者在性能上能相差两个数量级。试想一下，如果某个对象的 toString() 方法里用了 ToStringBuilder 来反射输出几十个属性时，这时能省下多少资源。 因此，某些仍在使用Log4J