建设银行衡阳市分行网站,手机网站开发需求 百度云盘,国内外高校门户网站建设,北京公司核名工商官网背景
在Java系统实现过程中#xff0c;我们不可避免地会借助大量开源功能组件。然而#xff0c;这些组件往往功能丰富且体系庞大#xff0c;官方文档常常详尽至数百页。而在实际项目中#xff0c;我们可能仅需使用其中的一小部分功能#xff0c;这就造成了一个挑战#…背景
在Java系统实现过程中我们不可避免地会借助大量开源功能组件。然而这些组件往往功能丰富且体系庞大官方文档常常详尽至数百页。而在实际项目中我们可能仅需使用其中的一小部分功能这就造成了一个挑战如何在有限的时间和精力下高效地掌握并使用这些组件的核心功能以实现投入产出最大化
针对这一问题我基于二八原则整理编写本文。
首先我会聚焦于组件的常见和核心功能这些功能通常是我们在日常开发中频繁使用到的也是构建稳定、高效系统的基石。通过深入了解这些核心功能的使用方法和最佳实践我们可以确保在关键点上投入足够的精力从而避免在实际使用中掉入陷阱。
其次我会以问题为导向将实用性作为第一要素对组件的功能进行筛选和整理。这意味着我会优先关注那些在项目中实际需要用到的功能而对于那些特定场景下才会用到的功能我会在文中提及但不做详细展开。这样做的好处是我们可以在保证核心功能得到充分理解的同时减少不必要的阅读负担提高学习效率降低投入成本。
最后我会注重内容的精炼和易读性。通过简明扼要的文字描述和直观的示例代码帮助读者快速理解并掌握组件的核心用法。
同时我也会结合经验指出常见的问题和注意事项以便读者在使用过程中能够规避一些常见的错误和陷阱。
综上所述通过这个系列的内容整理我希望能够帮助读者在有限的时间和精力下高效地掌握并使用这些开源功能组件的核心功能满足系统实现的需要。
注部分内容章节由AI辅助生成草稿我对其进行了复核和修订修复了有问题和有错误的部分。
理论
日志有什么用
在Java开发中日志记录是一个不可或缺的部分。它能帮助我们了解程序的运行状态追踪和定位代码中的错误。特别是在生产环境异常排查日志是非常重要的手段甚至某些情况下是唯一的途径。
日志级别有哪些
在Java开发中日志级别是一个重要的概念。
常见的日志级别由低到高分别为TRACE、DEBUG、INFO、WARN、ERROR和FATAL。
每个级别都对应着不同的日志输出内容和场景。
例如TRACE级别通常用于记录详细的程序执行流程而ERROR级别则用于记录程序运行时的错误信息。
主流的日志组件有哪些
日志功能具有通用性与具体的业务系统无关因此诞生了众多的日志组件我们不需要也不应该去重复“造轮子”而是拿来使用。
在选择和集成日志组件时我们需要考虑组件的性能、稳定性以及兼容性等因素。当前主流在使用的日志组件主要有两个一是logback二是log4j2。这些组件都提供了丰富的功能和灵活的配置选项可以根据项目的需求进行选择。
什么是日志门面
虽然我们也可以直接使用上面说的logback或log4j2但更好的方式是使用日志门面组件。
在Java中SLF4JSimple Logging Facade for Java是一个为Java程序提供日志输出的简单门面或抽象层。它提供了一套统一的日志接口使得开发者可以无需关心具体日志实现并可以轻松切换日志组件。
注这里虽然称之为门面但使用到的设计模式并不是门面模式而是适配器模式。
SLF4J的主要特点和优势是什么
SLF4J的主要特点和优势包括
统一的日志接口SLF4J为各种日志组件提供了统一的调用方式从而简化了日志记录的过程。
灵活性由于SLF4J是一个抽象层它可以与多种日志实现组件如Logback、Log4j2等集成。这意味着即使更改底层日志实现应用程序代码也不需要做出任何更改。
参数化日志SLF4J提供了参数化日志功能这有助于减少字符串拼接操作从而提高了日志记录的效率。
易于使用和学习SLF4J的API设计得相对简洁降低了学习成本并且无需复杂的配置。
SLF4J的应用场景有哪些
在项目中SLF4J的应用场景包括但不限于
为开发者提供统一的日志接口减少开发过程中的代码侵入性。
结合不同的日志组件实现对日志进行定制输出。
替换不同的日志组件使得日志输出更易于管理和控制。
SLF4J是一个非常有用的工具它可以帮助开发人员更好地管理和记录应用程序的日志。
实战
如何引入SLF4J
在Maven项目中你可以在pom.xml文件中添加依赖
dependenciesdependencygroupIdorg.slf4j/groupIdartifactIdslf4j-api/artifactIdversion1.7.30/version/dependency
/dependencies实际上因为SLF4J应用非常广泛大量的功能组件、中间件都使用并已经引入了它所以通常不再需要单独引入如下图所示druid、easyexcel、mybatisplus都使用到了slf4j。 如何引入logback
前文说过slf4j只是接口定义而不是实现日志功能需要具体的日志组件logback或log4j2等来实现。
以logback为例在slf4j已添加的情况下引入如下包
dependenciesdependencygroupIdch.qos.logback/groupIdartifactIdlogback-classic/artifactIdversion1.2.3/version/dependency
/dependencies注意因为SpringBoot 2.x版本默认使用的日志组件就是logback所以引入包的操作也省了。 如何记录日志
在引入slf4j和logback后就可以按照以下方式来记录日志了。
public class PlatformBootApplication {private static final Logger logger LoggerFactory.getLogger(PlatformBootApplication.class);public static void main(String[] args) {logger.info(当前时间: {}, System.currentTimeMillis());}
}上面这种方式需要在每个类中通过LoggerFactory构造一个logger对象并且需要将当前类名传入一方面比较繁琐另一方面从别的类中粘贴过来后容易忘记修改类名结果就是日志输出的来源出现张冠李戴。
更简便的方法是结合lombok注解使用在类名上直接添加slf4j注解然后直接调用log.info即可。
Slf4j
public class PlatformBootApplication {public static void main(String[] args) {log.info(当前时间: {}, System.currentTimeMillis());}
}运行程序控制台输出如下
16:09:03.823 [main] INFO tech.abc.platform.boot.PlatformBootApplication - 当前时间: 1718093343816如何进行配置
前文我们通过logback在开发环境的控制台输出了info信息使用的实际是logback的默认配置。
在实际使用过程中特别是生产环境我们需要对日志输出进行定制化包括日志输出的格式、日志的级别、输出到哪文件、控制台……这就需要进行配置了。
logback的默认配置文件查找顺序是在类路径下依次查找logback.groovy、logback-test.xml、logback.xml文件。
在springboot项目的resources目录下新建一个logback.xml文件我们来进一步做日志输出的定制化。
如何配置输出到控制台
使用IDE开发时输出到控制台是最常用的功能配置也是最简单的以此为例我们来说下配置。
先上一份配置
?xml version1.0 encodingUTF-8?
configuration!--控制台日志输出--appender nameSTDOUT classch.qos.logback.core.ConsoleAppender!--格式及编码--encoderpattern%d{HH:mm:ss.SSS} %-5level [%-5thread] %logger - %msg%n/patterncharsetutf-8/charset/encoder/appender!-- 输出 --root levelINFOappender-ref refSTDOUT//root
/configuration日志功能组件中负责输出的称之为appender用来进行定制化配置。
然后root节点来做全局管理启用哪些输出以及输出的最低日志级别。
如何控制输出日志的格式
appender的encoder 部分的pattern属性设置日志输出的格式包括时间戳、日志级别、线程名、logger名、日志消息等需要按照规范来写。
这些格式项具有特定的约定用来控制输出日志的样式和内容。
以下是一些常用的格式项及其意义
%d{HH:mm:ss.SSS}表示日期时间格式其中HH小时、mm分钟、ss秒、SSS毫秒。
%-5level日志级别如DEBUG、INFO、WARN、ERROR等-5表示左对齐并至少占用5个字符宽度。
[%-5thread]当前线程名称同样左对齐并至少占用5个字符宽度。
%logger{36} 或简写为 %logger记录器Logger的名称通常对应类名{36}指定了最大长度为36个字符超出部分省略。
%msg日志消息本身。
%n换行符。
其他可能用到但上述示例未包含的格式项还包括
%r自应用程序启动到创建该日志事件所经过的毫秒数。
%M发出日志调用的方法名。
%F发出日志调用的源文件名。
%L发出日志调用的源文件中的行号。
%c 或 %C完整的类名或仅类名不包含包名。
我们可以根据需要定制这些格式项来达到期望的日志输出格式。
将其调整如下
pattern%d{HH:mm:ss.SSS} %-5level %r [%-5thread] %logger %M %F %L %C - %msg%n
/pattern 控制台输入如下
09:14:43.830 INFO 282 [main ] tech.abc.platform.boot.PlatformBootApplication main PlatformBootApplication.java 35 tech.abc.platform.boot.PlatformBootApplication - 当前时间: 1718154883827
如何配置输出到文件
系统开发调试环节我们更关注即时结果通常只需要将日志输出到控制台就行了。
系统部署到服务器后无论是测试环境还是生产环境我们都希望日志持久化以文件的方式输出到磁盘便于较长时间段的日志查看和分析。
我们增加一个appender来将日志输出到文件。
?xml version1.0 encodingUTF-8?
configuration!--控制台日志输出--appender nameSTDOUT classch.qos.logback.core.ConsoleAppender!--格式及编码--encoderpattern%d{HH:mm:ss.SSS} %-5level [%-5thread] %logger - %msg%n/patterncharsetutf-8/charset/encoder/appender!-- 输出到文件 --appender nameFILE classch.qos.logback.core.FileAppender!-- 日志文件的路径 --filec:\logs\myApplication.log/file!-- 设置追加模式 --appendtrue/append!-- 定义日志格式 --encoderpattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern/encoder/appender!-- 全局配置 --root levelINFO!--输出到控制台--appender-ref refSTDOUT/!--输出到文件--appender-ref refFILE//root
/configuration我们定义了一个名为FILE的appender使用的类是FileAppender。
file节点指定输出日志文件的路径。
append属性指定追加模式为true是在末尾追加为false则会清空原内容通常会设置为true。
encoder属性配置与前面控制台相同与之不同的是我们把年月日给加上了。
启动应用在磁盘上生成了日志文件内容如下 如何配置只输出指定级别的日志
logback的默认配置是输出指定级别及以上的日志。
在上面的示例中我们配置了日志级别时info输出的日志文件中不仅仅是infowarn和error也会输出。
在系统访问量比较大的情况下info日志会输出大量内容系统运维和异常排查时我们往往只关注warn或error级别的日志不希望info的大量内容混在其中形成干扰如何做呢
一种便捷的方式就是调整全局配置将root节点的level属性调整为warn此时所有的appender输出的最低级别日志就是warn不过error也会输出即warn和error日志还是输出到同一个文件中。此外该调整是对所有appender生效一定程度上也会影响开发测试环境希望输出info的设置。
如要实现精确的日志输出则需要为appender配置filter如下所示
appender nameFILE classch.qos.logback.core.FileAppender!-- 此日志文件只记录warn级别的 --filter classch.qos.logback.classic.filter.LevelFilterlevelwarn/levelonMatchACCEPT/onMatchonMismatchDENY/onMismatch/filter!-- 日志文件的路径 --filec:\logs\myApplication.log/file!-- 设置追加模式 --appendtrue/append!-- 定义日志布局 --encoderpattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern/encoder
/appender将level设置为warn注意只做这一步没用会显示root定义的级别以上所有日志还需要进一步配置下面两个属性。
onMatch代表匹配时接受只配这一个属性会显示warn级别以上的所有日志。
onMismatch设置为不匹配时拒绝最终结果就是只会记录warn这一种类型的日志不会有更高级别的error也混进来。
这时候停下来想一想如果我们想只输出warn日志是不是只配置onMismatch为DENY就可以了并不需要配置onMatch为ACCEPT
动手尝试了下果然是这样。 总结下过滤器的用法
只设置level没有任何用处。
设置onMismatch为DENY可以只输出该级别的日志。
设置onMatch为ACCEPT可以输出该级别及其以上的日志。
日志需要保留多久
这不是一个技术问题而是一个管理问题。
客观地说日志具有一定时效性几乎没有查看1个月以前的日志的需求因此长时间保留意义不大。一般情况下一周左右的日志就能满足大多数场景下系统异常问题的排查需要了。某些特殊业务场景或监管要求下如重要的业务系统需要保留操作痕迹用于审计会要求保留一个月甚至3个月等长时间段的日志。
如何解决日志过大的问题
通过上面的操作我们把日志输出到一个文件中新日志记录会追加到文件末尾。随着时间的累积会带来两个问题一是日志文件越来越大从最初的几兆增加到数百兆甚至于好几个G此时查看日志打开速度会很慢以致于普通的文本编辑器都没法打开搜索指定内容也难以实现更不用说分析了二是因为日志的膨胀可能会占用大量的磁盘空间进而导致磁盘空间耗尽引发应用系统异常、卡顿甚至宕机。
解决思路也有多个最简单的就是人工定期清理缺点就是带来了额外的运维工作量且容易发生因疏忽导致的工作漏做。在这基础上可以做成自动化通过定时任务脚本或开发来实现清理。
实际上最佳的实践是配置logback来实现滚动日志新日志自动覆盖旧日志。
如何配置日志滚动覆盖
我们再新增一个滚动日志的appender如下
!-- 滚动日志 --
appender nameFILE_ROLLING classch.qos.logback.core.rolling.RollingFileAppenderfilter classch.qos.logback.classic.filter.LevelFilterlevelINFO/level/filterrollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy!-- 按天滚动覆盖 --fileNamePatternc:\logs\info\%d{yyyy-MM-dd}.%i.log/fileNamePatternmaxHistory5/maxHistorymaxFileSize1KB/maxFileSize/rollingPolicy!-- 设置追加模式 --appendtrue/append!-- 定义日志布局 --encoderpattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern/encoder
/appender与普通文件日志相比实现类发生了变化由FileAppender变更为RollingFileAppender。
然后增加了滚动策略的配置
SizeAndTimeBasedRollingPolicy用于控制日志文件的滚动和管理基于文件大小和时间两个维度来复合控制。
元素指定了日志文件的命名规则%d{yyyy-MM-dd}.%i.log表示按日期进行回滚每天生成一个新文件文件名格式为yyyy-MM-dd.log其中%i表示按大小进行滚动的索引编号。
元素指定了保留的历史日志文件的最大天数这里设置为5意味着只会保留最近5天的日志文件旧的日志文件将会被删除。
元素指定了每个日志文件的最大体积这里设置为1KB当单个日志文件的体积超过1KB时将会生成新的日志文件进行滚动。
上面的配置定义了一个基于大小和时间的滚动策略用于按天回滚日志文件并限制了历史日志文件的保留天数和单个日志文件的大小。
注意这里有个误区以为maxHistory是设定日志文件的数量实际是日志天数。
上面为了测试效果我设置了很小的值输出如下 文件数量明显超出了5个。
至于设置了1KB实际2KB这是操作系统的估算而已。 正常使用也不会设置单日志文件限制大小1KB可忽略。
如何严格控制日志的磁盘占用
从上面测试结果来看实际仍有可能发生某一天因为系统异常产生了大量日志导致磁盘耗尽的可能性如何来解决呢
实际logback提供了多种滚动策略上面SizeAndTimeBasedRollingPolicy是基于大小和时间两个维度复合控制还有两个类分别实现基于大小和基于时间单个维度来控制。
基于时间的滚动策略 (TimeBasedRollingPolicy):
允许根据时间如每小时、每天滚动日志文件。
通过配置滚动后的文件名格式例如%d{yyyy-MM-dd}.log表示每天生成一个新日志文件。
基于大小的滚动策略 (SizeBasedTriggeringPolicy):
当日志文件达到指定大小时触发滚动。
需要与其他滚动策略结合使用比如与时间策略一起确保文件不会无限增长。
另有两个策略分别是固定窗口滚动策略 (FixedWindowRollingPolicy) 和 滚动计数器策略 (RollingFixedWindowTriggeringPolicy)。
这两个策略常一起使用基于固定窗口大小如每10个文件一组进行滚动。
不直接指定文件大小或时间而是通过窗口和计数器控制文件数量。
来个实例
appender nameFILE_ROLLING_FIXED_WINDOW classch.qos.logback.core.rolling.RollingFileAppender!-- 定义日志文件路径及基础文件名 --filec:\logs\app\app.log/file!-- 使用固定窗口滚动策略 --rollingPolicy classch.qos.logback.core.rolling.FixedWindowRollingPolicy!-- 指定窗口大小比如每5个文件一组 --minIndex1/minIndexmaxIndex5/maxIndex!-- 文件命名模式%i 代表窗口索引 --fileNamePatternc:\logs\app\app.%i.log/fileNamePattern/rollingPolicy!-- 配合使用的滚动计数器策略定义何时触发滚动 --triggeringPolicy classch.qos.logback.core.rolling.SizeBasedTriggeringPolicy!-- 每个日志文件最大大小 --maxFileSize1KB/maxFileSize/triggeringPolicy!-- 日志内容格式化 --encoderpattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern/encoder!-- 设置追加模式 --appendtrue/append/appender启动应用运行效果如下 查看日志内容发现app.1.log里的时间要晚于app.5.log里的时间说明已经发生了日志覆盖情况符合预期。
注意除了编号1-5的日志外还有一个无编号的本尊。在这种配置模式下去除 c:\logs\app\app.log配置通不过logback验证。
进一步测试发现情况有了变化如下图 日志大小超出了我们设置的1KB推测是因为我们日志大小设置的值过小而logback出于性能考虑往往会分批往磁盘里写日志每批次远大于1KB这个值设置成5M或者更大则不会存在问题。
通过固定窗口滚动策略滚动计数器策略这两个组合我们就能严格限定日志单个大小上限以及日志总个数比如设置单个日志文件不能超出10M日志文件最大为20个那么占用磁盘空间上限就是201*10210M。
另外你可能也想到了这种方式的一个弊端就是异常情况下如产生了大量日志新日志会覆盖旧日志有可能造成你想查看问题发生初期甚至昨天的日志因为被覆盖而无法实现的问题。
还有一个小问题就是我们日常往往不会主动去查看日志而是收到了系统异常反馈后才会根据日志排查这时基本可以确定异常发生的时间范围而上述配置产生的日志通过文件名是无法确定相应的日志在哪个文件里文件修改时间可以提供一定的参考往往需要打开多个日志文件才能定位。
如何使用变量
配置过程中有些值需要多次使用例如上面例子中日志文件路径及基础文件名在滚动策略命名中也会用到最好是将其定义成参数一次定义多次使用。如果需要修改也只修改一个地方就好了而不是到处找哪些地方用到既麻烦也容易遗漏。
logback是支持变量的定义方式如下 property nameMAX_SIZE value10MB/使用方式如下 maxFileSize${MAX_SIZE}/maxFileSize如何避免写日志操作影响业务处理
默认配置下写日志操作跟业务处理是在同一个进程或线程中的在系统负荷大特别是高并发情况下写日志操作对系统性能还是有一定影响。
通常日志的重要性要远低于业务处理所以我们可以采用异步方式。
logback自身支持异步需要配置如下 appender nameASYNC classch.qos.logback.classic.AsyncAppender!-- 设置异步日志队列的大小为1000即最多可以缓存1000个日志事件 --queueSize1000/queueSize!-- 设置丢弃阈值为0表示当队列满时不会丢弃任何日志事件 --discardingThreshold0/discardingThreshold!-- 设置为true表示当队列满时写入日志的操作不会被阻塞而是直接返回 --neverBlocktrue/neverBlock!-- 引用的appender将作为异步日志输出的目标即实际输出日志的地方 --appender-ref refSOME_OTHER_APPENDER//appender实际上就是定义一个异步的appender然后使用appender-ref指向默认或者说同步的appender就好了类似于套接了一层是不是很灵活记得最后在全局配置root节点下启用的是这个异步appender而不是原先的被套接的appender。
注意异步日志的配置有坑点下面来具体说一下。
queueSize是日志队列长度底层实现是BlockingQueue默认长度是256设置过大有可能造成OOM。
discardingThreshold的默认设置是queueSize的20%队列长1000默认就是200这个参数什么意思呢
就是当队列中剩余的容量不足200时会丢弃掉info级别及以下的日志。设置为0则代表永不丢弃。 AsyncAppender的异步机制的出现本来就是优化日志阻塞问题的但是使用不当反而容易出现阻塞问题。
neverBlock的默认值是false当队列满了的时候**或剩余容量达到阈值discardingThreshold就会出现阻塞问题**。设置为true时明面上代表永不堵塞业务处理实际意味着丢弃日志。
这三个参数实际是相互作用的在具体项目中需要好好权衡下取舍是性能优先还是日志完整性优先。
如果性能排在首位能接受一定的日志丢失则将neverBlock设置为true。
如果完全不能接受日志丢失需要将discardingThreshold 设置为0。
兼顾性能和日志不丢将discardingThreshold 设置为0把queueSize值设置的大一点。 所以异步日志一定注意合理配置并且如果系统的并发访问量不大也没必要启用异步日志。
典型配置什么样
经过上述一步步从简单到复杂的探索我们了解了logback的常用配置。
考虑到日志通常不会占用大量磁盘而且服务器通常会有监控磁盘不足时会进行报警。
从运维便利性角度考虑我们采用的还是基于时间维度限制单个文件大小的滚动覆盖的日志策略。
最终我们综合运用输出一个典型配置如下
?xml version1.0 encodingUTF-8?
configuration!--设置系统日志目录--property nameLOG_PATH valuec:/logs//!--设置应用日志目录--property nameAPP_DIR valueplatform/!--日志保留天数--property nameMAX_HISTORY value30/!--单个日志最大体积--property nameMAX_SIZE value10MB/!-- 仅错误日志 --appender nameFILE_ERROR classch.qos.logback.core.rolling.RollingFileAppender!-- 此日志文件只记录error级别的 --filter classch.qos.logback.classic.filter.LevelFilterlevelerror/levelonMismatchDENY/onMismatch/filterrollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy!-- 按天滚动覆盖 --fileNamePattern${LOG_PATH}/${APP_DIR}/error/%d{yyyy-MM-dd}.%i.log/fileNamePatternmaxHistory${MAX_HISTORY}/maxHistorymaxFileSize${MAX_SIZE}/maxFileSize/rollingPolicy!-- 追加方式记录日志 --appendtrue/append!-- 日志文件的格式 --encoder classch.qos.logback.classic.encoder.PatternLayoutEncoderpattern%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger Line:%-3L - %msg%n/patterncharsetutf-8/charset/encoder/appender!-- 仅警告日志 --appender nameFILE_WARN classch.qos.logback.core.rolling.RollingFileAppenderfilter classch.qos.logback.classic.filter.LevelFilterlevelwarn/levelonMismatchDENY/onMismatch/filterrollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy!-- 按天滚动覆盖 --fileNamePattern${LOG_PATH}/${APP_DIR}/warn/%d{yyyy-MM-dd}.%i.log/fileNamePatternmaxHistory${MAX_HISTORY}/maxHistorymaxFileSize${MAX_SIZE}/maxFileSize/rollingPolicy!-- 追加方式记录日志 --appendtrue/append!-- 日志文件的格式 --encoder classch.qos.logback.classic.encoder.PatternLayoutEncoderpattern%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger Line:%-3L - %msg%n/patterncharsetutf-8/charset/encoder/appender!-- 所有日志 --appender nameFILE_INFO classch.qos.logback.core.rolling.RollingFileAppenderfilter classch.qos.logback.classic.filter.LevelFilterlevelinfo/levelonMatchACCEPT/onMatch/filterrollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy!-- 按天滚动覆盖 --fileNamePattern${LOG_PATH}/${APP_DIR}/info/%d{yyyy-MM-dd}.%i.log/fileNamePatternmaxHistory${MAX_HISTORY}/maxHistorymaxFileSize${MAX_SIZE}/maxFileSize/rollingPolicy!-- 追加方式记录日志 --appendtrue/append!-- 日志文件的格式 --encoder classch.qos.logback.classic.encoder.PatternLayoutEncoderpattern%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger Line:%-3L - %msg%n/patterncharsetutf-8/charset/encoder/appender!--控制台日志输出--appender nameSTDOUT classch.qos.logback.core.ConsoleAppender!--格式及编码--encoderpattern%d{HH:mm:ss.SSS} %-5level [%-5thread] %logger - %msg%n/patterncharsetutf-8/charset/encoder/appender!-- 全局配置 --root levelINFO!--仅错误日志--appender-ref refFILE_ERROR/!--仅警告日志--appender-ref refFILE_WARN/!--信息日志--appender-ref refFILE_INFO/!--输出到控制台--appender-ref refSTDOUT//root
/configuration上述配置将日志输出到两个地方一个是控制台STDOUT用于开发环境另外一个是磁盘文件并且按日志级别进行了区分对待单个日志文件不超过10M按天滚动覆盖最多不超过30天。
在配置的日志文件路径下显示如下 注意以上配置文件设置中info、warn和error分别建立目录info代表是info及其级别以上的信息即不仅包含info日志warn和error日志也存在。warn和error日志使用了filter过滤器控制分别只记录严格匹配的警告和错误信息。按照上述配置warn类型的日志会记录两遍一遍在warn中一遍在info中error也是一样的。
开发环境建议全局配置中只保留控制台日志输出即可。
测试环境建议完全按照上面配置控制台和磁盘文件都输出便于上生产前发现和排查问题。
生产环境建议将全局日志级别的root levelINFO调整为ERROR或者WARN并注释掉info输出 以及控制台输出。
在系统异常的时候仅靠warn和error日志难以排查时在流量较小的情况下短时间打开info日志收集完日志数据后及时关闭。
