金 安

（上海愛奇藝新媒體科技有限公司，上海 200050）

0 引言

隨著云計算、大數(shù)據(jù)、虛擬化、容器化等新技術(shù)出現(xiàn)和移動互聯(lián)網(wǎng)的普及，移動端應(yīng)用系統(tǒng)架構(gòu)越來越龐大，業(yè)務(wù)形態(tài)越來越多，給傳統(tǒng)的監(jiān)控分析帶來全新挑戰(zhàn)［1］，如何在應(yīng)用出現(xiàn)問題時快速定位系統(tǒng)故障迫在眉睫。一些互聯(lián)網(wǎng)企業(yè)的移動端應(yīng)用系統(tǒng)呈現(xiàn)形式為超級APP，通常服務(wù)于海量用戶，不同地域、時段、請求的用戶體驗完全不同，單純依靠人工發(fā)現(xiàn)和排查問題顯然行不通。

如何尋找移動業(yè)務(wù)的性能瓶頸，定位應(yīng)用系統(tǒng)故障，優(yōu)化和提升用戶體驗是急需解決的問題，應(yīng)用性能管理（Application Performance Management，簡稱APM）系統(tǒng)應(yīng)運而生［1］。文獻［2］基于J2EE 架構(gòu)從Application 探針、管理服務(wù)器和管理控制臺3 個部件設(shè)計并實現(xiàn)了APM 系統(tǒng)；對于提高APM 海量數(shù)據(jù)存儲與訪問需求的可靠性與讀寫效率，文獻［3］、文獻［4］詳細介紹了分布式協(xié)調(diào)服務(wù)ZooKeeper、查詢引擎Elasticsearch、Storm 與Kafka 等數(shù)據(jù)處理技術(shù)框架；文獻［5］分析了中小型企業(yè)異構(gòu)業(yè)務(wù)系統(tǒng)復雜現(xiàn)狀，從設(shè)計原則、功能架構(gòu)、技術(shù)架構(gòu)等角色詳細闡述面向中小型企業(yè)業(yè)務(wù)系統(tǒng)的APM 框架。 然而對于大型互聯(lián)網(wǎng)系統(tǒng)，必須考慮海量數(shù)據(jù)處理算法與大數(shù)據(jù)存儲聚合存儲策略的優(yōu)化；文獻［6］提出一種基于Canopy&K-means 聚類算法的分析算法，用于挖掘應(yīng)用的典型性能瓶頸參數(shù)；文獻［7］對于海量數(shù)據(jù)分析處理提出了基于可變網(wǎng)格劃分的密度偏差抽樣算法。以上算法都為本文數(shù)據(jù)處理算法優(yōu)化提供了較好的參考。

本文以某互聯(lián)網(wǎng)公司為例，針對該企業(yè)遇到的應(yīng)用性能管理難題，解決快速定位故障，驅(qū)動產(chǎn)品迭代，縮短產(chǎn)品開發(fā)周期，設(shè)計并實現(xiàn)一套基于大數(shù)據(jù)平臺的移動端APM系統(tǒng)。

1 應(yīng)用性能管理

應(yīng)用性能管理（APM）指對企業(yè)數(shù)字化的關(guān)鍵業(yè)務(wù)應(yīng)用進行監(jiān)測、優(yōu)化，提高應(yīng)用的可靠性和質(zhì)量，保證用戶得到良好服務(wù)，降低IT 總擁有成本［8］。

在互聯(lián)網(wǎng)應(yīng)用的交付鏈中，越靠近機房或商業(yè)云的區(qū)域，比如SLB、Web 服務(wù)、應(yīng)用服務(wù)器、DB、消息隊列、分布式存儲等，由于有專業(yè)人員的QoS 保證，相對來說比較可控；靠近終端的用戶區(qū)域，涉及到國內(nèi)各大運營商的網(wǎng)絡(luò)鏈路和第三方服務(wù)（CDN、消息推送、互聯(lián)支付、跨國訪問等），且用戶移動設(shè)備多種多樣，特別是國內(nèi)安卓端設(shè)備各大廠家定制化嚴重，很容易發(fā)生因為設(shè)備的不兼容出現(xiàn)性能和用戶體驗問題。

