关于日志记录的一些感想

关于日志记录的一些感想

刚刚咱们组的产品经理和法务部的同事找我,说公司正在和某个客户打官司。为了反驳客户的某一些说辞,须要我帮忙找一找某个客户的某一份合同文件的操做日志。也就是:java

须要肯定就是这个客户在某一天的某个时间进入咱们的某个系统进行了「合同签署」这个操做程序员

过后我想了一下,里面确实有不少咱们平时设计系统,实现系统功能时须要注意的一些点,因此我基于我目前的眼界和经验,总结一下,但愿对你们有所帮助,争取不浪费读者朋友们的宝贵的时间。框架

日志的输出

我觉的最基本的可是也是最重要的事情就是日志的输出。由于没有日志输出也就没有下面要说的「存储收集」和「查询展现」了。性能

我不肯定读者所在的格式是否有日志规范,我觉的有一份好的日志规范仍是很重要的,可是最重要的仍是有效的执行下去。线程

统一日志框架

Java里存在众多的开源日志框架,好比:slf4j, logback, log4j, JCL(Apache Common Logging), JUL(JDK自带的java.util.logging)设计

我通常都采用SLF4J这个框架,由于它的API很简洁。其实它并不包含日志的实现,而仅仅是提供了众多的适配器来适配其余全部开源的日志框架,这就使得咱们在代码中只须要面对SLF4J的API,而后能够任意的切换实现。代理

也许大家并不须要切换日志框架的实现这个功能,但每每咱们的项目都会依赖不少的第三方的开源框架,而这些第三方的开源框架有可能采用不一样的日志框架,而不一样的日志框架可能须要的配置也不尽相同,不一样的配置又可能致使日志输出到不一样的位置,这就很不方便咱们后续的日志收集和管理。调试

为了方便咱们将日志统一收集和管理起来,咱们可使用slf4j的适配器将第三方库中各类日志的实现接管,接管以后就能够统一配置这些第三方库中使用的日志了。日志

logback的性能又很是的好,因此我就选择了logback做为个人日志实现了。code

日志的级别

日志有:TRACE, DEBUG, INFO, WARN, ERROR, FATAL这几个隔离级别。

必定要用好日志级别。个人习惯和理解以下:

  • TRACE 通常状况下我会用来记录业务日志
  • WARN 我通常会在出现了异常状况,可是又在业务的合理范围之类的时候我会适应warn
  • INFO 通常很是重要的日志,关键系统参数的回显、后台服务的初始化状态、须要开发者确认的信息我都会适应INFO这个级别。
  • DEBUG 详细的记录流程的关键路径,这种级别的日志是为了方便咱们开发和调试系统功能的,在生产环境默认是关闭的。
  • ERROR 系统出现了异常状况的时候时候
  • FATAL 说实话我没有用过,我都用ERROR代替了。

日志的格式和分类

统必定义日志文件的名称,日志内容的格式,能够极大的方便后续日志的收集和解析工做。

大的指导原则是:

  • INFO 及以上的系统日志统一输出到Console
  • 业务日志、系统日志、异常日志分别输出到不一样的文件中,更加方便异常问题的排查

不一样类型的系统或者模块对不一样功能的日志的侧重是不同的

根据系统使用场景不一样,对日志的侧重点就不同。致使这些不一样侧重点的缘由可能有:

  • 排查问题的须要
  • 来自审计部门的须要
  • 数据挖掘的须要
  • 为了不纠纷(这个挺重要的)
  • 。。。。。

好比咱们作两个系统,一个是「权限管理系统」,另一个是「信息通知系统」,干一些发邮件,短信等的消息。前者咱们须要详细的操做日志,记录「谁在某年某月某日为某人分配了什么权限」,由于审计部门须要。然后者即使发送出错了,重试或者忽略均可以考虑,甚至都不须要记录任何的日志。

系统可能有点大,系统中的一些模块、重要接口对日志的要求也很高,好比我文章开头举得例子,代理商说合同我没有签定,死不认可。这个时候怎么办呢,只能找当时的系统日志来讲了。假设当时系统没有输出日志,或者输出的日志信息对于打官司一点用都没有,那么就比较尴尬了。

日志输出的注意点

我不肯定你们是否遇到过下面的状况:*排查问题时,发现那块出现错误的地方有日志输出,可是输出的日志对于排查问题一点用都没有**,每当出现这种状况的时候我都想骂人。

好的日志须要有哪些内容呢?

  • 发生时间
  • 出现问题的线程
  • 日志级别
  • 出现问题的类文件,类的哪一行,异常栈
  • 程序入参
  • 相应的程序员的注释等

重要API,系统间交互等地方是加日志,监控的重点位置

临时想到一个,就是日志输出时,尽可能输出一些「不可变的或者惟一」的信息。举个例子:

为了在日志中记录某个用户的行为,可是用户的身份能够用本身生成的userId,手机号,身份证号,昵称等。

考虑到昵称和手机号可能会变化,因此使用这两个来在日志中表示用户身份可能就不合适了。也许查询一年前的日志是,可是记录的手机号已经不属于这个用户了。

日志的存储与收集

关于日志的存储方式,不管是使用MySQL,Elasticsearch,HDFS等,都已经颇有多的文章和教程了,我就不详细提了。

主要须要注意点是:日志的存储时须要了解清楚日志存储的做用,而后按照某些维度来组织,好比时间,好比操做人等,方便后续聚合、查询,分析等。

另外还须要注意的是日志的存储时间,若是大家的日志是永久存储的话,当我没说哈。通常公司会为了节省存储空间成本,会按期删除一些日志,这个时候须要根据日志的重要性肯定是否永久存储,或者按期删除的时间长短。

相关文章
相关标签/搜索