下面針對一些典型場景缺通用日志（android/kernel）的問題，一一列舉如下，希望可以讓大家關注到缺日志的真實原因。如下問題也提醒各位工程師：謹慎添加日志，不要隨意添加，否則即容易造成自己的日志缺失也會導致其他業務模塊丟失日志。

通用日志丟失目前有如下情況會出現：

（1）liblog通過socket傳輸日志時失敗，此時在event日志中會記錄類似上圖中tag=liblog的埋點。具體見4.1、4.2節內容。

（2）其它進程通過socket讀取logd的日志時，此時由于日志打印速度過快，讀取速度跟不上寫入速度，造成了部分歷史日志被丟棄的情況，此時在event日志中會記錄tag=chatty的埋點。此種情況遇到較少。

（3） logd buffer中日志內存超過buffer大小了，則會按照每次裁剪日志的行數等于日志總行數的10%，并且會大于等于4行，小于256行。環形buffer大小超過了，會不斷循環裁剪。

（4） 文件存儲問題，導致日志內容無法落盤至日志文件。具體見4.3節內容。

（5） 低內存查殺日志進程，導致日志內容無法落盤。具體見4.4節內容。

日志丟失的問題可能不止以上原因，基本分析思路是首先了解問題發生場景及時間點，然后通過日志抓取和落盤場景進行分析，參考業務日志打印頻率、logd的狀態（logd的cpu負載、運行狀態）、系統的異常狀態（嚴重低內存、整機CPU負載高、文件系統異常、溫度過高限頻限核）等綜合原因，得出問題分析結論。往往日志缺失和系統狀態聯系較為緊密，所以分析此類問題，就要具備開闊的視野，能夠及時聯想到有關整機各個狀態，推測和佐證自己的分析原因和得出的結論。具體分析過程，也可以參考思維導圖。

下面針對以上內容，列舉如下幾個典型案例，僅供大家參考。

4.1 業務日志輸出頻率太高

（1） events日志出現大量丟棄日志打印

（2） 查看android日志，發現sensor日志打印量非常大，基本達到刷屏的程度

（3） android日志輸出頻率達4229條/秒，日志輸出頻率非常大，sensor日志打印處于top1，達到2418條/s。

總結：sensor日志打印頻率太高，超過了socket的處理能力，不能及時處理只能先行丟掉。故導致部分日志丟失。

4.2 整機負載高

（1） 輸出的日志出現大量的日志丟失內容

（2） 查看日志打印頻率，發現日志輸出頻率較低

（3） 查看systrace發現整機負載高達90%以上，logd一直處于runanble狀態，整機溫度也較高導致觸發了限頻限核。

總結：logd一直處于runnable狀態，導致logd無法獲得cpu時間片執行日志操作，容易出現socket通信失敗，故導致部分日志丟失。

4.3 存儲異常導致

（1） 查看日志發現mmap異常

（2） 由于沒有過多日志打印，故本地使用adb logcat抓取日志分析

總結：文件存儲出現問題，日志無法輸出到對應的文件中，日志信息無法得到落盤，故出現日志內容大量丟失。

4.4 低內存導致

（1） 日志文件為空

（2） kernel日志中發現打印日志進程被殺

（3） 查看內存，已經處于低內存狀態

總結：低內存導致日志進程被殺，出現日志文件無對應的日志信息落盤，故出現日志內容丟失。