APM 監控系統：APM小結

8、 APM 小結

一般來講各個端的監控能力是不太一致的，技術實現細節也不統一。因此在技術方案評審的時候須要將監控能力對齊統一。每一個能力在各個端的數據字段必須對齊（字段個數、名稱、數據類型和精度），由於 APM 自己是一個閉環，監控了以後需符號化解析、數據整理，進行產品化開發、最後須要監控大盤展現等android
一些 crash 或者 ANR 等根據等級須要郵件、短信、企業內容通訊工具告知干係人，以後快速發佈版本、hot fix 等。git
監控的各個能力須要作成可配置，靈活開啓關閉。github
監控數據須要作內存到文件的寫入處理，須要注意策略。監控數據須要存儲數據庫，數據庫大小、設計規則等。存入數據庫後如何上報，上報機制等會在另外一篇文章講：打造一個通用、可配置的數據上報 SDKobjective-c

儘可能在技術評審後，將各端的技術實現寫進文檔中，同步給相關人員。好比 ANR 的實現數據庫

/*
android 端

根據設備分級，通常超過 300ms 視爲一次卡頓
hook 系統 loop，在消息處理先後插樁，用以計算每條消息的時長
開啓另外線程 dump 堆棧，處理結束後關閉
*/
new ExceptionProcessor().init(this, new Runnable() {
            @Override
            public void run() {
                //監測卡頓
                try {
                    ProxyPrinter proxyPrinter = new ProxyPrinter(PerformanceMonitor.this);
                    Looper.getMainLooper().setMessageLogging(proxyPrinter);
                    mWeakPrinter = new WeakReference<ProxyPrinter>(proxyPrinter);
                } catch (FileNotFoundException e) {
                }
            }
        })
        
/*
iOS 端

子線程經過 ping 主線程來確認主線程當前是否卡頓。
卡頓閾值設置爲 300ms，超過閾值時認爲卡頓。
卡頓時獲取主線程的堆棧，並存儲上傳。
*/ 
- (void) main() {
    while (self.cancle == NO) {
        self.isMainThreadBlocked = YES;
        dispatch_async(dispatch_get_main_queue(), ^{
            self.isMainThreadBlocked = YES;
            [self.semaphore singal];
        });
        [Thread sleep:300];
        if (self.isMainThreadBlocked) {
            [self handleMainThreadBlock];
        }
        [self.semaphore wait];
    }
}
複製代碼

整個 APM 的架構圖以下markdown

說明：session
- 埋點 SDK，經過 sessionId 來關聯日誌數據
APM 技術方案自己是隨着技術手段、分析需求不斷調整升級的。上圖的幾個結構示意圖是早期幾個版本的，目前使用的是在此基礎上進行了升級和結構調整，提幾個關鍵詞：Hermes、Flink SQL、InfluxDB。架構

文章內容過長，拆分爲多個篇章，請自行點擊查看，若是想總體連貫查看，請訪問這裏async