[总结]日志格式
1. 概述
统一日志服务使用了分布式跟踪技术来收集和存储分散在各个应用或接口服务的日志,这些日志可用于后续的运维、监控和统计分析。
分布式跟踪技术把每次请求的整个调用链记录下来,可以方便的查看一次请求从客户端到应用服务器到数据库等每个阶段的执行情况,详细参考OpenTracing。
在统一日志服务中的日志分为以下几种类别:
- 跟踪日志(由调用者发出的请求日志)
- 程序日志(代码执行过程中产生的日志)
- 操作日志(带有业务含义的日志记录)
在分布式跟踪日志系统中,要求所有的应用日志都可以通过一次请求关联起来,形成一条完整的调用链。
1-1. 跟踪日志
跟踪日志记录从客户端发起的每次调用执行情况,客户端包括浏览器、移动应用、后台服务等,请求可以由用户(人)发起或者系统发起(无用户信息)。
跟踪日志主要包含了技术层面的信息,如客户端IP地址、请求地址、开始时间、执行时长、执行状态、请求大小等,一般用于分析系统层面的问题,比如执行慢,错误率等。
在统一日志服务中,一次完整的请求被划分为多个具有层次关系Span,每个Span都包含一条跟踪记录,一个完整的请求日志需要由多个Span的跟踪记录组成。
1-2. 程序日志
程序日志记录了应用系统在响应每次请求时代码执行的详细信息,通常硬编码在代码中,并通过日志框架输出到文件,如Java平台种的log4j或者logback等框架。
在统一日志服务中,程序日志需要和请求日志进行关联。
1-3. 操作日志
操作日志是在一次请求(须由用户发起)中记录用户在业务或功能层面做了什么。
操作日志主要记录的是非技术层面的信息,如用户姓名、功能模块、行为(或动作)、影响的数据(或资源)等,一般用于安全审计和事后回溯等。
在分布式跟踪日志系统中,操作日志需要和请求日志进行关联。
注:登录日志理论上归属于操作日志,但在日志系统中一般单独归类,便于查询
2. 系统架构
统一日志服务由以下几部分组成:
- 日志数据库(Database)
- 请求跟踪器(Tracer)
- 日志采集器(Collector)
- 管理控制台(Console)
2-1. 日志数据库
日志数据库使用Elasticsearch,用于集中保存和查询所有日志,支持分布式部署、海量日志存储、高性能日志查询等。
2-2. 请求跟踪器
请求跟踪器采用OpenTracing标准,用于产生一次请求中关键环节的日志记录,一般需要植入到应用代码或者部署到应用所在机器上执行。
OpenTracing目前只定义了规范和接口,具体的实现可以使用第三方开源方案或者自行开发。
2-2-1-1. Zipkin跟踪器
Zipkin是Twitter开源的分布式跟踪系统,兼容OpenTracing规范,支持多种语言。
2-2-1-2. Jaeger跟踪器
Jaeger是Uber开源的分布式跟踪系统,兼容OpenTracing规范,支持多种语言。
2-2-1-3. 自定义跟踪器
应用可根据OpenTracing规范和统一日志服务中的日志格式自行实现。
2-3. 日志采集器
日志采集器用于采集应用通过跟踪器产生的日志并发送到Elasticsearch中保存。
2-3-1-1. Filebeat采集器
Filebeat是Elastic官方的产品,用于收集文件的内容并发送到Elasticsearch中进行存储。
统一日志服务推荐使用Filebeat作为默认的采集器。
2-3-1-2. Logstash采集器
Logstash也是Elastic官方的产品,作用和Filebeat类似,相比Filebeat提供了更为强大的数据处理能力,但也更为重量级一些,需要消耗更多的系统资源。
2-3-1-3. 自定义采集器
应用如果不使用Logstash采集日志,也可根据后面描述的采集规范自行实现。
2-4. 管理控制台
管理控制台是一个Web应用,用于给IT管理员进行日志系统的管理设置以及给应用管理员查看分析各自应用的日志数据
3. 日志格式
日志数据统一使用Elasticsearch进行存储,有很多第三方的工具、框架都支持与Elasticsearch对接,包括Elastic Stack自身的Logstash、Beats等,日志接口直接开放Elasticsearch的索引(Index)进行写入和查询。
根据日志类型的不同,日志的索引也分为跟踪日志、程序日志和操作日志。
4. 日志接口
日志接口直接使用Elasticsearch的Indices APIs、Document APIs和Search APIs。
5. 日志框架
5-1. 禁止直接使用框架
目前有哪些框架被广泛的使用。
1、j.u.l
j.u.l是java.util.logging包的简称,是JDK在1.4版本中引入的Java原生日志框架。Java Logging API提供了七个日志级别用来控制输出。这七个级别分别是:SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST。
5-1-1-1. 2、Log4j
Log4j是Apache的一个开源项目,通过使用Log4j,我们可以控制日志信息输送的目的地是控制台、文件、GUI组件,甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等;我们也可以控制每一条日志的输出格式;
通过定义每一条日志信息的级别,我们能够更加细致地控制日志的生成过程。Log4也有七种日志级别:OFF、FATAL、ERROR、WARN、INFO、DEBUG和TRACE。
最令人感兴趣的就是,这些可以通过一个配置文件来灵活地进行配置,而不需要修改应用的代码。
3、LogBack
LogBack也是一个很成熟的日志框架,其实LogBack和Log4j出自一个人之手,这个人就是Ceki Gülcü。
logback当前分成三个模块:logback-core,logback- classic和logback-access。
logback-core是其它两个模块的基础模块。
logback-classic是Log4j的一个改良版本。此外logback-classic完整实现SLF4J API使你可以很方便地更换成其它日记系统如Log4j或j.u.l。
logback-access访问模块与Servlet容器集成提供通过Http来访问日记的功能。
5-1-1-2. 4、Log4j2
前面介绍过Log4j,这里要单独介绍一下Log4j2,之所以要单独拿出来说,而没有和Log4j放在一起介绍,是因为作者认为,Log4j2已经不仅仅是Log4j的一个升级版本了,而是从头到尾被重写的,这可以认为这其实就是完全不同的两个框架。
关于Log4j2解决了Log4j的哪些问题,Log4j2相比较于Log4j、j.u.l和logback有哪些优势,我们在后续的文章中介绍。
5-2. 使用日志Facade
5-2-1-1. 1、SLF4J
Java简易日志门面(Simple Logging Facade for Java,缩写SLF4J),是一套包装Logging 框架的界面程式,以外观模式实现。可以在软件部署的时候决定要使用的 Logging 框架,目前主要支援的有Java Logging API、Log4j及logback等框架。以MIT 授权方式发布。
SLF4J 的作者就是 Log4j和Logback 的作者 Ceki Gülcü,他宣称 SLF4J 比 Log4j 更有效率,而且比 Apache Commons Logging (JCL) 简单、稳定。
其实,SLF4J其实只是一个门面服务而已,他并不是真正的日志框架,真正的日志的输出相关的实现还是要依赖Log4j、logback等日志框架的。
由于SLF4J比较常用,这里多用一些篇幅,再来简单分析一下SLF4J,主要和Log4J做一下对比。相比较于Log4J的API,SLF4J有以下几点优势:
- Log4j 提供 TRACE, DEBUG, INFO, WARN, ERROR 及 FATAL 六种纪录等级,但是 SLF4J 认为 ERROR 与 FATAL 并没有实质上的差别,所以拿掉了 FATAL 等级,只剩下其他五种。
- 大部分人在程序里面会去写logger.error(exception),其实这个时候Log4j会去把这个exception tostring。真正的写法应该是logger(message.exception);而SLF4J就不会使得程序员犯这个错误。
- Log4j间接的在鼓励程序员使用string相加的写法(这种写法是有性能问题的),而SLF4J就不会有这个问题 , 你可以使用logger.error(“{} is+serviceid”,serviceid);
- 使用SLF4J可以方便的使用其提供的各种集体的实现的jar。(类似commons-logger)
- 从commons–logger和Log4j merge非常方便,SLF4J也提供了一个swing的tools来帮助大家完成这个merge。
- SLF4J 只支持 MDC,不支持 NDC。
- 提供字串内容替换的功能,会比较有效率,说明如下:
5-2-1-2. 2、commons-logging
Apache Commons Logging是一个基于Java的日志记录实用程序,是用于日志记录和其他工具包的编程模型。它通过其他一些工具提供API,日志实现和包装器实现。
commons-logging和SLF4J的功能是类似的,主要是用来做日志 门面的。提供更加好友的API工具。