Android 日志系统7——Android 平台日志丢失问题分析

前言

下面针对一些典型场景缺通用日志(android/kernel)的问题，一一列举如下，希望可以让大家关注到缺日志的真实原因。如下问题也提醒各位工程师: 谨慎添加日志，不要随意添加，否则极容易造成自己的日志缺失也会导致其他业务模块丢失日志。

通用日志丢失目前有如下情况会出现：

(1) liblog通过socket传输日志时失败，此时在event日志中会记录类似上图中tag=liblog的埋点。具体见1.1、1.2节内容。
(2) 其它进程通过socket读取logd的日志时，此时由于日志打印速度过快，读取速度跟不上写入速度，造成了部分历史日志被丢弃的情况，此时在event日志中会记录tag=chatty的埋点。此种情况遇到较少。
(3) logd buffer中日志内存超过buffer大小了，则会按照每次裁剪日志的行数等于日志总行数的10%，并且会大于等于4行，小于256行。环形buffer大小超过了，会不断循环裁剪。
(4) 文件存储问题，导致日志内容无法落盘至日志文件。具体见1.3节内容。
(5) 低内存查杀日志进程，导致日志内容无法落盘。具体见1.4节内容。

日志丢失的问题可能不止以上原因，基本分析思路是首先了解问题发生场景及时间点，然后通过日志抓取和落盘场景进行分析，参考业务日志打印频率、logd的状态（logd的cpu负载、运行状态）、系统的异常状态(严重低内存、整机CPU负载高、文件系统异常、温度过高限频限核)等综合原因，得出问题分析结论。往往日志缺失和系统状态联系较为紧密，所以分析此类问题，就要具备开阔的视野，能够及时联想到有关整机各个状态，推测和佐证自己的分析原因和得出的结论。具体分析过程，也可以参考思维导图。

下面针对以上内容，列举如下几个典型案例，仅供参考。

一、案例分析

1.1 业务日志输出频率太高

(1) events日志出现大量丢弃日志打印

(2) 查看android日志，发现sensor日志打印量非常大，基本达到刷屏的程度

(3) android日志输出频率达4229条/秒，日志输出频率非常大，sensor日志打印处于top1，达到2418条/s。

总结：sensor日志打印频率太高，超过了socket的处理能力，不能及时处理只能先行丢掉。故导致部分日志丢失。

1.2 整机负载高

(1) 输出的日志出现大量的日志丢失内容

(2) 查看日志打印频率，发现日志输出频率较低

(3) 查看systrace发现整机负载高达90%以上，logd一直处于runanble状态，整机温度也较高导致触发了限频限核。

总结：logd一直处于runnable状态，导致logd无法获得cpu时间片执行日志操作，容易出现socket通信失败，故导致部分日志丢失。

1.3 存储异常导致

(1) 查看日志发现mmap异常

(2) 由于没有过多日志打印，故本地使用adb logcat抓取日志分析

总结：文件存储出现问题，日志无法输出到对应的文件中，日志信息无法得到落盘，故出现日志内容大量丢失。

1.4 低内存导致

(1) 日志文件为空

(2) kernel日志中发现打印日志进程被杀

(3) 查看内存，已经处于低内存状态

总结：低内存导致日志进程被杀，出现日志文件无对应的日志信息落盘，故出现日志内容丢失。

二、资源消耗问题

打印日志是非常消耗资源的，原因可概括如下：

(1) 跨进程通信的消耗：日志信息通过 socket 发送给 logd，存在跨进程通信的消耗；
(2) 内存消耗：logd 中维持对应的buffer，存在相应RAM的消耗，往往低存储机器在低内存过程表现尤为突出；
(3) CPU资源消耗：logd中ring buffer会经常进行 pruneLogs操作，进行删减日志，会耗费一定的CPU资源；业务日志打印太多容易导致logd在一段时间出现cpu负载非常高的现象；
(4) IO消耗：在应用程序中，创建后台线程保存日志信息，这会导致应用或者整机卡顿。
(5) 功耗消耗：往往业务日志打印较多，导致logd的cpu负载非常高，直观表现就是发热和续航恶化。
(6) 性能消耗：日志打印过多，也容易导致界面操作卡顿，从而表现出整机性能方面的消耗。

所以，规劝大家在打印日志过程一定要注意。在正式版本中，一定要规范日志打印，要有系统资源消耗及整机性能的意识。最好建立自己模块的故障检测能力，平时做到少量日志打印，遇到故障可以适当增加日志打印。