《手把手教你》系列基础篇(八十八)-java+ selenium自动化测试-框架设计基础-Log4j 2实现日志输出-下篇(详解教程)

简介: 【7月更文挑战第6天】本文介绍了如何使用Log4j2将日志输出到文件中,重点在于配置文件的结构和作用。配置文件包含两个主要部分:`appenders`和`loggers`。`appenders`定义了日志输出的目标,如控制台(Console)或其他文件,如RollingFile,设置输出格式和策略。`loggers`定义了日志记录器,通过`name`属性关联到特定的类或包,并通过`appender-ref`引用`appenders`来指定输出位置。`additivity`属性控制是否继承父logger的配置。

1.简介

上一篇宏哥讲解和分享了如何在控制台输出日志,但是你还需要复制粘贴才能发给相关人员,而且由于界面大小限制,你只能获取当前的日志,因此最好还是将日志适时地记录在文件中直接打包发给相关人员即可。因此这一篇宏哥主要讲解和分享如何通过log4j2将日志输出到文件中。

2.配置文件

先简单介绍一下下面这个配置文件。

1)根节点configuration,然后有两个子节点:appenders和loggers(都是复数,意思就是可以定义很多个appender和logger了)(如果想详细的看一下这个xml的结构,可以去jar包下面去找xsd文件和dtd文件)

2)appenders:这个下面定义的是各个appender,就是输出了,有好多类别,这里也不多说(容易造成理解和解释上的压力,一开始也未必能听懂,等于白讲),先看这个例子,只有一个Console,这些节点可不是随便命名的,Console就是输出控制台的意思。然后就针对这个输出设置一些属性,这里设置了PatternLayout就是输出格式了,基本上是前面时间,线程,级别,logger名称,log信息等,差不多,可以自己去查他们的语法规则。

3)loggers下面会定义许多个logger,这些logger通过name进行区分,来对不同的logger配置不同的输出,方法是通过引用上面定义的logger,注意,appender-ref引用的值是上面每个appender的name,而不是节点名称。

这个例子为了说明什么呢?宏哥要说说这个logger的name(名称)了(上一篇文章 开头部分有提到)。

xml version="1.0" encoding="UTF-8"?>

<configuration status="OFF">

   <appenders>

       <Console name="Console" target="SYSTEM_OUT">

           <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>

       Console>

   appenders>

   <loggers>

     

     

       <logger name="testSuites.Test" level="trace" additivity="false">

           <appender-ref ref="Console"/>

       logger>

       <root level="error">

           <appender-ref ref="Console"/>

       root>

   loggers>

configuration>

3.name的机制

想要详细了解的同学们或者小伙伴们可以参考: http://logging.apache.org/log4j/2.x/manual/architecture.html)

我们这里看到了配置文件里面是name很重要,没错,这个name可不能随便起(其实可以随便起)。这个机制意思很简单。就是类似于java package一样,比如我们的一个包:cn.lsw.base.log4j2。而且,可以发现我们前面生成Logger对象的时候,命名都是通过 Hello.class.getName(); 这样的方法,为什么要这样呢? 很简单,因为有所谓的Logger 继承的问题。比如 如果你给cn.lsw.base定义了一个logger,那么他也适用于cn.lsw.base.lgo4j2这个logger。名称的继承是通过点(.)分隔的。然后你可以猜测上面loggers里面有一个子节点不是logger而是root,而且这个root没有name属性。这个root相当于根节点。你所有的logger都适用与这个logger,所以,即使你在很多类里面通过 类名.class.getName() 得到很多的logger,而且没有在配置文件的loggers下面做配置,他们也都能够输出,因为他们都继承了root的log配置。