移動互聯(lián)網(wǎng)應(yīng)用場景中經(jīng)常會碰到如網(wǎng)絡(luò)基站擁塞、各地運營商域名劫持、CDN 節(jié)點故障、骨干網(wǎng)線路維護、云端服務(wù)的宕機和瀏覽器或移動設(shè)備不兼容等問題，這些問題都是APM 系統(tǒng)應(yīng)該關(guān)注和解決的。

APM 技術(shù)分類可根據(jù)數(shù)據(jù)采集位置區(qū)分，基本上分為針對最終用戶側(cè)和應(yīng)用服務(wù)側(cè)兩大類技術(shù)。通常說的端到端APM，實質(zhì)上是這兩端APM 技術(shù)的融合。企業(yè)在選擇APM 產(chǎn)品時，除了滿足功能及需求的匹配度，還需考慮APM 所采用的數(shù)據(jù)采集方式。表1 為APM 數(shù)據(jù)采集方式優(yōu)缺點對比。

Table 1 Comparison of advantages and disadvantages of APM’s data collection methods表1 APM 數(shù)據(jù)采集方式優(yōu)缺點對比

越來越復雜的應(yīng)用架構(gòu)和業(yè)務(wù)場景需要結(jié)合使用不同的APM 技術(shù)，只有更加關(guān)注于運維數(shù)據(jù)采集，對端到端的性能數(shù)據(jù)進行相關(guān)性分析，才能快速準確地定位業(yè)務(wù)故障，支持精細化運營。

2 系統(tǒng)框架設(shè)計與實現(xiàn)

2.1 某企業(yè)移動端應(yīng)用系統(tǒng)問題

某互聯(lián)網(wǎng)企業(yè)隨著APP 系統(tǒng)的不斷壯大，原來使用的類APM 系統(tǒng)越來越不能滿足業(yè)務(wù)需求。由于投遞數(shù)據(jù)的缺失，業(yè)務(wù)多次在性能下降和服務(wù)異常時未能快速預測和定位問題點，導致流失了一定的用戶量。

2.2 移動端應(yīng)用數(shù)據(jù)監(jiān)測與采集

APM 中兩個最重要的維度是最終的用戶體驗和業(yè)務(wù)指標，需要采集海量數(shù)據(jù)并根據(jù)算法優(yōu)化進行聚合分類，快速發(fā)現(xiàn)、定位和修復問題［9］。

本文APM 系統(tǒng)采集以下數(shù)據(jù)：

（1）崩潰數(shù)據(jù)。該數(shù)據(jù)晦澀難懂但十分重要，需要特殊翻譯，包含堆棧、日志、用戶行為路徑、異常、寄存器、設(shè)備信息等數(shù)據(jù)。

（2）卡頓監(jiān)控數(shù)據(jù)。包含ANR、UI 卡頓棧、日志等數(shù)據(jù)。

（3）頁面性能數(shù)據(jù)。包含APP 啟動時間、頁面打開時間、埋點Trace 時間分析等數(shù)據(jù)。

（4）網(wǎng)絡(luò)監(jiān)控數(shù)據(jù)。該數(shù)據(jù)最復雜也是問題最多的，包含Http 請求性能、DNS、WebView 請求、連接超時、CDN 等數(shù)據(jù)。

（5）熱更數(shù)據(jù)。包含熱更耗時、成功率、到達率等數(shù)據(jù)。

（6）業(yè)務(wù)異常數(shù)據(jù)。包含異常棧、業(yè)務(wù)模塊、接口耗時、附加數(shù)據(jù)等。

2.3 系統(tǒng)框架設(shè)計

APM 系統(tǒng)設(shè)計根據(jù)覆蓋范圍分為數(shù)字化體驗監(jiān)控、終端程序發(fā)現(xiàn)跟蹤和深度應(yīng)用分析診斷3 個層次分階段實現(xiàn)。數(shù)字化體驗監(jiān)控主要體現(xiàn)在數(shù)據(jù)采集、監(jiān)控和可視化；終端程序發(fā)現(xiàn)跟蹤偏向程序的跟蹤檢查和問題定位等；深度應(yīng)用分析診斷模式依托大數(shù)據(jù)分析和機器學習、AI 技術(shù)，可以更加智能地預測、發(fā)現(xiàn)問題，在減少人為干預的情況下自動修復故障。

