SpringBoot使用logback输出日志并打印sql信息 --经典---

爱被打了一巴掌 2023-02-28 05:39 12阅读 0赞

最近在学习springboot以及一些springcloud插件的使用，其中发现默认的配置并不能打印一些有用的日志，所以需要自定义一些日志输出方式以便于查看日志排查问题，目前只整理了两种使用方式，如下：

1 简单日志配置  
默认情况下spring boot使用Logback作为日志实现的框架，其内部使用Commons Logging来记录日志，同时也保留外部接口可以让一些日志框架来进行实现，  
例如Java Util Logging,Log4J2还有Logback，如果你想用某一种日志框架来进行实现的话，就必须先配置。  
其中最基础的日志配置就在在resources（即classpath路径）下面创建一个属性文件：application.properties。  
1.1 配置控制台日志的level（级别）  
默认情况下，spring boot从控制台打印出来的日志级别只有ERROR, WARN 还有INFO，如果你想要打印debug级别的日志，可以通过application.properites配置debug=true  
1.2 可以通过logging.level.\*配置自定义包的日志输出级别  
logging.level.root=INFO  
logging.level.org.springframework.web=DEBUG  
logging.level.org.hibernate=ERROR  
1.3 默认情况下spring boot是不将日志输出到日志文件中，但我们可以配置将日志输出到指定的文件中  
logging.file=文件名称  
logging.path=文件路径  
小提示：在生产环境环境下，你可以通过命令行进行配置日志的debug级别-->java -jar C:\\Users\\Administrator\\Desktop\\xx\\demo.jar --debug  
这里需要注意几点：  
这里若不配置具体的包的日志级别，日志文件信息将为空  
若只配置logging.path，那么将会在F:\\demo文件夹生成一个日志文件为spring.log（ps：该文件名是固定的，不能更改）。如果path路径不存在，会自动创建该文件夹  
若只配置logging.file，那将会在项目的当前路径下生成一个demo.log日志文件。这里可以使用绝对路径如，会自动在e盘下创建文件夹和相应的日志文件。  
logging.file=e:\\\\demo\\\\demo.log  
logging.path和logging.file同时配置，不会在这个路径有F:\\demo\\demo.log日志生成，logging.path和logging.file不会进行叠加（要注意）  
logging.path和logging.file的value都可以是相对路径或者绝对路径

example:

> 1.  `#采用Logback日志框架输出日志`
> 2.   
> 3.  `#在生产环境环境下，你可以通过命令行进行配置日志的debug级别`
> 4.  `#java -jar C:\Users\Administrator\Desktop\xx\demo.jar --debug`
> 5.   
> 6.  `#默认情况下，spring boot从控制台打印出来的日志级别只有ERROR, WARN 还有INFO，如果你想要打印debug级别的日志，可以通过application.properites配置debug=true`
> 7.  `debug=true`
> 8.   
> 9.  `#配置logging.level.*来具体输出哪些包的日志级别`
> 10. `logging.level.org.springframework.web=DEBUG`
> 11. `logging.level.com.xuexin.xcloud.print.service.mapper=DEBUG`
> 12.  
> 13. `#将日志输出到文件中`
> 14. `#默认情况下spring boot是不将日志输出到日志文件中，但你可以通过在application.properites文件中配置logging.file文件名称和logging.path文件路径，将日志输出到文件中`
> 15. `logging.file=./xcloud-print.log`
> 16. `#logging.path=F:\\demo`
> 17.

