ftofficer|张聪的blog

这是这个系列的第四部分，也是最后一部分，我们将讨论如何有效的分析调试日志，并给出一些典型的日志分析方法和经验。

如何分析调试日志

当支持人员或者开发人员拿到调试日志时，通常的分析方法是先找到用户遇到的问题所对应的日志，从这里出发，进行跟踪，并分析出现这种问题的原因。在这个过程当中，存在三个必要的步骤：发现问题所对应的日志，跟踪，分析原因，这也是分析调试日志的一般方法。

在整个过程当中，发现问题所对应的日志所在往往会消耗大量的时间。主要原因之一是分析人员拿到的日志往往是最低调试级别的，往往日志的条目非常巨大，而且可能不同
的模块、不同的线程的调试日志混杂在一起，导致难于分析。因此对于如此大量日志，通过必要的辅助工具支持能够大大的提高效率。

第一种辅助工具是日志过滤和切分工具。根据日志的所属的不同模块、级别，或者根据线程或日志的相关性键值，对日志进行过滤和切分，将其划分成多个小的相关的日志模块，将极大的方便进行分析。这种工具可以用脚本实现，或者用grep过滤，甚至直接使用编辑器的查找功能（如ultraedit的“列出所有行”功能），通常将在很多时候就足够了，因此不做细致的讨论。

Tip 23：使用切分和过滤工具将日志根据相关性划分成多个小的日志模块进行分析。

有的时候问题可能出现在不同子系统之间的交互之上，或者对于某一个对象的操作会跨越多个子系统，而不同的子系统的日志文件可能具有不同的文件前
缀。因此，必要时可以用日志组合工具将多个子系统的日志组合之后，再经过日志切分工具进行切分。这种操作通常就需要两个子系统之间保持一定的日志格式的规
约，以便工具可以容易的找到相关性的键值并根据这个键值进行组合。

Tip 24：当需要跨越子系统进行跟踪时，可以使用日志组合工具将日志组合之后再进行切分。

对于划分好的子模块的分析就是发挥人类洞察力的时候了，人类的智慧就应该用在这种地方:)。而一旦通过某种方式发现了问题所对应的日志，接下来的工作就相对简单了。而一旦发现了问题所在，我们建议将这种问题所对应的日志抽取出来适当的模式，并将过程或结果加以记录，用可运行的脚本或需要手动操作的条文都可以。这样未来就可以根据这些积累，快速的确定已知问题。

Tip 25：尝试将已知问题的日志模式加以记录，以便可以在问题到来时容易的确定是否是已知问题。

对于某些特定的问题，我们已经有了相应的日志模式。

第一类问题是程序崩溃，这种情况很容易通过分析PID变动之前的日志查出原因，因此，用某种工具快速的定位PID变动的地方，并查找附近的特征字符串，即可知道是否发生了崩溃。

Tip 26：使用工具定位PID变动的位置并查找特征字符串，可以检测到程序的崩溃。

第一类问题是性能问题或死锁。这也是Tip
18的来源。我们可以通过求出操作开始之前和结束之后的两条日志之间的时间差值来得到这个操作持续的时间，或者识别这些操作是否完成，是否陷
入了无限等待或超时等等。这种模式很容易通过自动化工具来找到。而对于性能问题，可以通过工具分析日志，统计其中最耗时的一些操作，并对其进行统计学分析，对于实际用户环境当中的性能瓶颈也可以有很好的预测，对于将来的设计和改进也是非常重要的资料。

Tip 27：通过分析日志之间的时间差，可以检测性能问题或死锁。

另一种问题是内存或资源的泄漏。虽然这种问题可能不是可以仅仅通过调试日志解决的。但是在有的时候，唯一能够用来调试内存泄漏的只有调试日志，因此先从
调试日志当中分析，有时也能够发现一些问题，至少可以排除掉一些可能。如果根据Tip
19的建议，在对象的构造、拷贝、析构的时候都加上了必要的日志，那么通过简单的脚本扫描所有的相关的日志项即可知道是否所有的对象都得到了正确的析构
了。如果需要对于内存泄漏问题进行更多的分析，也可以建立一种机制，在日志当中记录所有的内存分配和释放的操作，并加以分析。

Tip 28：通过分析日志当中资源分配和释放的配对情况，可以用来检测内存或资源泄漏。

在发现了问题之后，接下来的就是根据日志进行程序执行路径的跟踪。由于可能需要经过复杂的程序执行路径才能够出现问题，完全的手动跟踪是一件非常消耗人力物力的事情。由于在日志当中的记录了代码文件和行数，以及函数名，这种动作也可以一定程度上通过工具自动化寻找下面的执行路径，加快跟踪的速度。

Tip 29：使用自动化工具来辅助路径跟踪。

虽然我们一直在强调辅助工具的重要性，但更重要的还是日志的清晰程度和分析人员的耐心以及洞察力，而这种洞察力往往需要通过经验的积累才能获得。工具只能够用来辅助查找已知问题和给出建议，人的努力才是发现问题、解决问题的最终关键。

Tip 30：工具只是辅助，人的耐心、洞察力和经验才是分析日志的最重要资本。

总结

至此，这个四个部分的文章告一段落。我写这篇个系列文章的目的在于希望能够总结和分享有关调试日志经验，并为接下来的工作当中对于调试日志的书写、处理的标准化作一些思考。这些虽然都经验，但毕竟是一家之言，难免狭隘甚至错误，希望有更多的人可以参与讨论，给出更多的建议和分享更多的经验。