刚刚我们组的产品经理和法务部的同事找我，说公司正在和某个客户打官司。为了反驳客户的某一些说辞，需要我帮忙找一找某个客户的某一份合同文件的操作日志。也就是：
需要确定就是这个客户在某一天的某个时间进入我们的某个系统进行了「合同签署」这个操作
事后我想了一下，里面确实有很多我们平时设计系统，实现系统功能时需要注意的一些点，所以我基于我目前的眼界和经验，总结一下，希望对大家有所帮助，争取不浪费读者朋友们的宝贵的时间。
日志的输出
我觉的最基本的但是也是最重要的事情就是日志的输出。因为没有日志输出也就没有下面要说的「存储收集」和「查询展示」了。
我不确定读者所在的格式是否有日志规范，我觉的有一份好的日志规范还是很重要的，但是最重要的还是有效的执行下去。
统一日志框架
Java里存在众多的开源日志框架，比如：slf4j, logback, log4j, JCL(Apache Common Logging), JUL(JDK自带的java.util.logging)。
我一般都采用SLF4J这个框架，因为它的API很简洁。其实它并不包含日志的实现，而仅仅是提供了众多的适配器来适配其他所有开源的日志框架，这就使得我们在代码中只需要面对SLF4J的API，然后可以任意的切换实现。
也许你们并不需要切换日志框架的实现这个功能，但往往我们的项目都会依赖很多的第三方的开源框架，而这些第三方的开源框架有可能采用不同的日志框架，而不同的日志框架可能需要的配置也不尽相同，不同的配置又可能导致日志输出到不同的位置，这就很不方便我们后续的日志收集和管理。
为了方便我们将日志统一收集和管理起来，我们可以使用slf4j的适配器将第三方库中各种日志的实现接管，接管之后就可以统一配置这些第三方库中使用的日志了。
而logback的性能又非常的好，所以我就选择了logback作为我的日志实现了。
日志的级别
日志有：TRACE， DEBUG， INFO， WARN， ERROR， FATAL这几个隔离级别。
一定要用好日志级别。我的习惯和理解如下：
- TRACE 一般情况下我会用来记录业务日志
- WARN 我一般会在出现了异常情况，但是又在业务的合理范围之类的时候我会适应warn
- INFO 一般非常重要的日志，关键系统参数的回显、后台服务的初始化状态、需要开发者确认的信息我都会适应INFO这个级别。
- DEBUG 详细的记录流程的关键路径，这种级别的日志是为了方便我们开发和调试系统功能的，在生产环境默认是关闭的。
- ERROR 系统出现了异常情况的时候时候
- FATAL 说实话我没有用过，我都用ERROR代替了。
日志的格式和分类
统一定义日志文件的名称，日志内容的格式，可以极大的方便后续日志的收集和解析工作。
大的指导原则是：
- INFO 及以上的系统日志统一输出到Console
- 业务日志、系统日志、异常日志分别输出到不同的文件中，更加方便异常问题的排查
不同类型的系统或者模块对不同功能的日志的侧重是不一样的
根据系统使用场景不同，对日志的侧重点就不一样。导致这些不同侧重点的原因可能有：
- 排查问题的需要
- 来自审计部门的需要
- 数据挖掘的需要
- 为了避免纠纷（这个挺重要的）
- 。。。。。
比如我们做两个系统，一个是「权限管理系统」，另外一个是「信息通知系统」，干一些发邮件，短信等的消息。前者我们需要详细的操作日志，记录「谁在某年某月某日为某人分配了什么权限」，因为审计部门需要。而后者即便发送出错了，重试或者忽略都可以考虑，甚至都不需要记录任何的日志。
系统可能有点大，系统中的一些模块、重要接口对日志的要求也很高，比如我文章开头举得例子，代理商说合同我没有签订，死不承认。这个时候怎么办呢，只能找当时的系统日志来说了。假设当时系统没有输出日志，或者输出的日志信息对于打官司一点用都没有，那么就比较尴尬了。
日志输出的注意点
我不确定大家是否遇到过下面的情况：*排查问题时，发现那块出现错误的地方有日志输出，但是输出的日志对于排查问题一点用都没有**，每当出现这种情况的时候我都想骂人。
好的日志需要有哪些内容呢？
- 发生时间
- 出现问题的线程
- 日志级别
- 出现问题的类文件，类的哪一行，异常栈
- 程序入参
- 相应的程序员的注释等
重要API，系统间交互等地方是加日志，监控的重点位置
临时想到一个，就是日志输出时，尽量输出一些「不可变的或者唯一」的信息。举个例子：
为了在日志中记录某个用户的行为，但是用户的身份可以用自己生成的userId，手机号，身份证号，昵称等。
考虑到昵称和手机号可能会变化，所以使用这两个来在日志中表示用户身份可能就不合适了。也许查询一年前的日志是，但是记录的手机号已经不属于这个用户了。
日志的存储与收集
关于日志的存储方式，无论是使用MySQL，Elasticsearch，HDFS等，都已经很有多的文章和教程了，我就不详细提了。
主要需要注意点是：日志的存储时需要了解清楚日志存储的作用，然后按照某些维度来组织，比如时间，比如操作人等，方便后续聚合、查询，分析等。
另外还需要注意的是日志的存储时间，如果你们的日志是永久存储的话，当我没说哈。一般公司会为了节省存储空间成本，会定期删除一些日志，这个时候需要根据日志的重要性确定是否永久存储，或者定期删除的时间长短。