我们上面的这个配置文件里面还定义了一个logger,他的名称是 testSuites.Test ,这个名称其实就是通过前面的Hello.class.getName(); 得到的,我们为了给他单独做配置,这里就生成对于这个类的logger,上面的配置基本的意思是只有testSuites.Test 这个logger输出trace信息,也就是他的日志级别是trace,其他的logger则继承root的日志配置,日志级别是error,只能打印出ERROR及以上级别的日志。如果这里logger 的name属性改成cn.lsw.base,则这个包下面的所有logger都会继承这个log配置(这里的包是log4j的logger name的“包”的含义,不是java的包,你非要给Hello生成一个名称为“myhello”的logger,他也就没法继承cn.lsw.base这个配置了。

那有人就要问了,他不是也应该继承了root的配置了么,那么会不会输出两遍呢?我们在配置文件中给了解释,如果你设置了additivity="false",就不会输出两遍,否则,看下面的输出:

1.这里要在加入一个类做对比,如下图所示: 

2.这里先把配置文件改一下方便对照,一个是刚才第一个logger的名称还是testSuites.Test,additivity去掉或改为true(因为默认是true,所以可以去掉),第二是把root的level改为info方便观察。 然后运行Test,看控制台的日志输出:

可以看出,Test的trace日志没有输出,因为他继承了root的日志配置,只输出info即以上级别的日志。Hello 输出了trace及以上级别的日志,但是每个都输出了两遍。你可以试一下,把第一个logger的level该为error,那么error以上的级别也是输出两遍。这时候,只要加上additivity为false就可以避免这个问题了。

当然,你可以为每个logger 都在配置文件下面做不同的配置,也可以通过继承机制,对不同包下面的日志做不同的配置。因为loggers下面可以写很多个logger。

4.复杂的配置文件

xml version="1.0" encoding="UTF-8"?>


<configuration status="error">

 

   <appenders>

     

       <Console name="Console" target="SYSTEM_OUT">

         

           <ThresholdFilter level="trace" onMatch="ACCEPT" onMismatch="DENY"/>

         

           <PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %class{36} %L %M - %msg%xEx%n"/>

       Console>

     

       <File name="log" fileName="log/test.log" append="false">

           <PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %class{36} %L %M - %msg%xEx%n"/>

       File>


     

       <RollingFile name="RollingFile" fileName="logs/app.log"

                    filePattern="log/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.log.gz">

           <PatternLayout pattern="%d{yyyy-MM-dd 'at' HH:mm:ss z} %-5level %class{36} %L %M - %msg%xEx%n"/>

           <SizeBasedTriggeringPolicy size="50MB"/>

       RollingFile>

   appenders>

 

   <loggers>

     

       <root level="trace">

           <appender-ref ref="RollingFile"/>

           <appender-ref ref="Console"/>

       root>


   loggers>

configuration>

说复杂,其实也不复杂,这一个例子主要是为了讲一下appenders。

  这里定义了三个appender,Console,File,RollingFile,看意思基本也明白,第二个是写入文件,第三个是“循环”的日志文件,意思是日志文件大于阀值的时候,就开始写一个新的日志文件。

  这里我们的配置文件里面的注释算比较详细的了。所以就大家自己看了。有一个比较有意思的是ThresholdFilter ,一个过滤器,其实每个appender可以定义很多个filter,这个功能很有用。如果你要选择控制台只能输出ERROR以上的类别,你就用ThresholdFilter,把level设置成ERROR,onMatch="ACCEPT" onMismatch="DENY" 的意思是匹配就接受,否则直接拒绝,当然有其他选择了,比如交给其他的过滤器去处理了之类的,详情大家自己去琢磨吧。

  为什么要加一个这样的配置文件呢?其实这个配置文件我感觉挺好的,他的实用性就在下面:

4.1实用性

我们用日志一方面是为了记录程序运行的信息,在出错的时候排查之类的,有时候调试的时候也喜欢用日志。所以,日志如果记录的很乱的话,看起来也不方便。所以我可能有下面一些需求:

1)我正在调试某个类,所以,我不想让其他的类或者包的日志输出,否则会很多内容,所以,你可以修改上面root的级别为最高(或者谨慎起见就用ERROR),然后,加一个针对该类的logger配置,比如第一个配置文件中的设置,把他的level设置trace或者debug之类的,然后我们给一个appender-ref是定义的File那个appender(共三个appender,还记得吗),这个appender的好处是有一个append为false的属性,这样,每次运行都会清空上次的日志,这样就不会因为一直在调试而增加这个文件的内容,查起来也方便,这个和输出到控制台就一个效果了。

