支撐系統中全景監控技術研究實現范文

本站小編為你精心準備了支撐系統中全景監控技術研究實現參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

摘要:本文詳細分析了移動應用支撐系統監控技術面臨的各類問題，并提出了一種覆蓋用戶體驗、后臺系統、底層硬件等各個層面的全景監控技術，實現了移動應用后臺支撐系統的統一監控與分析，并通過變點檢測等方法及時發現監控數據的陰跌或暗漲等趨勢變化。

關鍵詞:支撐系統；全景監控；全鏈路技術；變點檢測

隨著移動互聯網的快速發展，各類熱門移動應用的后臺支撐系統也隨著前端應用的業務發展變得更加強大與復雜，而監控系統在后臺支撐中扮演的角色也越來越重要。如何迅速監控到從用戶體驗、支撐系統乃至底層硬件的波動或者故障，并迅速定位問題，是移動應用后臺監控系統面臨的主要問題。

1存在的問題

通過對業界移動應用后臺支撐系統的監控系統進行整理與分析，發現主要存在以下幾類問題。

1.1用戶側體驗缺乏監控

用戶在使用移動應用中一旦遇到應用閃退、白屏、卡頓、頁面加載不完整、頁面之間切換慢等問題會發生抱怨、投訴、甚至流失等情況，用戶的使用體驗和應用的口碑都會受到較大影響。大部分移動應用的后臺監控系統主要關注業務和系統等層面，用戶體驗的問題主要通過事前測試或者事后客戶投訴來發現，缺乏能在用戶使用過程中就及時發現批量出現用戶體驗問題的方案。

1.2故障定位效率需提升

許多移動應用的后臺支撐系統經過一段時間的迭代建設后，功能層面不斷完善，但是架構也越來越復雜，給監控系統的故障定位效率提出了新的挑戰。比如各系統模塊是通過不同項目分期設計和上線，往往都有獨立的監控工具（如數據庫有獨立的監控工具，緩存模塊有獨立的監控工具），但監控的視野較窄且相互無關聯，缺乏一致性的監控視角，經常出現各獨立監控系統均有預警，系統運維人員卻無法判斷是否是同一故障引起，排障效率較低。

1.3對趨勢的預測能力弱

傳統的監控預警算法中，預警的閾值主要直接取自監控數據本身，但是對于陰跌和暗漲等數據緩慢變化，存在無法及時把控數據變化趨勢，存在誤報和漏報的可能。

2移動應用支撐系統的全景監控技術

基于業界移動應用后臺支撐系統的監控技術存在缺乏對用戶體驗的監控、排障效率低、趨勢預測能力弱等問題，本文提出了針對移動應用支撐系統的全景監控技術。

2.1全景監控架構

全景監控在客戶端應用層面增加了關于用戶體驗的監控，比如用戶在應用中批量出現的客戶端崩潰、白屏、頁面切換慢等問題的監控，另外也實現了對應用級系統和底層硬件層面的監控，做到監控點全面分布，監控口徑一致。從客戶端到應用級系統（緩存、中間件等）再到底層硬件，信息全面采集，集中收集清洗，實時處理分析，各個層面通過數據流串聯起來，統一監控與分析，如圖1所示。

2.1.1數據采集層以監控目標為維度進行劃分，對以下各部分數據進行全面采集。（1）用戶體驗數據：利用自研的客戶端和H5插碼技術，對客戶端的APP崩潰、ANR或白屏、H5頁面加載慢或者出錯等批量影響用戶體驗的異常情況進行采集。客戶端和H5插碼是通過在移動應用中集成用戶體驗采集SDK來實現的，同時在對應的服務端架設Nginx+Lua環境的采集數據接收端，按照約定的格式及間隔時間，采集帶時間戳的客戶體驗數據。具體采集流程如圖2所示。本文中提及的用戶體驗采集SDK的邏輯架構如圖3所示。整體上分為3層。最上層是接口層，提供APP調用的方法以及環境和配置參數等。第2層是業務層，包含了客戶端各頁面測速、卡頓檢測和參數采集等所有的核心邏輯。第3層是數據層，將業務層產生的數據封裝為統一的數據結構，并保存到本地文件或者數據庫中。（2）應用系統數據：利用自研的Collectframework技術和業界熱門的Metricbeat技術，實現對支撐系統中Nginx、緩存、服務中間件和服務接口等各組件的運行狀態數據進行采集。因為應用系統層面，各個廠商不同類型的組件較多，所以本文使用Collectframework技術，通過制定統一的采集標準和數據格式，對來自應用系統中Apache、HAProxy、MongoDB、MySQL、Nginx、Redis等不同技術和不同模塊的數據進行統一采集。（3）底層硬件數據：利用業界熱門的Metricbeat技術，對支撐系統的底層服務器硬件、CPU、內存、磁盤、文件系統、網絡等各項進行采集。Metricbea將采集到的底層硬件數據定時傳輸到Redis緩存，經Logstash初步處理后進行存儲。

