迁移自简书，格式可能未经校对。
场景还原
先说个场景：
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