2)我已经基本上部署好程序了,然后我要长时间运行了。我需要记录下面几种日志,第一,控制台输出所有的error级别以上的信息。第二,我要有一个文件输出是所有的debug或者info以上的信息,类似做程序记录什么的。第三,我要单独为ERROR以上的信息输出到单独的文件,如果出了错,只查这个配置文件就好了,不会去处理太多的日志,看起来头都大了。怎么做呢,很简单。

首先,在appenders下面加一个Console类型的appender,通过加一个ThresholdFilter设置level为error。(直接在配置文件的Console这个appender中修改)

其次,增加一个File类型的appender(也可以是RollingFile或者其他文件输出类型),然后通过设置ThresholdFilter的level为error,设置成File好在,你的error日志应该不会那么多,不需要有多个error级别日志文件的存在,否则你的程序基本上可以重写了。

这里可以添加一个appender,内容如下:

<File name="ERROR" fileName="logs/error.log">

   <ThresholdFilter level="error" onMatch="ACCEPT" onMismatch="DENY"/>

   <PatternLayout pattern="%d{yyyy.MM.dd 'at' HH:mm:ss z} %-5level %class{36} %L %M - %msg%xEx%n"/>

File>

并在loggers中的某个logger(如root)中引用(root节点加入这一行作为子节点)。

<appender-ref ref="ERROR" />

然后,增加一个RollingFile的appender,设置基本上同上面的那个配置文件。

最后,在logger中进行相应的配置。不过如果你的logger中也有日志级别的配置,如果级别都在error以上,你的appender里面也就不会输出error一下的信息了。

还记得上面的Test类里面有一个被注释掉的for循环么?这个是为了做配置文件中RollingFile那个appender的配置的,取消注释,运行商一次或几次,看你的输出配置文件的地方,他是怎么“RollingFile”的,这里给个我测试的截图:(这里你可以把 这里的size改成2MB,要生成50MB的日志还是比较慢的。为了方便观察么!然后把Console的ThresholdFilter的level设置成error这样的较高级别,不然控制台输出东西太多了)

从上图可以看出:

第一部分是File这个appender生成的日志文件,你会发现你运行很多次,这个文件中的日志是被覆盖的。

第二部分是RollingFile 这个appender生成的配置文件,可以发现,默认建立的是app.log这个日志,每次超过2MB的时候,就会生成对应年-月的文件夹,和制定命名格式的log文件,而且是压缩成gz格式文件,打开资源管理器发现这个文件只有11KB,解压后就是2MB。

5.小结

 好了,时间也不早了,今天就分享和讲解到这里,希望对您有所帮助,感谢您耐心地阅读!



每天学习一点,今后必成大神-

往期推荐(由于跳转参数丢失了,所有建议选中要访问的右键,在新标签页中打开链接即可访问):


Appium自动化系列,耗时80天打造的从搭建环境到实际应用精品教程测试

Python接口自动化测试教程,熬夜87天整理出这一份上万字的超全学习指南

Python+Selenium自动化系列,通宵700天从无到有搭建一个自动化测试框架

Java+Selenium自动化系列,仿照Python趁热打铁呕心沥血317天搭建价值好几K的自动化测试框架

Jmeter工具从基础->进阶->高级,费时2年多整理出这一份全网超详细的入门到精通教程

Fiddler工具从基础->进阶->高级,费时100多天吐血整理出这一份全网超详细的入门到精通教程

Pycharm工具基础使用教程

