背景
软件系统生产稳定，依靠着各种高可用、高吞吐、高性能的设计。一旦出现生产问题，常常需要线上定位问题。
日志则是必备的，问题定位利器。常常出现线上问题，我们都可以通过日志精确定位。同时在开发过程中，由于极长的调用链难以快速定位问题或难以复现时，它是极好的利器。
日志级别
一个项目各个log级别的定义应该是清楚明确的，是每个开发人员所遵循的；
即使是TRACE或者DEBUG级别的日志，也应该有一定的规范，要保证除了开发人员自己以外，包括测试人员和运维人员都可以方便地通过日志定位问题；
FATAL
表示需要立即被处理的系统级错误。
当该错误发生时，表示服务已经出现了某种程度的不可用，系统管理员需要立即介入。
这属于最严重的日志级别，因此该日志级 别必须慎用，如果这种级别的日志经常出现，则该日志也失去了意义。
通常情况下，一个进程的生命周期中应该只记录一次FATAL级别的日志，即该进程遇到无 法恢复的错误而退出时。
当然，如果某个系统的子系统遇到了不可恢复的错误，那该子系统的调用方也可以记入FATAL级别日志，以便通过日志报警提醒系统管 理员修复；
ERROR
该级别的错误也需要马上被处理，但是紧急程度要低于FATAL级别。
当ERROR错误发生时，已经影响了用户的正常访问。从该意义上来说，实际上 ERROR错误和FATAL错误对用户的影响是相当的。
FATAL相当于服务已经挂了，而ERROR相当于好死不如赖活着，然而活着却无法提供正常的服务，只能不断地打印ERROR日志。
特别需要注意的是，ERROR和FATAL都属于服务器自己的异常，是需要马上得到人工介入并处理的。
而对于用户自己 操作不当，如请求参数错误等等，是绝对不应该记为ERROR日志的；
WARN
该日志表示系统可能出现问题，也可能没有，这种情况如网络的波动等。
对于那些目前还不是错误，然而不及时处理也会变为错误的情况，也可以记为WARN日 志，例如一个存储系统的磁盘使用量超过阀值，或者系统中某个用户的存储配额快用完等等。
对于WARN级别的日志，虽然不需要系统管理员马上处理，也是需要 即使查看并处理的。
因此此种级别的日志也不应太多，能不打WARN级别的日志，就尽量不要打；
INFO
该种日志记录系统的正常运行状态，例如某个子系统的初始化，某个请求的成功执行等等。
通过查看INFO级别的日志，可以很快地对系统中出现的 WARN,ERROR,FATAL错误进行定位。
INFO日志不宜过多，通常情况下，INFO级别的日志应该不大于TRACE日志的10%；
DEBUG or TRACE
这两种日志具体的规范应该由项目组自己定义，该级别日志的主要作用是对系统每一步的运行状态进行精确的记录。
通过该种日志，可以查看某一个操作每一步的执 行过程，可以准确定位是何种操作，何种参数，何种顺序导致了某种错误的发生。
可以保证在不重现错误的情况下，也可以通过DEBUG（或TRACE）级别的 日志对问题进行诊断。
需要注意的是，DEBUG日志也需要规范日志格式，应该保证除了记录日志的开发人员自己外，其他的如运维，测试人员等也可以通过 DEBUG（或TRACE）日志来定位问题；
在出错时，日志中包含尽量多的有用上下文信息
为什么可以这么做？
日志过多大家伙会说影响性能，但是值得指出的是出错是小概率分支。如果是出错是大概率分支那，打日志以外操作更会成为瓶颈！
多打日志减少支持时间，比起开发所用的实现时间，线上和线下的排查/支持要花费很多时间；
别吞噬异常！
抓住异常没有书写人和响应日志，将导致难以定位。 @Override public UserAmountStat getUserYestodayStat(Long userId, String day) throws GlobalServiceException { // TODO Auto-generated method stub try { UserAmountStat stat = userAmountStatMapper.getUserYestodayStat(userId, day); if (stat == null) { stat = new UserAmountStat(); stat.setBet(0l); stat.setPrize(0l); stat.setBonus(0l); } return stat; } catch (Exception e) { // TODO: handle exception throw new GlobalServiceException(e); } } |
此处推荐的需要在日志中记录的内容
- 在系统启动或初始化时记录重要的系统初始化参数
- 记录系统运行过程中的所有的错误
- 记录系统运行过程中的所有的警告
- 在持久化数据修改时记录修改前和修改后的值
- 记录系统各主要模块之间的请求和响应
- 重要的状态变化（如对系统白名单的修改等）
- 系统中一些长期执行的任务的执行进度
- 服务信息：接口、方法、版本等等
- 如果是超时，配置的超时时间，本次处理所用的时间，是Server端超时还Client超时？
- 重试的次数，本次重试的是第几次（fail over）
RequestID
将一个请求的整个处理流程和唯一的requestID关联起来，requestID规则另行定义。
日志输出级别
在设置日志输出级别时，推荐如下：
- 开发、测试环境打开DEBUG；
- 线上生产环境保证设置为WARN级别；
关于日志分类
日志从功能来说，可分为诊断日志、统计日志、审计日志。
诊断日志：
- 请求入口和出口
- 外部服务调用和返回
- 资源消耗操作: 打开文件等
- 容错行为： 譬如云硬盘的副本修复操作
- 程序异常： 譬如数据库无法连接
-
后台操作：清理程序
-
启动、关闭、配置加载
-
抛出异常时，不记录日志
统计日志：
- 用户访问统计
- 计费日志（如记录用户交易流水日志，格式较为严格，便于统计）
审计日志：
- 管理操作（类似于登录信息记录）
关于日志格式
日志格式一定要统一，不能任由开发人员的喜好来。举例来说，对于NOS视频截图超时的ERROR日志，有以下几种方式打印：
第一种：logger.error(“Gearman timeout exception for request ” + getRequestID() + ” value: ” + value, e);第二种：logger.error(“RequestID: ” + getRequestID() + “, Error Message: Gearman timeout exception: ” + e);第三种：logger.error(getErrorMessage(getRequestID(), getErrorMessage(), e)); |
第一种方式打印日志即是开发人员按照自己的喜好来的，这种方法带来的问题是：
- 系统中日志格式不统一，不利于自动化处理
- 有些日志可能只有开发人员自己才能看懂
- 代码规范性不好
而第三种方式，通过一个函数来规范日志格式，所有开发人员便可以通过该接口实现统一的日志。
关于日志语义
日志书写语义一定要明确，定义明确语义的异常类信息，在此列举linux环境下两个报错信息作为示例；
[root@ip-172-31-1-43 ~]# cd /file-bash: cd: /file: 没有那个文件或目录[root@ip-172-31-1-43 ~]# cd build-public-ult_6.0-2015-09-02-17_6d3c3ee51a.tar.gz-bash: cd: build-public-ult_6.0-2015-09-02-17_6d3c3ee51a.tar.gz: 不是目录 |
我们可以看到同样是cd命令，在遇到不同的错误行为时，分别针对性的给出了报错信息。