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

日志实践推荐

2024-08-18 03:10:37   221人阅读

背景

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

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

日志级别

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

 

日志实践推荐


联系
我们