关于日志的几个想法

场景还原

先说个场景：

APP上某个操作出现了 系统异常。错误码：abc012，我们收到错误码之后，可以一次性查出这条请求完整的请求路径，穿越了哪几个服务，出错的代码堆栈信息，甚至中间发生了哪些 SQL 查询。这样我们基本在脑子里复现整个场景了。

其中涉及的几个地方：

• 错误码：很多时候并不能得到这个错误截图，我们可以用户反馈的时间、用户ID、功能大致定位到。错误码放在全局的 response header 里

• 请求轨迹：在请求来的时候加个 traceId，这个 traceId 注入到后面的 logger 和 client，这样所有的log就都能识别了。

• 堆栈信息：像 Php Java 可以很方便的在出现 ERROR 时把堆栈信息跑出去（Php还能记录每个函数的调用参数）。我们用 Go 比较麻烦一些，要专门加个记录 stack 的 error 类型。

• SQL日志：这个看需要了，如果你的 ORM 框架对钩子支持好，加起来也不是难事。

日志框架

功能上，个人觉得有个强大的 Hook 就够了。这样每个团队都可以根据自己需要来加自己需要的东西

• Hook

  • 继承 context

  • 必要时候输出代码位置信息

• Keyword

• Extra Map

输出和存储

• 格式：支持不同环境下不同的格式，比如dev模式，关键字就挺好。线上可能需要以json格式打到相关的日志服务里。

• 分卷存储：有的框架会按照日期来分文件，个人觉得没必要，可以用 logrotate 这样专业的工具来做。还有一种思路，用 rsyslog 把日志导出到你的日志服务里去，本机的日志，不用存多少就可以删掉了。

监控报警

• 如果性能没那么苛刻，推荐直接集成 Sentry

• 如果团队实力比较强，可以根据日志做各种分析和监控，参考 open-falcon

参考

• 优秀日志实践准则