一、日志分级的定义（摘录）
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
二、正确的对待日志的方式
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"
}
