β

关于日志级别的一些想法

Harries Blog™ 493 阅读

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

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

  1. trace 很少用
  2. debug 的话,应该是 开发 阶段会用到的。 类似单步 调试 ,只是通过 log 的形式 打印出来。如果写了也不用删掉,反正在线上一般也不会开启 debug level.

  3. notice 或者 info(叫法不一)。以 tcp/ http 请求为例子, 每次成功的请求都应该有一条 notice/info 日志,以表示该业务正常执行了。也许有人会说: 没有消息就是好消息,即 没有错误日志的时候,逻辑应该是正常执行了呀,为何还多此一举 打印 notice 日志?

    你怎么知道没有错误日志的时候就一定正确执行了,也许那时就是出问题了且没有错误日志输出呢? 所以,我建议 Notice 还是加上。检索的时候,如果觉得某些日志不想看,则过滤掉呗。 但是,该记录的还是得记录,尤其是电商系统这么重要的系统。

  4. warn 有些错误返回,比如 mysql 返回了err no rows,在业务上可能表示该用户不存在 数据库 中。不存在有时候也正常吧,就是这个用户没注册过,但是这确实是个错误返回,所以这时候我一般记为 warn。

  5. 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/

PS:如果您想和业内技术大牛交流的话,请加qq群(521571209)或者关注微信公众 号(AskHarries),谢谢!

转载请注明原文出处: Harries Blog™ » 关于日志级别的一些想法

作者:Harries Blog™
追心中的海,逐世界的梦
原文地址:关于日志级别的一些想法, 感谢原作者分享。