相关实践学习
通过日志服务实现云资源OSS的安全审计
本实验介绍如何通过日志服务实现云资源OSS的安全审计。
相关文章
|
7月前
|
Web App开发 人工智能 JavaScript
主流自动化测试框架的技术解析与实战指南
本内容深入解析主流测试框架Playwright、Selenium与Cypress的核心架构与适用场景,对比其在SPA测试、CI/CD、跨浏览器兼容性等方面的表现。同时探讨Playwright在AI增强测试、录制回放、企业部署等领域的实战优势,以及Selenium在老旧系统和IE兼容性中的坚守场景。结合六大典型场景,提供技术选型决策指南,并展望AI赋能下的未来测试体系。
|
5月前
|
数据采集 人工智能 自然语言处理
Playwright MCP 浏览器自动化框架全面解析
Playwright MCP是微软推出的开源项目,结合Playwright与MCP协议,让AI通过结构化数据直接操作浏览器。告别传统视觉识别,实现高效、精准的网页自动化,广泛应用于测试、爬虫、办公自动化等场景,大幅提升效率与可靠性。
|
8月前
|
Web App开发 开发框架 .NET
Playwright 自动化测试系列(6)| 第三阶段:测试框架集成​指南:参数化测试 + 多浏览器并行执行
Pytest 与 Playwright 集成可提升自动化测试效率,支持参数化测试、多浏览器并行执行及统一报告生成。通过数据驱动、Fixture 管理和并行优化,显著增强测试覆盖率与执行速度,适用于复杂 Web 应用测试场景。
|
8月前
|
测试技术 API C++
Playwright 自动化测试系列(7)| 第三阶段:测试框架集成​​Page Object 模式
本课程详解Playwright测试框架中的Page Object模式,通过电商登录-下单实战演示PO架构设计与高级技巧,结合Pytest实现多用户测试。重点解析PO模式提升代码复用性、降低维护成本的核心价值,并提供常见问题解决方案,助力构建高可维护性的自动化测试体系。
|
8月前
|
Java 测试技术 API
自动化测试框架深度解析与选择指南
Apache JMeter是Apache组织基于Java开发的一款压力测试工具,旨在测试软件的性能承受能力。它支持多种协议测试及功能测试,提供灵活的断言创建能力,如同创建带断言的脚本来验证程序是否返回预期结果。
|
数据可视化 前端开发 测试技术
接口测试新选择:Postman替代方案全解析
在软件开发中,接口测试工具至关重要。Postman长期占据主导地位,但随着国产工具的崛起,越来越多开发者转向更适合中国市场的替代方案——Apifox。它不仅支持中英文切换、完全免费不限人数,还具备强大的可视化操作、自动生成文档和API调试功能,极大简化了开发流程。
|
9月前
|
Java 测试技术 容器
Jmeter工具使用:HTTP接口性能测试实战
希望这篇文章能够帮助你初步理解如何使用JMeter进行HTTP接口性能测试,有兴趣的话,你可以研究更多关于JMeter的内容。记住,只有理解并掌握了这些工具,你才能充分利用它们发挥其应有的价值。+
1331 23
|
11月前
|
SQL 安全 测试技术
2025接口测试全攻略:高并发、安全防护与六大工具实战指南
本文探讨高并发稳定性验证、安全防护实战及六大工具(Postman、RunnerGo、Apipost、JMeter、SoapUI、Fiddler)选型指南,助力构建未来接口测试体系。接口测试旨在验证数据传输、参数合法性、错误处理能力及性能安全性,其重要性体现在早期发现问题、保障系统稳定和支撑持续集成。常用方法包括功能、性能、安全性及兼容性测试,典型场景涵盖前后端分离开发、第三方服务集成与数据一致性检查。选择合适的工具需综合考虑需求与团队协作等因素。
1742 24
|
JSON 前端开发 测试技术
大前端之前端开发接口测试工具postman的使用方法-简单get接口请求测试的使用方法-简单教学一看就会-以实际例子来说明-优雅草卓伊凡
大前端之前端开发接口测试工具postman的使用方法-简单get接口请求测试的使用方法-简单教学一看就会-以实际例子来说明-优雅草卓伊凡
1014 10
大前端之前端开发接口测试工具postman的使用方法-简单get接口请求测试的使用方法-简单教学一看就会-以实际例子来说明-优雅草卓伊凡
|
JSON 前端开发 API
以项目登录接口为例-大前端之开发postman请求接口带token的请求测试-前端开发必学之一-如果要学会联调接口而不是纯写静态前端页面-这个是必学-本文以优雅草蜻蜓Q系统API为实践来演示我们如何带token请求接口-优雅草卓伊凡
以项目登录接口为例-大前端之开发postman请求接口带token的请求测试-前端开发必学之一-如果要学会联调接口而不是纯写静态前端页面-这个是必学-本文以优雅草蜻蜓Q系统API为实践来演示我们如何带token请求接口-优雅草卓伊凡
852 5
以项目登录接口为例-大前端之开发postman请求接口带token的请求测试-前端开发必学之一-如果要学会联调接口而不是纯写静态前端页面-这个是必学-本文以优雅草蜻蜓Q系统API为实践来演示我们如何带token请求接口-优雅草卓伊凡