根據(jù)業(yè)務(wù)需求設(shè)計一個移動端APM 實時監(jiān)控系統(tǒng)，在收集到APP 端海量數(shù)據(jù)后進行歸類聚合，實時分析并基于相關(guān)閾值異常發(fā)出警告，給出離線分析報告。系統(tǒng)框架設(shè)計如圖1 所示。

（1）各種終端設(shè)備嵌入APM SDK，通過接口將業(yè)務(wù)所需要的信息投遞到Nginx 和Tracker 系統(tǒng)，其中Nginx 接收短數(shù)據(jù)信息，Tracker 系統(tǒng)保存長數(shù)據(jù)信息。

（2）通過Flume 將數(shù)據(jù)匯聚整理，投遞數(shù)據(jù)根據(jù)業(yè)務(wù)需求進入實時和非實時Kafka 消息隊列中。

（3）實時消息隊列信息可通過FileBeat 組件將數(shù)據(jù)清洗后入庫到ES 集群中，提供給Kibana 或者Grafana 展示。

（4）清洗設(shè)備Spark Streaming 把解析后的信息包存入HBase，并使用時間戳+序號作為HBase 的key，Spark 定時周期性觸發(fā)Hadoop MR 任務(wù)。任務(wù)被觸發(fā)后，通過時間段信息獲知key 范圍，然后對HBase 中該范圍的數(shù)據(jù)做scan 還原，對數(shù)據(jù)做統(tǒng)計計算，比如某時間段的崩潰率、崩潰機型分布、卡頓類型等。

（5）Hadoop MR 把統(tǒng)計結(jié)算結(jié)果寫入MySQL 等數(shù)據(jù)庫，計算結(jié)果包括各APP 版本的啟動次數(shù)、崩潰次數(shù)、崩潰機型分布、崩潰OS 版本分布等，該結(jié)果提供給Portal 頁面展示。

（6）符號解析系統(tǒng)啟動對Hbase 中的“Crash 信息”做二次處理，將處理結(jié)果寫入HBase、ES 和MySQL 中。具體步驟為：iOS 崩潰的符號還原，類型聚合；安卓/iOS 崩潰的模塊和類定位，通過Git/配置文件定位崩潰并將問題自動投遞到Jira 系統(tǒng)郵件，或者短信告知相關(guān)研發(fā)Owner。

Fig.1 APM system architecture圖1 APM 系統(tǒng)框架

（7）用戶可以通過瀏覽器查看數(shù)據(jù)和各類圖表，展示端從各種數(shù)據(jù)源獲取數(shù)據(jù)返回給查詢端。

3 APM 系統(tǒng)實現(xiàn)關(guān)鍵技術(shù)

3.1 APM 系統(tǒng)數(shù)據(jù)存儲聚合策略

案例企業(yè)用戶多，采集的數(shù)據(jù)龐大，為達到更好的時效和經(jīng)濟性，從數(shù)據(jù)存儲和數(shù)據(jù)計算兩方面進行優(yōu)化。

Hbase 主要用來保存完整用戶崩潰日志、崩潰前的用戶操作細節(jié)、ANR/卡頓等詳情。由于APP 版本較多，每個崩潰和ANR/卡頓類型最多每天保存1 000 條，詳細數(shù)據(jù)按照國家要求保存6 個月。當Hadoop MR 任務(wù)根據(jù)原始數(shù)據(jù)計算統(tǒng)計寫入MySQL 和Redis 等數(shù)據(jù)庫后，為節(jié)約存儲空間，根據(jù)業(yè)務(wù)特點清除HBase 中不再需要的對應(yīng)的明細數(shù)據(jù)。

ES 集群采集實時的Kafka 消息，通過Kibana 實時展現(xiàn)各種趨勢圖，包含APP 名稱、APP 版本號、APP Patch 版本號、時間范圍、異常類型等。MySQL 數(shù)據(jù)庫保存了HBase 中詳細信息key 的索引關(guān)系，另外符號解析系統(tǒng)和Hadoop MR 任務(wù)也會更新MySQL 中的崩潰統(tǒng)計數(shù)據(jù)信息。

