2019-03 服务日志级别调研

一、日志分级的定义（摘录）

1. 文林福写的wiki中提到

log的主要目的：便于观察线上服务是否正常、数据统计、问题跟进。
log打印的基本原则：简明扼要。在能清楚表达所要打印的信息的情况下，越短越好。主要是log打印太多会提高存储、传输和分析的代价

log分级：

  debug：用于调试时打印的信息，上线时需要关闭，如果是前期需要观察线上数据，可以临时打开一段时间，一个请求可以打多条记录

  INFO：记录非常重要的信息，一个请求可以打印1-3条（一般开始1条，结束一条），能合并的尽量合并。记录请求的id、请求类型，做了什么事情、结果、状态、时间等（根据自己需要）。log合并的好处是在数据分析和统计的时候可以在1条log中获取所有的信息，而信息打印在不同的log记录中，需要做合并操作，会非常麻烦。此外无论请求成功了还是失败了，都需要打一条INFO log，用状态码区分就行

  WARN：警告日志，出现了预期之外的信息，但是程序不影响程序运行的。比如：传递过来的图片解码失败

  FATAL: 致命错误日志：类似磁盘空间不够了，分配内存和端口失败这种

2. 王健的知乎专栏：最佳日志实践

FATAL — 表示需要立即被处理的系统级错误。这属于最严重的日志级别（必须慎用），通常一个进程的生命周期中应该只记录一次FATAL级别的日志，即该进程遇到无法恢复的错误而退出时。
ERROR — 当ERROR错误发生时，需要立即处理——表示已经影响了用户的正常访问，但服务没有挂掉。这种级别的日志属于服务错误，而不是用户自己操作不当，请求参数错误等等。
WARN — 该日志表示系统可能出现潜在问题。这个级别表明不需要立即处理，但也是需要查看并处理的。因此此种级别的日志也不应太多。
INFO — 该种日志记录系统的正常运行状态，例如某个子系统的初始化，某个请求的成功执行等等。通过查看INFO级别的日志，可以很快地对系统中出现的 WARN,ERROR,FATAL错误进行定位。INFO日志不宜过多，通常情况下，INFO级别的日志应该不大于TRACE日志的10%；
DEBUG or TRACE — 作用是对系统每一步的运行状态进行精确的记录。可以保证在不重现错误的情况下，也可以通过DEBUG（或TRACE）级别的日志对问题进行诊断。

3. stackoverflow回答 - Hansaka perera

Trace - Only when I would be "tracing" the code and trying to find one part of a function specifically.

Info - Generally useful information to log (service start/stop, configuration assumptions, etc). Info I want to always have available but usually don't care about under normal circumstances. This is my out-of-the-box config level.

Warn - Anything that can potentially cause application oddities, but for which I am** automatically recovering**. (Such as switching from a primary to backup server, retrying an operation, missing secondary data, etc.)

Error - Any error which is fatal to the operation, but not the service or application (can't open a required file, missing data, etc.). These errors will force user (administrator, or direct user) intervention. These are usually reserved (in my apps) for incorrect connection strings, missing services, etc.

Fatal - Any error that is forcing a shutdown of the service or application to prevent data loss (or further data loss). I reserve these only for the most heinous errors and situations where there is guaranteed to have been data corruption or loss.

4. stackoverflow回答 - Peter Mortensen

Would you want the message to get a system administrator out of bed in the middle of the night?

yes -> error

no -> warn

+ 引用

文林福 涉及公司内容，链接隐去

王健 - https://zhuanlan.zhihu.com/p/27363484

stackoverflow问题

二、正确的对待日志的方式

1. 不断优化日志

源自 - 王健

好的日志就像好的文章一样，绝不是一遍就可以写好的，而需要在实际的运维过程中，结合线上问题的定位，不断地进行优化。最关键的一点是，团队要重视日志优化这件事情，不要让日志的质量持续降低。

好的实践：

• 在定位问题的过程中完善日志，如果定位问题花费了很长时间，那就说明系统日志还存在问题，需要进一步完善和优化；

• 需要思考是否可以通过优化日志，来提前预判该问题是否可能发生;

• 定义好整个团队记录日志的规范，保证每个开发记录的日志格式统一；定期对日志内容进行Review；

2. 对现状做一个个人评价

根据上述的一些结论，发现team的代码：

• fatal级别：基本上API服务的处理较好，panic、runtime-errorr这类问题并不会直接服务重启，而是会被中间代码兜住并打出一个error级日志，符合预期；RPC服务未确认，似乎大多数没有做很好的兜底，也没有导致服务崩溃时的fatal日志。

• error：现状是非常随意，一些不会引发接口错误、次要的字段、无需立即处理的问题，往往不合预期就被打上一条error日志。使tce上线时经常上得惊心动魄，提示出现严重错误，很不友好。

• warn：基本符合预期，对非重要功能的调用失败、参数错误、打上warning

• info：有一些意义不明的内容打上了info（到底是想要作为业务warn还是一条trace？）

• trace：用得较少，可以通过CtxPushNotice把键值对塞进这个级别中，用于追踪请求细节。

总结来说，还有不少进步空间。

- 引用

王健 - https://zhuanlan.zhihu.com/p/27363484

三、负面场景

• 避免使用简单的无意义的字符串输出日志
  logging.error(u'执行错误')
• 避免通过多条日志记录同一个事件
  # 这种日志可以通过最后的一条日志，进行整体的记录，将开始和结束时的关键信息通过变量参数的形式记录
  logging.info(u'开始')
  logging.info(u'结束')
  logging.info(u'消耗时间' + end_time - start_time)
• 代码举例

// 数据已影响函数正常执行应该打warning，且日志信息不足
func work0(ctx context.Context, input int) {
  if input < 0 {
      logs.CtxInfo(ctx, "[CommandTrans] invalid parameter")
      return
}
// 占用日志空间的info日志，应该用trace日志将一次请求的信息汇总成一条
func work1(ctx context.Context) string {
  logs.CtxInfo(ctx, "xxxx")
  return "test"
}