2.1.2數據清洗層負責匯總所有監控的初始數據，對這些數據進行清洗，過濾掉有問題或者不完整的數據，并將其進行統一的結構轉換和標記，提取必要的信息，從而便于分析及存儲。原始的監控日志由于各種原因會存在日志格式不完整、信息丟失等現象，所以需要將無效的數據進行規整刪除，對部分數據進行適當的轉換，比如日期的時區轉換等，才能確保監控分析的準確。本文中的數據清洗層主要使用的工具是Logstash，具體清洗過程如下。（1）Logstash從緩存隊列中獲取監控日志數據。（2）Logstash通過其Filter插件對監控數據進行清洗和轉換。（3）將清洗和轉換后的監控數據進行存儲至Elasticsearch集群或者Opentsdb中供數據分析層使用。

2.1.3數據分析層負責對清洗過的數據進行關聯性分析，迅速發現監控目標的異常情況，并及時預警。數據分析層主要由監控分析模塊與展現預警模塊組成。（1）監控分析模塊主要用于針對清洗后存儲到Elasticsearch集群或者Opentsdb中的監控日志進行深度挖掘，分析系統的運行狀況及各種性能問題。（2）展現預警模塊一方面以圖表的方式將監控目標的各種性能及狀態指標集中呈現給運維人員，另一方面根據預警設置對各種監控到的異常情況進行預警和通知。

2.2全鏈路監控技術

全鏈路監控技術是以調用請求傳遞鏈路為入手點，將從用戶體驗到底層硬件的各個監控層面串聯起來，關聯監控并分析。此技術故障處理效率高，一旦發生故障，迅速定位故障點。在移動應用的支撐系統中，用戶在客戶端的請求一般要經過用戶端請求→防火墻→負載均衡→反向→應用端→各能力服務→緩存→數據庫→應用中間件（應用容器）→主機服務這樣的一個長調用鏈路，各個環節的監控數據口徑不統一，關聯性不強，就算監控出數據異常，也很難迅速定位出具體的故障點。本文通過對分布式鏈路追蹤技術的深入研究，實現了從用戶體驗到應用性能到主機和中間件的全鏈路監控。全鏈路監控系統的鏈路追蹤技術遵從了谷歌Dapper鏈路的協議規范，其核心是基于Span的協議，依賴Span構建出服務調用的屬性結構關系，從而通過樹形結構的樹形節點和葉子節點能夠展示出分布式服務系統間的調用關系。整個調用過程的追蹤流程如下。（1）系統一旦收到用戶端請求，就生成一個全局TraceID，通過TraceID可以串聯起整個調用鏈，一個TraceID代表一次請求。（2）除了TraceID外，還需要SpanID用于記錄調用父子關系。每個服務會記錄下ParentSpanID和SpanID，通過他們可以組織一次完整調用鏈的父子關系。（3）一個沒有ParentSpanID的Span成為rootSpan，可以看成調用鏈入口。（4）所有這些ID可用全局唯一的64bit整數表示。（5）整個調用過程中每個請求都要透傳TraceID和SpanID。（6）每個服務將該次請求附帶的TraceID和附帶的SpanID作為ParentSpanID記錄下，并且將自己生成的SpanID也記錄下。（7）要查看某次完整的調用則只要根據TraceID查出所有調用記錄，然后通過ParentSpanID和SpanID組織起整個調用父子關系。全鏈路監控技術在監控平臺中具體實現的界面如圖4所示，通過此技術，運維人員可監控整條系統鏈路的運行情況以及各系統模塊之間的調用關系，能夠迅速定位出問題的故障模塊和故障點并且迅速接入排障處理。

2.3變點檢測算法

傳統的監控預警算法對監控數據的微量波動、持續陰跌或者暗漲等問題常常不能及時發現，從而發生故障漏報。針對此問題，全景監控中引入了mean-shift等均值漂移模型與機器學習算法相結合來尋找監控數據的變點。所謂變點，就是持續微量下跌到一定時間，累積變化量到一定程度后，使得變點前后監測指標在一段時間內的均值發生漂移。從圖5可以看到，均值漂移模型把傳統監測預警算法不容易識別的陰跌趨勢，轉換成CUSUM時間序列并根據歷史數據采用機器學習算法自動顯示出變化趨勢，在變點左側單調增、右側單調減，變點兩側單調變化。

參考文獻

[1]劉嘉裕.基于分布式微服務全鏈路實時監控系統設計與實現[D].北京：北京交通大學，2018.

[2]李拂曉.幾類時間序列模型變點監測與檢驗[D].西安：西北工業大學，2015.

[3]劉一田,劉士進,郭偉.柔性微服務監控框架[J].計算機系統應用,2017(10).

[4]蘇衛星,朱云龍,劉芳.時間序列異常點及突變點的檢測算法[J].計算機研究與發展,2014,51(4):781-788.

作者：李映 單位：中國移動通信集團江蘇有限公司