3.2 APM 系統(tǒng)大數(shù)據(jù)聚類算法優(yōu)化說明

考慮到PB 級數(shù)據(jù)采集和未來系統(tǒng)的數(shù)據(jù)擴展，為加快數(shù)據(jù)分析，有必要對APM 系統(tǒng)中大數(shù)據(jù)聚類算法進行優(yōu)化。

相對于固定網(wǎng)格劃分的密度偏差抽樣（Density Biased Samping，DBS）算法，可變網(wǎng)格劃分指首先分析原始數(shù)據(jù)集的屬性特征及分布特征，然后劃分與數(shù)據(jù)集特征保持一致的網(wǎng)格空間。對原始數(shù)據(jù)集的每一維動態(tài)地劃分區(qū)間，使每一維上的區(qū)間大小不等，不同維的區(qū)間段個數(shù)也不一樣，最終得到大小不等的區(qū)間構(gòu)成網(wǎng)格空間［10-11］。該算法在保持原始數(shù)據(jù)分布特征的基礎(chǔ)上能有效減少網(wǎng)格數(shù)，比固定網(wǎng)格劃分技術(shù)更為靈活。

3.2.1 可變網(wǎng)格劃分方法

構(gòu)建可變網(wǎng)格時對原始的每一維數(shù)據(jù)集（N 個數(shù)據(jù)點、d 維數(shù)據(jù)集A）用快速排序法按小到大排序后再進行等深劃分，然后對密度相似的相鄰區(qū)間段進行合并操作，數(shù)據(jù)集每一維重復此操作最終實現(xiàn)可變網(wǎng)格的劃分［12］，公式如

下：

排序后i維數(shù)據(jù)集：

計算各相鄰區(qū)間段的密度相似性：

計算每維數(shù)據(jù)閾值：

對Dai等深劃分為k個區(qū)間段，每個區(qū)間段數(shù)據(jù)個數(shù)為N/k，區(qū)間密度為該區(qū)間上下確界的差，Iik代表第i維上第k區(qū)間段的密度，α可取經(jīng)驗值1 2。

若密度相似性εi大于閾值Vi，表示這兩個相鄰區(qū)間段密度相似，全部比較完成后合并密度相似的相鄰區(qū)間段，然后重復式（2）和式（3），完成可變網(wǎng)格劃分［13］。

3.2.2 改進型可變網(wǎng)格劃分DBS 核心算法

傳統(tǒng)可變網(wǎng)格劃分需要對每維數(shù)據(jù)先進行排序，這必然增加網(wǎng)格劃分的時間。為節(jié)約時間，對該網(wǎng)格的劃分方法進行標準方差維度改進如下：

為某一維度所有數(shù)據(jù)的平均值。

公式（5）中，σi為某一維度所有數(shù)據(jù)的標準方差：

劃分網(wǎng)格時不必通過對數(shù)據(jù)集每一維進行排序，只需對每一維度標準方差信息動態(tài)確認該維劃分粒度即可，理論上縮短了網(wǎng)格矩陣構(gòu)建時間。將矩陣看成空間，計算各維相鄰區(qū)間密度相似性與整維密度閾值，得出劃分后的網(wǎng)格單元數(shù)和各網(wǎng)格的數(shù)據(jù)數(shù)。

根據(jù)DBS 算法定義和條件，推定在每個聚合里每個數(shù)據(jù)點被抽取的概率函數(shù)如下：

式中，ni為第i個聚合大小，實際上e可取經(jīng)驗值為1 2。

樣本數(shù)量n等于Di抽取樣本數(shù)量的總和，得出以下公式：

結(jié)合式（6）和式（7）得出各個聚合數(shù)據(jù)點的抽樣概率函數(shù)為：

由式（8）得出每個聚合抽樣的個體函數(shù)為：

3.3 APM 符號解析系統(tǒng)