2.使用logback日志框架  
logback日志框架官网：http://logback.qos.ch  
2.1 logback日志框架的简介（摘自官网-->英文不好凑合看吧）  
Logback is intended as a successor to the popular log4j project, picking up where log4j leaves off.  
(Logback旨在作为受欢迎的log4j项目的继承者，它拾起log4j离开的地方。)  
Logback's architecture is sufficiently generic so as to apply under different circumstances. At present time, logback is divided into three modules, logback-core, logback-classic and logback-access.  
(Logback的架构是非常通用的，以便在不同的情况下应用。目前，logback分为三个模块：logback-core，logback-classic和logback-access。)  
The logback-core module lays the groundwork for the other two modules. The logback-classic module can be assimilated to a significantly improved version of log4j. Moreover, logback-classic natively implements the SLF4J API so that you can readily switch back and forth between logback and other logging frameworks such as log4j or java.util.logging (JUL).  
(对数核心模块为其他两个模块奠定了基础。logback-classic模块可以被同化到显着改进的log4j版本。此外，logback-classic本机实现了SLF4J API，以便您可以轻松地在logback和log4j或java.util.logging（JUL）之类的日志记录框架之间来回切换。)  
The logback-access module integrates with Servlet containers, such as Tomcat and Jetty, to provide HTTP-access log functionality. Note that you could easily build your own module on top of logback-core.  
(回溯访问模块与Servlet容器（如Tomcat和Jetty）集成，以提供HTTP访问日志功能。请注意，您可以轻松地在logback-core之上构建自己的模块。)  
2.2 从log4j切换到logback上的原因（摘自官网）  
1、更快的实现  Logback的内核重写了，在一些关键执行路径上性能提升10倍以上。而且logback不仅性能提升了，初始化内存加载也更小了。  
2、非常充分的测试  Logback经过了几年，数不清小时的测试。Logback的测试完全不同级别的。在作者的观点，这是简单重要的原因选择logback而不是log4j。  
3、Logback-classic非常自然实现了SLF4j    Logback-classic实现了 SLF4j。在使用SLF4j中，你都感觉不到logback-classic。而且因为logback-classic非常自然地实现了SLF4J，  所 以切换到log4j或者其他，非常容易，只需要提供成另一个jar包就OK，根本不需要去动那些通过SLF4JAPI实现的代码。  
4、非常充分的文档  官方网站有两百多页的文档。  
5、自动重新加载配置文件  当配置文件修改了，Logback-classic能自动重新加载配置文件。扫描过程快且安全，它并不需要另外创建一个扫描线程。这个技术充分保证了应用程序能跑得很欢在JEE环境里面。  
6、Lilith   Lilith是log事件的观察者，和log4j的chainsaw类似。而lilith还能处理大数量的log数据 。  
7、谨慎的模式和非常友好的恢复  在谨慎模式下，多个FileAppender实例跑在多个JVM下，能 够安全地写道同一个日志文件。RollingFileAppender会有些限制。Logback的FileAppender和它的子类包括 RollingFileAppender能够非常友好地从I/O异常中恢复。  
8、配置文件可以处理不同的情况   开发人员经常需要判断不同的Logback配置文件在不同的环境下（开发，测试，生产）。而这些配置文件仅仅只有一些很小的不同，可以通过,和来实现，这样一个配置文件就可以适应多个环境。  
9、Filters（过滤器）  有些时候，需要诊断一个问题，需要打出日志。在log4j，只有降低日志级别，不过这样会打出大量的日志，会影响应用性能。在Logback，你可以继续 保持那个日志级别而除掉某种特殊情况，如alice这个用户登录，她的日志将打在DEBUG级别而其他用户可以继续打在WARN级别。要实现这个功能只需 加4行XML配置。可以参考MDCFIlter 。  
10、SiftingAppender（一个非常多功能的Appender）  它可以用来分割日志文件根据任何一个给定的运行参数。如，SiftingAppender能够区别日志事件跟进用户的Session，然后每个用户会有一个日志文件。  
11、自动压缩已经打出来的log  RollingFileAppender在产生新文件的时候，会自动压缩已经打出来的日志文件。压缩是个异步过程，所以甚至对于大的日志文件，在压缩过程中应用不会受任何影响。  
12、堆栈树带有包版本  Logback在打出堆栈树日志时，会带上包的数据。  
13、自动去除旧的日志文件  通过设置TimeBasedRollingPolicy或者SizeAndTimeBasedFNATP的maxHistory属性，你可以控制已经产生日志文件的最大数量。如果设置maxHistory 12，那那些log文件超过12个月的都会被自动移除。  
总之，logback比log4j太优秀了，让我们的应用全部建立logback上吧 ！  
2.3 Logback配置  
Logback可以以编程方式配置，也可以配置为以XML或Groovy格式表示的配置脚本。顺便说一下，现有的log4j用户可以使用我们的 PropertiesTranslator Web应用程序将其log4j.properties文件转换 为logback.xml-->地址：https://logback.qos.ch/translator/  
让我们从讨论初始化步骤开始，尝试配置自己：  
1.Logback尝试在类路径中找到一个名为logback-test.xml 的文件 。  
2.如果没有找到这样的文件，logback尝试在类路径中找到一个名为logback.groovy 的文件 。  
3.如果没有找到这样的文件，它会检查classpath中的文件 logback.xml 。  
4.If no such file is found, service-provider loading facility (introduced in JDK 1.6) is used to resolve the implementation of com.qos.logback.classic.spi.Configurator interface by looking up the file META-INF\\services\\ch.qos.logback.classic.spi.Configurator in the class path. Its contents should specify the fully qualified class name of the desired Configurator implementation  
5.如果以上都不成功，则logback会自动配置，BasicConfigurator 这将导致日志输出被导向控制台。  
java代码使用example:final static Logger logger = LoggerFactory.getLogger(MyApp1.class);logger.info("Entering application.");  
  
  
小提示：  
1.如果您使用Maven，并且将 logback-test.xml放在src / test / resources 文件夹下，Maven将确保它不会包含在生成的工件中。因此，您可以使用不同的配置文件，即测试期间的logback-test.xml，以及生产中的另一个文件，即logback.xml  
2.Logger 可以被分配级别。级别包括：TRACE、DEBUG、INFO、WARN 和 ERROR，定义于 ch.qos.logback.classic.Level类。如果 logger没有被分配级别，那么它将从有被分配级别的最近的祖先那里继承级别。root logger 默认级别是 DEBUG  
3.打印方法决定记录请求的级别。例如，如果 L 是一个 logger 实例，那么，语句 L.info("..")是一条级别为 INFO 的记录语句。记录请求的级别在高于或等于其 logger 的有效级别时被称为被启用，否则，称为被禁用。记录请求级别为 p，其logger的有效级别为 q，只有则当 p>=q时，该请求才会被执行。该规则是 logback 的核心。级别排序为： TRACE < DEBUG < INFO < WARN < ERROR

