1回答

Jimin

2018-01-21

已采纳

你好，关于日志如何记确实是一个特别值得讨论的课题，如何记好日志也是一门艺术。因此呢，一个回复很难面面俱到，只能针对你的问题有针对性的回答，希望能对你有所帮助。

首先，日志如何记，肯定不是根据需求来定的。日志本身是给开发人员使用的，准确的说是给开发团队使用的。当系统出问题或者一些特殊场合，开发人员需要去找到当时的日志，通过分析日志并结合当时的代码(代码后期可能被改过)来确定当时数据和流程是什么样子的，最终定位问题原因。

这时，在哪里记日志，记录什么信息就显得尤为关键，每执行一行代码就记录一条日志肯定不合适，具体可以参考我之前针对日志记录写的一篇手记，https://www.imooc.com/article/21178 （这篇手记很可能是你能学习到东西最多，有许多记录日志的最佳实践）

需要注意的是，日志记录不是自己能看懂就可以，要整个团队都能看得懂，因为不是你写的日志就你自己去看~

接下来说点更高层面的：

当前特别流行分布式及服务化（一个请求需要经过系统中多个模块，上百台机器的协作完成单次请求），导致同一个流程的日志可能出现在多个服务器的多个项目中，因此呢，Google Dapper（没听过的话，自己去查一下相关的概念） 等全链路trace技术也跟着出现了。这样，一个请求在不同模块的整个流程能通过唯一的一个值进行标识，查询时先确定好这个traceId就可以了，然后不断的在不同的系统不同的服务器的日志里查这个traceId就可以了。

当然了，这样并没有完，一个全链路trace并不能完全解决日志查询难的问题，只是将同一个请求的整个链路拿到了，方便根据这个traceId去查询请求的整个日志而已，对于上百台的服务器那种，你挨个去看日志也不是个办法，因此呢许多公司都建立了专门的日志平台，统一搜集起来然后提供查询界面。

这时呢，假如查询一个订单的处理过程，理想的情况下就会是：可以先拿订单号去日志平台搜一下日志，这时正常会出现多个traceId, 然后依次去查traceId，就可以得到这个订单的所有处理流程。当然了，这里也间接的告诉你，涉及到订单处理时，核心的订单号是一定要出现在日志里的~

实际中，我们也会要求系统里的报警也需要能轻松通过日志查询到，就是报警的关键字，也记录在日志了，这样系统报警时我们能最快的拿到对应的日志进行分析。这也算是一条最佳实践。

说了这些，是不是感觉记日志也是一门艺术活了^_^

结尾，关于日志两方面，先学如何记才能让你通过分析日志得到问题的答案，然后考虑如何查询起来更方便~

2

1

bearsmall

非常感谢！

2018-03-03

共1条回复