用戶體驗監(jiān)控是APM 系統(tǒng)必須要解決的首要問題，其中APP 崩潰數(shù)據(jù)解析又是重中之重。本文中的符號解析系統(tǒng)基本上由以下需求或功能構(gòu)成：收集包括Objective-C、Swift、C/C++在內(nèi)的crash 和dump crash 的調(diào)用堆棧信息，分析發(fā)生在crash 之前的用戶操作細節(jié)以更快定位故障原因。本文設(shè)計的APM 符號解析系統(tǒng)如圖2 所示。

Fig.2 APM symbolic paring system圖2 APM 符號解析系統(tǒng)

APM 符號解析步驟如下：①通過APM 后臺上傳需要的dSYM、mapping、linkmap 和SDK 類名等數(shù)據(jù)文件，經(jīng)過預處理后存入映射表數(shù)據(jù)庫加速符號化；②通過APM 系統(tǒng)定時調(diào)用符號解析系統(tǒng)對崩潰文件進行解析并進行地址符號轉(zhuǎn)換；③拿到轉(zhuǎn)化后可讀的崩潰信息后，按照定義的格式寫入ES 和其他數(shù)據(jù)持久化集群提供Portal 查詢；④根據(jù)后臺上傳的SDK 類名列表，解析出崩潰來自哪一類App SDK；⑤把解析的結(jié)果輸出到相關(guān)數(shù)據(jù)庫中，等待被生產(chǎn)系統(tǒng)獲取。

通過嵌套的聚合查詢，可預先聚合統(tǒng)計指定多個維度的數(shù)據(jù)，使離線數(shù)據(jù)聚合優(yōu)化。由于ES 集群數(shù)據(jù)量巨大，要對每個查詢請求啟動cache 緩存優(yōu)化策略，將ES 的索引刷新率降到5min 以提高cache 命中率，減少cache 頻繁刷新。

4 系統(tǒng)上線數(shù)據(jù)結(jié)果分析

本文的APM 系統(tǒng)于2020 年上線，與市面上常見的skywalking、zipkin 等APM 組 件 采 用Jmeter 工 具 進 行 并 發(fā) 百 萬用戶的壓力測試比較，發(fā)現(xiàn)自研的APM 系統(tǒng)投遞對系統(tǒng)吞吐量影響最小，僅為無投遞時的10%左右，而skywalking、zipkin 達到25%以上。內(nèi)部服務(wù)CPU 和內(nèi)存的影響差不多在10%以內(nèi)，前兩者在15%左右［14］。

為了加快符號化過程，將上傳預處理過的符號數(shù)據(jù)傳到hbase 數(shù)據(jù)庫，通過地址直接scan 還原，一次還原時間小于5ms；通過cache 加速技術(shù)，使命中率達到96%以上。大部分情況下還原一條信息耗時小于1ms，說明在進行抽樣過程中，基于標準方差的網(wǎng)格劃分方法和DBS 算法并結(jié)合緩存技術(shù)，在適當降低樣本準確率的情況下能顯著提高大數(shù)據(jù)的抽樣速度，減少構(gòu)建網(wǎng)格空間的時間，從而提高算法性能，加快數(shù)據(jù)分析過程。極限情況下，1ms 內(nèi)能處理并匹配29 652 條崩潰消息，并以實時郵件或其他觸達方式反饋到責任人。

該系統(tǒng)上線后，極大縮短了人員定位與排障時間，平均定位bug 時間從30min 降低到5min 左右，應(yīng)用的崩潰率從0.345%下降到0.134%左右，接近行業(yè)頂尖公司千分之一的崩潰率。

5 結(jié)語

本研究在生產(chǎn)環(huán)境中基本實現(xiàn)了APM 系統(tǒng)設(shè)計的數(shù)字化體驗監(jiān)控和終端程序發(fā)現(xiàn)跟蹤功能。系統(tǒng)能進行指定崩潰問題分析、實時崩潰問題趨勢分析、iOS/Android 性能檢測、問題協(xié)同報告和崩潰率自動告警等，較好地解決了先前無法解決的痛點，提高了定位線上故障的效率。

后續(xù)應(yīng)重點在優(yōu)化算法、引入機器人學習和AI 技術(shù)方面深入研究。