Spring Boot日志
1. 日志的概述
1.1 概念:
最早期我们就通过System.out.print来打印日志,用来发现和定位问题.随着项⽬的复杂度提升, 我们对⽇志的打印也有了更⾼的需求, ⽽不仅仅是定位排查问题.比如如需要记录⼀些⽤户的操作记录(⼀些审计公司会要求), 也可能需要使⽤⽇志来记录用户的⼀些喜好, 把⽇志持久化, 后续进⾏数据分析等. 但是 System.out.print 不能很好的满⾜我们的需求, 我们就需要使⽤⼀些专⻔⽇志框架(专业的事情交给专业的⼈去做)
1.2 日志的用处
1> 发现问题, 分析问题, 定位问题是最基本功能
2> 系统监控,举个例子某个接口的运行时间是多少,然后客户访问后端使用这个接口100次,只有10次响应,那么可用率就为10%,需要进行优化.再比如,我如果在异常里面打印日志,发现异常的次数在一段时间内超过了阈值,就进行报警.
监控现在⼏乎是⼀个成熟系统的标配, 我们可以通过⽇志记录这个系统的运⾏状态, 每⼀个⽅法的响应时间, 响应状态等, 对数据进⾏分析, 设置不同的规则, 超过阈值时进⾏报警. 比如如统计⽇志中关键字的数量，并在关键字数量达到⼀定条件时报警，这也是⽇志的常⻅需求之一
我们下面是使用日志测试一个get接口使用到结束的耗费时间
3> 数据采集
比如: 在购物网站,我们要知道今天卖了多少货物,收了多少钱,最畅销的商品是哪些....
网站一般分为日活,月活...用活(用户一登陆,前端就把登录信息打印出来了,我们就能根据这个来进行统计) ,还能计算某个用户今天在哪个商品停留了多少时间.
数据采集是⼀个比较大的范围, 采集的数据可以作⽤在很多⽅⾯, 比如数据统计, 推荐排序等.
数据统计: 统计页面的浏览量(PV), 访客量(UV), 点击量等, 根据这些数据进⾏数据分析, 优化公司运营策略
推荐排序: ⽬前推荐排序应⽤在各个领域, 我们经常接触的各⾏各业很多也都涉及推荐排序, 比如购物, ⼴告, 新闻等领域. 数据采集是推荐排序⼯作中必须做的⼀环, 系统通过⽇志记录用户的浏览历史, 停留时⻓等, 算法⼈员通过分析这些数据, 训练模型, 给用户做推荐.
数据清洗(日志清洗,数据治理): 分析日志...
4> ⽇志审计
大多都是国家需要,比如网络安全这一块.很多软件在使用之前都要获取我们的信息,进行一些授权,这样我们的一些信息就流在网络上了.
随着互联网的发展，众多企业的关键业务越来越多的运⾏于网络之上. 网络安全越来越受到⼤家的关注, 系统安全也成为了项目中的⼀个重要环节, 安全审计也是系统中非常重要的部分. 国家的政策法规、⾏业标准等都明确对日志审计提出了要求. 通过系统⽇志分析，可以判断⼀些非法攻击, 非法调用，以及系统处理过程中的安全隐患.
比如, 大家平时都在做运营系统, 其中运营⼈员在通过界⾯处理⼀些数据的时候, 如果没有清楚的⽇志操作记录, ⼀条数据被删除或者修改, 你是⽆法找到是谁操作的，但是如果你做了相应的记录，该数据被谁删除或者修改就会⼀目了然.还有⼀些内部的违规和信息泄漏(⽐如客户信息被卖掉)现象出现后, 如果未记录留存⽇志, 为事后调查提供依据, 则事后很难追查(⼀些公司查看客⼾的信息都会被记录⽇志, 如果频繁查询也会报警).
2. 日志的使用
Spring里面集成了日志框架,我们来进行使用
2.1 使用日志对象打印日志
创建日志对象,然后打印日志
运行结果:
解释代码:
LoggerFactory.getLogger()里面的内容是什么?logger.info()里面的内容是什么?
2.2 日志框架介绍
设计模式
设计模式就是对方法的封装.
工厂模式概述
此时,这里就使用了一种工厂模式(线程池那里也用到了工厂模式)
门面模式(外观模式)
提供了一个统一的接口,用来访问子系统中的一群接口.其主要特征是定义了一个高层接口,让用户更容易使用.
门面系统的角色:
1> 外观角色: 也叫做门面角色,是系统对外的统一接口
2> 子系统角色: 可以同时有⼀个或多个 SubSystem. 每个 SubSytem 都不是⼀个单独的类,而言是⼀个类的集合. SubSystem 并不知道 Facade 的存在, 对于 SubSystem而言, Facade 只是另⼀个客户端而已(即 Facade 对 SubSystem 透明)
比如刚刚的那个图:对于子系统而言,门面系统只是一个客户端而已.通过门面系统来调用子系统会更加的方便.
比如看病这个例子:去医院看病,，可能要去挂号, ⻔诊, 化验, 取药, 让患者或患者家属觉得很复杂, 如果有提供接待⼈员, 只让接待⼈员来处理, 就很⽅便.
门面模式的实现:
场景: 回家, 我们会开各个屋的灯. 离开家时, 会关闭各个屋的灯.如果家⾥设置⼀个总开关, 来控制整个屋的灯就会很⽅便.我们使⽤⻔⾯模式的实现.
1> 实现子系统
2> 实现门面系统
我们在门面系统里面调用子系统,把分别的子系统的功能封装到一起来进行统一使用.
它是一种规范,只有类实现开灯和关灯俩个功能,才能作为它的子系统.
3> 客户端调用门面系统
门面模式的优缺点(八股文)
1. 减少了系统的相互依赖,实现了客户端与子系统的耦合关系,这使得子系统的变化不会影响到调用它的客户端(只要修改门面系统即可)
2. 提高了灵活性,简化了客户端对子系统的使用难度,客户端不需要关系子系统的具体实现,只需要使用门面系统封装好的接口就行.
3. 提高了安全性,可以灵活设置访问权限,不在门面对象中开通方法就无法访问.因为有了门面系统,我们的客户端就不能够直接接触到子系统了,这就提高了安全性.
什么是日志实现?
Spring 打印日志使用的是JUL( Java util Logging),默认的日志框架是logback.
他们是底层的日志框架
什么是日志门面?
slf4j是日志的门面,它是门面模式的典型应用,是对日志实现的进一步封装.不需要关注它具体实现是什么,直接使用接口就行.
slf4j是一种规范,
3. SLF4J框架介绍
SLF4J 就是其他⽇志框架的⻔⾯. SLF4J 可以理解为是提供⽇志服务的统⼀API接⼝, 并不涉及到具体的⽇志逻辑实现.
3.1 不引入日志门面
常见的⽇志框架有log4J, logback等. 如果⼀个项⽬已经使⽤了log4j，⽽你依赖的另⼀个类库，假如是Apache Active MQ, 它依赖于另外⼀个⽇志框架logback, 那么你就需要把logback也加载进去.
存在问题:
1. 不同⽇志框架的API接⼝和配置⽂件不同, 如果多个⽇志框架共存, 那么不得不维护多套配置⽂件(这个配置⽂件是指⽤⼾⾃定义的配置⽂件).
2. 如果要更换⽇志框架, 应⽤程序将不得不修改代码, 并且修改过程中可能会存在⼀些代码冲突.
3. 如果引⼊的第三⽅框架, 使⽤了多套, 那就不得不维护多套配置(还牵扯到版本问题).
3.2 引入日志门面
引⼊⻔⾯⽇志框架之后, 应⽤程序和⽇志框架(框架的具体实现)之间有了统⼀的API接⼝(⻔⾯⽇志框架实现), 此时应⽤程序只需要维护⼀套⽇志⽂件配置, 且当底层实现框架改变时, 也不需要更改应⽤程序代码.配置相同,我们只需要维护一个版本就行.
3.3 日志格式的介绍
我们可以看到有一下日志内容
1> 时间⽇期：精确到毫秒
2> ⽇志级别：ERROR, WARN, INFO, DEBUG 或TRACE
3> 进程ID
4> 线程名
5> Logger名(通常使⽤源代码的类名)
6> ⽇志内容
3.3.1 日志的级别
日志的级别代表日志信息的严重性.有了⽇志级别之后就可以过滤⾃⼰想看到的信息了, ⽐如只关注error级别的, 就可以根据级别过滤出来error级别的⽇志信息, 节约开发者的信息筛选时间.
例: 试想⼀下这样的场景，假设你是⼀家 2 万⼈公司的⽼板, 如果每个员⼯的⽇常⼯作和琐碎的信息都要反馈给你, 那你⼀定⽆暇顾及. 于是就有了组织架构，⽽组织架构就会分级，有很多的级别设置，如下图所示:
有了组织架构之后，就可以逐级别汇报消息了, 例如：组员汇报给组⻓, 组⻓汇报给研发⼀组, 研发⼀组汇报给 Java 研发, 等等依次进⾏汇报.
日志级别划分:
日志级别从高到低: FATAL,ERROR,WARN,INFO,DEBUG,TRACE
1> FATAL: 致命信息,表示需要立即被处理的系统错误.
2> ERROR: 错误信息,级别较高的错误日志信息,但是不影响系统的继续运行.(比如我们验证码,校验信息失败,或者偶尔一次的超时)
3> WARN: 警告信息,不影响使用,但需要注意.(长期不处理,可能会引起故障)
4> INFO: 普通信息,用来记录应用正常运行时的一些信息,例如系统启动完成,请求处理完成...
5> DEBUG: 调试信息,需要调试的关键信息打印
6> TRACE: 追踪信息,比DEBUG颗粒度更细的信息事件(很少使用)
日志级别顺序
使用日志级别:
trace,debug日志信息一般不打印,但是我们可以设置打印出来.>=info级别的日志,我都可以收到
注意: 错误级别的日志,和测试人员提出的bug级别无关.这个错误级别是方便程序员来看的.
设置日志级别:
我们去官方文档看一下 :常见的 Application Properties
日志级别只要在配置文件中设置"logging.level"配置即可,后面我们只要在yml或者Properties里面配置一个就行.⼆者转换⽅式: Properties⽂件的点(. ) 对应yml⽂件中的换⾏以下两个配置, 根据项⽬使⽤其中之⼀.
yml版本:
logging:
level:
root: debug
properties版本:
logging.level.root: debug
这个说明一件事,程序如果运行出来了,一些DEBUG日志是不影响的
基本上企业开发里面,每个项目都有错误日志,不影响结果的运行就可以不管他们
然后我们使用自己刚刚的日志级别: 发现debug级别依然没有打印出来
这个原因就是因为yml我们配置的路径的问题: root表示设置所有的整个目录文件的日志级别
同理,我们也可以去打印trace级别的日志
规律: 打印出来>=我们在配置文件设置的级别,比如我们设置info,那么我们可以打印出来info,warn,err
日志持久化
以上的⽇志都是输出在控制台上的, 然⽽在线上环境中, 我们需要把⽇志保存下来, 以便出现问题之后追溯问题. 把⽇志保存下来就叫持久化.
简单来说就是.我们关掉我们的程序之后,我们的日志就没有了,比如我今天才发现了一星期前的一个Bug,那么我就需要一星期前的日志.此时,我们就需要把日志存起来,形成一个文件.
官方文档给出的核心组件: 常见的 Application Properties
第一个组件: logging,file.name
我们来使用一下logging.file.name.这样我们就可以查到我们之前的日志信息了
刚刚我们没有设置路径,此时我们设置路径,我们生成了一个文件夹,然后里面放着我们的历史日志
持久化的问题: 我们一直在历史日志下面继续添加日志,如果太大了(一般,我们要存一个月的日志),我们该如何解决.解决这个问题,我们就可以用到多个文件夹了,一个文件夹存不下的,我们用多个文件夹进行存(此时就牵扯到日志的分割,后面再说)
第二个组件: logging.file.path
我们进行使用:
此时我们得出一个结论:
name: 可以设置路径和名称
path: 只可以设置路径,默认日志名:spring.log
对比:
如果path和name都进行设置
name生效,path不生效.name的优先级高于path
日志分割
如果我们的⽇志都放在⼀个⽂件中, 随着项⽬的运⾏, ⽇志⽂件会越来越⼤, 需要对⽇志⽂件进⾏分割.一般10M就进行分割.
设置分割日志的大小,此时我设置的是1KB
注意: 如果觉得代码没有问题,那么就可以去考虑缓存问题.点击这里面的clean
设置分割日志的格式,此时我们采用默认值
配置日志格式
一些配置项和配置说明
配置控制台里面信息的颜色: 复制这个信息,-配置一下 Dspring.output.ansi.enabled=ALWAYS
注意有些格式可能对不上,我们就去官方寻找答案
官方格式详解:
更加简单的日志输出
这是我们之前的输出日志的方式: 1.声明对象 2. 打印日志
我们lombok提供了一个注解@Slf4j
4. 总结:
1> 日志是用来快速发现和定位问题的工具,Spring Boot 帮我们把logback集成了进来.日志的6个级别.一般常用warrn,info,error.一般日志在工作的时候是单独在一个xml进行配置的.默认情况下使⽤的是 info ⽇志级别将⽇志输出到控制台的，我们可以通过 lombok 提供的@Slf4j 注解和 log 对象快速的打印⾃定义⽇志.
2> ⽇志包含 6 个级别, ⽇志级别越⾼，收到的⽇志信息也就越少，我们可以通过配置⽇志的保存名称或保存⽬录来将⽇志持久化.
原文地址：https://blog.csdn.net/2201_75880772/article/details/145161778
免责声明：本站文章内容转载自网络资源，如侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！