转载

关于日志级别的一些想法

备注：本文讨论的范畴是服务端日志。

常见的日志级别有 trace/debug/notice/warn/fatal 这些吧（不同的日志库叫法不一，大同小异）

trace 很少用
debug 的话，应该是开发阶段会用到的。类似单步调试，只是通过 log 的形式打印出来。如果写了也不用删掉，反正在线上一般也不会开启 debug level.
notice 或者 info(叫法不一)。以 tcp/http 请求为例子，每次成功的请求都应该有一条 notice/info 日志，以表示该业务正常执行了。也许有人会说：没有消息就是好消息，即没有错误日志的时候，逻辑应该是正常执行了呀，为何还多此一举打印 notice 日志？

你怎么知道没有错误日志的时候就一定正确执行了，也许那时就是出问题了且没有错误日志输出呢？所以，我建议 Notice 还是加上。检索的时候，如果觉得某些日志不想看，则过滤掉呗。但是，该记录的还是得记录，尤其是电商系统这么重要的系统。
warn 有些错误返回，比如 mysql 返回了err no rows，在业务上可能表示该用户不存在数据库中。不存在有时候也正常吧，就是这个用户没注册过，但是这确实是个错误返回，所以这时候我一般记为 warn。
fatal/error （有的日志库区分了 fatal 和 error， fatal 比 error 高）出现这种错误，应该是要马上处理了。如果不是需要马上处理的，则不应该是 fatal 级别。但是我还是不太明白，为何我们某些业务的日志有这么多的 fatal 日志。

测试环境建议是 Debug 级别，方便排查问题

生产环境一般是 Notice, 特殊情况如大型电商活动期间，访问量非常高，如双11那种，则应该开到 warn 甚至 fatal。

而且开发管理后台应具备一键切换到 warn/fatal 级别，以快速响应特殊情况的需求。这个功能在实现上，我觉得在日志收集组件上实现会简单些。

记住一点：日志是为了排查问题用的。如果关键时候排不上用场，要你何用！

以上，是我的一些很初级的想法。会不定期更新此文。

本文地址 http://holys.im/2017/02/09/thoughts-on-logging/

原文 https://holys.im/2017/02/09/thoughts-on-logging/

正文到此结束