首页 > 代码库 > 日志实践推荐

日志实践推荐

背景


软件系统生产稳定,依靠着各种高可用、高吞吐、高性能的设计。一旦出现生产问题,常常需要线上定位问题。

日志则是必备的,问题定位利器。常常出现线上问题,我们都可以通过日志精确定位。同时在开发过程中,由于极长的调用链难以快速定位问题或难以复现时,它是极好的利器。

日志级别


一个项目各个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命令,在遇到不同的错误行为时,分别针对性的给出了报错信息。

 

日志实践推荐