example:

</div>

<?xml version="1.0" encoding="UTF-8"?>
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        xcloud-print
        
        
        ${LOG_PATH}/${APPDIR}/xcloud-print_log_error.log
        
        ${LOG_PATH}/${APPDIR}/error/xcloud-print_log-error-%d{yyyy-MM-dd}.%i.log
        12MB
        true
        %d{yyyy-MM-dd HH:mm:ss.SSS} %-5level --- [%thread] %logger Line:%-3L - %msg%nutf-8
        errorACCEPTDENY
        
        ${LOG_PATH}/${APPDIR}/xcloud-print_log_warn.log
        
        ${LOG_PATH}/${APPDIR}/warn/xcloud-print_log-warn-%d{yyyy-MM-dd}.%i.log
        12MB
        true
        %d{yyyy-MM-dd HH:mm:ss.SSS} %-5level --- [%thread] %logger Line:%-3L - %msg%nutf-8
        warnACCEPTDENY
        
        ${LOG_PATH}/${APPDIR}/xcloud-print_log_info.log
        
        ${LOG_PATH}/${APPDIR}/info/xcloud-print_log-info-%d{yyyy-MM-dd}.%i.log
        12MB
        true
        %d{yyyy-MM-dd HH:mm:ss.SSS} %-5level --- [%thread] %logger Line:%-3L - %msg%nutf-8
        infoACCEPTDENY
        
        ${LOG_PATH}/${APPDIR}/xcloud-print_log_debug.log
        
        ${LOG_PATH}/${APPDIR}/info/xcloud-print_log-debug-%d{yyyy-MM-dd}.%i.log
        12MB
        true
        %d{yyyy-MM-dd HH:mm:ss.SSS} %-5level --- [%thread] %logger Line:%-3L - %msg%nutf-8
        debugACCEPTDENY
        ${CONSOLE_LOG_PATTERN}
        utf-8
        debug

原文地址：https://blog.csdn.net/long290046464/article/details/73790203