日志自动分析

为什么要推出日志自动分析？

在分析崩溃问题的过程中，可能常常会遇到这种情况，崩溃线程的出错堆栈全是系统堆栈，通过出错堆栈本身并不能定位导致异常的原因。

如下图所示，我们只知道渲染线程异常终止了，导致SIGABRT的原因有很多，单纯从出错堆栈根本没有办法继续定位原因。

这种情况下，我们往往会借助于崩溃时捕获的系统日志来辅助分析。如下图所示，这个案例应该是内存不足导致渲染异常。从日志中，我们看到关键日志「OpenGLRenderer: GL error: Out of memory!」。

接着再分析另外一份日志，看到另一类关键信息，「No pending exception expected: java.lang.OutOfMemoryError: OutOfMemoryError thrown while trying to throw OutOfMemoryError; no stack trace available 」。

但是，这个问题上报的个例有1773个，我们不可能逐一分析每个案例来计算每类情况的占比。我们需要有一个自动分析工具，可以自动对一批个例的日志进行分析。

怎样使用日志自动分析？

在Android平台的崩溃/ANR/错误等监控项的问题详情中，新增了「日志自动分析」入口，点击即可快速查看分析结果。

默认情况下，切换到「日志自动分析」Tab后，会自动分析最近7天的上报日志。默认展示三个数据，满足条件的个例数，这些个例包含有效日志文件数，以及真正用来分析的文件数。

• 崩溃时获取系统日志，有一定的失败概率，所以并不是所有的个例都包含日志文件。因此，我们看到「这些个例包含有效日志文件」往往要比「满足条件的个例」要小。
• 我们分析发现，当日志文件的数量达到一个量级时，增加日志文件的数量，并不会影响日志分析结果。因此，基于效率考虑，日志分析系统在分析一定量级的日志后，发现持续增加一批量日志后，分析结果没有明显变化时，就自动停止追加。因此我们看到，「这些个例包含有效日志文件」比较大时，「分析使用文件」要小于「这些个例包含有效日志文件」。

除上述三个数据后，接下来就是分析结果，基于权重，出现文件频次，出现频次来排序得到日志行信息。

• 默认展示Top 100行分析日志。
• 查看更多可以查看Top 500行分析日志。
• 下载到本地可以查看Top 5000行分析日志。

分析结果是基于什么原则排序的？

我们会对日志进行分析，提取时间，进程/线程号，日志级别和日志信息几部分。如下所示，E表示日志级别，「OpenGLRenderer: GL error: Out of memory!」是日志信息部分。

02-22 21:25:41.723 4496 4913 E OpenGLRenderer: GL error: Out of memory!

对每一个日志的每一行日志，进行类似分析，然后统计日志信息的出现频次。重点考虑两个出现频次:

• 出现文件频次：指的是多少个文件中包含相关的日志信息。例如共有100个日志文件，如果80个文件中都包含该日志信息，则出现文件频次为80，占比 = 80 / 100 = 80%。
• 出现频次：指的是这一批日志生成的所有日志信息中，该日志信息的出现频次。例如共有100个文件，平均每个文件有90行，即总共有9000行日志。该日志信息总共出现了3000次，则出现频次为3000次，占比 = 3000 / 9000。

不同的日志级别被赋予了不同的权重，权重：E = 1，W = 0.8，其他为 0.6。

最终，排序因子 = 权重 x 出现文件频次。

欢迎大家体验「日志自动分析」功能，多多反馈意见，Bugly将持续完善，为大家提供更加强大的自动分析能力。

Bugly是 TDS 腾讯端服务（Tencent Device-oriented Service）旗下的端质量监控平台，致力于提供专业的监控定位服务，协助用户打造高质量App。