本文内容主要包含如下几个部分:
为什么要用日志
日志是用来记录我们在系统中的操作动作的,相当于我们的操作轨迹,那么日志的目的就显而易见,就是为了让我们知道,在某个时刻,系统里发生了什么事情,以便于我们更好的去复盘问题。
日志的种类
一般来说,日志有这几种:部署日志、启动日志以及运行日志。
部署日志
我们的应用服务要部署到服务器的时候,会有一系列的打包,编译,上传等过程,这个过程中产生的日志我们一般称为部署日志。
启动日志
服务部署到服务器之后,在启动过程中,加载各个组件,初始化各种数据,这个过程中产生的日志被称为启动日志,很多启动不了的问题,都需要我们去启动日志中查找报错原因。
运行日志
服务运行期间,我们不可能将所有的操作都记录到数据库,也没那个必要,那么这个时候,运行日志的作用就体现出来了,我们一般在一个请求的入口及出口打印上基本的参数及返回结果信息,同时在运行中,在关键的节点去打印一些信息来让我们清楚程序在那个时刻运行状况。
常见的日志组件
介绍了日志的作用,下面我们看看都有哪些日志组件供我们使用,日志发展了这么多年,各类日志组件也是层出不穷,不同的组件都是为了解决当时或者未来的一些问题而出现。常见的一般有:Log4j,Log4j2,slf4j,logback,JUL等。这几种日志组件,如果要选择使用哪个,还是需要去官方文档看下介绍,对比之后再做选择,本文只是对此做个简单介绍。
Log4j
Log4j是Apache的一个开放源代码项目,通过使用Log4j,我们可以控制日志信息输送到不同的地方,如控制台、文件、数据库等;我们也可以控制每一条日志的输出格式;同时,我们还可以通过定义每一条日志信息的级别,使我们能更加细致地控制日志的生成过程。
SLF4J
SLF4J,即简单日志门面(Simple Logging Facade for Java),不是具体的日志解决方案,它允许终端用户在部署时植入所需日志系统。
Log4j2
对Log4j的改良
Logback
Logback,一个“可靠、通用、快速而又灵活的Java日志框架”。主要特点是性能会更好。
JUL
Java自己的日志框架,类似于Log4J,但是API并不完善,对开发者不是很友好,使用人也较少。
日志的使用方式
我们使用日志来查询问题一般有两种方式,一种是直接上服务器用grep命令查,另一种是我们的日志如果有一个统一的日志中心来收集,那么可以在这种地方进行查询。先介绍第一种查询日志的方式。
服务器查询
服务器直接查询日志在效率上也是有高低之分的,如果我们的整个调用链路没有一个唯一标志,那么就费劲了,需要用 -A -B等命令来不断的一点点去看。那么业界比较公认的一种处理方式是,在一个请求的开始,加上一个唯一标志,在整个请求的过程中,所有的日志都会带上整个唯一标志,这样在查询的时候,可以根据这个唯一标志来查询整个请求链路。
总结起来一句话:通过全局id将分布在各个服务上的⼀次请求串联起来,还原调⽤关系,追踪问题,分析数据
实现方式多种多样,核心思想是在一个rpc调用的开始,将这个唯一标志放到上下文中(可以放到threadLocal变量中),进而在打印日志的包装类中,将traceId打印出来即可。
统一日志中心
由于现在大部分服务都是分布式的部署,每次查问题的话就需要到多台机器上去一个个挨着查,效率会不可避免的降低,那么统一日志中心解决的就是这个问题。
以美团的日志中心设计来举例,如下图:
整体架构上来讲,分为四层:
1.业务应用层:业务应用层主要是指业务系统使用公司统一的日志SDK,按日志规范生产Log;
2.日志收集层:负责从分散的业务机器上,收集Log并实时传输到中心的Kafka集群;
3.日志存储计算层:负责存储大量的日志,并实时建立索引;提供查询接口供日志中心查询;负责备份日志;负责对业务指标聚合生产;
4.服务接口层:一方面向应用开发者提供日志查询功能和可视化界面;另一方面向基于日志的应用提供接口API;
以上是本次对日志相关内容的一些总结,内部的一些文章引用没法贴出来,外部文章参考:Log4j、Log4j 2、Logback、SFL4J、JUL、JCL的比较
Log4j,Log4j2,logback比较