1-付求愛-服務性能分析探索與實踐.pdf

《1-付求愛-服務性能分析探索與實踐.pdf》由會員分享，可在線閱讀，更多相關《1-付求愛-服務性能分析探索與實踐.pdf（42頁珍藏版）》請在三個皮匠報告上搜索。

1、服務性能分析探索與實踐時間：2023/05/12作者：華為云 付求愛2023 深圳站付求愛多年AIOps智能運維行業經驗，擔任華為云智能化運維算法專家、PaaS技術創新La智能化運維業務負責人，負責華為云PaaS研發質量看護和智能化運維關鍵能力構建、技術研究、整體規劃、團隊管理及交付落地。華為云 智能化運維算法專家嘉賓照片2023 深圳站目錄CONTENTS背景介紹01 面臨的挑戰02 現有技術分析03 方案介紹04 有益效果05 總結06 2023 深圳站背景介紹2023 深圳站背景介紹現如今，微服務架構在部署、擴展以及自動化等方面相比傳統架構都具有明顯的優勢，越來越多的系統選擇采用微服務架

2、構。2023 深圳站背景介紹當微服務系統發生故障或性能下降時，定位問題根因是非常困難的。在微服務系統中，一個用戶請求需要眾多服務通過相互調用的方式共同實現，這些實現同一個用戶請求的調用被稱為一個調用鏈；調用鏈有時候是非常復雜的。2023 深圳站背景介紹當性能問題發生時，真正有問題的服務和與它相關的服務，都會出現指標異常以及發出告警；大量的告警讓運維人員無法確定哪個微服務及接口才是故障根因。只能逐個去排查，排除掉那些本身并沒有異常的服務。對于中大型系統而言，不同的服務是由不同的運維人員甚至不同的部門管理的，因此問題定界定位分析涉及到不同人員甚至不同部門的合作，分析成本非常高。因此，自動化的高效率

3、的性能分析服務對于快速處理基于服務的系統性能故障是非常重要的。2023 深圳站華為云真實案例根因接口特征：接口響應時長排第二調用次數相比其他接口調用次數偏大故障期間接口調用次數相比日常量變化不大現網大概50幾個接口出現同步響應時間陡增影響現網用戶100+，牽扯3個實體組織共12人，耗費1.5小時定位出問題2023 深圳站接口時延排名第一的原因為連接數據庫時間過長2023 深圳站接口時延排名第二的原因為出現慢查詢SQL(根因接口）2023 深圳站排名第三接口出現一條慢SQL和數據庫連接池時間過長2023 深圳站面臨的挑戰2023 深圳站挑戰 1服務間依賴關系復雜，難以分析性能問題在服務之間的傳遞

4、挑戰 2服務更新迭代頻率高，線上的云服務往往需要按需/按日發布版本，導致特征提取困難挑戰 3性能異?？缯{用鏈傳播，要有跨調用鏈的共因識別能力，排除假陽性面臨的挑戰2023 深圳站現有技術分析2023 深圳站 基于長尾任務的性能惡化分析主要缺點：只認為根因會發生在耗時最長的一條惡化調用鏈中，容易將真實根因排除掉；只考慮服務的耗時情況，沒有考慮異常傳播問題，導致分析不全面；僅能識別耗時相關問題，對調用鏈結構異常、參數錯誤等導致的性能問題不具備識別能力。檢測服務性能惡化遍歷惡化時間窗口內，服務被調用的N個調用鏈選耗時最長的調用鏈對這條耗時最長的調用鏈做根因分析（基于耗時主導因素）認為得到的根因是整個

5、服務的惡化根因2023 深圳站 基于單調用鏈模板匹配的性能惡化分析檢測服務性能惡化預處理：獲取惡化時間窗口內同一接口的成功調用，并聚類形成調用鏈模板處理待預測調用：對帶預測調用鏈進行基于模板的根因分析根據相似度匹配最佳模板輸出性能惡化根因與模板調用鏈進行比較，保存差異對于模板調用鏈的差異進行根因分析從歷史成功調用鏈數據中提煉正常調用鏈模板，對于每個分析對象，匹配最佳模板，再進行差異分析，最后排序推薦根因。主要缺點：僅著眼于根因在單條調用鏈上的影響因素，忽略了故障在調用鏈之間的相互影響以及調用鏈之間的差異；僅能在單條調用鏈上推薦根因，無法上升到真實場景中更常見的接口粒度根因推薦；無法識別多根因場

6、景。2023 深圳站 基于惡化傳播圖的性能惡化分析開始結束服務是否發生性能惡化？服務KPI數據通過AD算法檢測服務的KPI數據構建惡化傳播圖節點KPI是否異常存儲微服務KPI變更時間點及數據，觸發基于隨機游走的性能惡化根因分析方法YNNY主要缺點：對于一處異常而言，僅在得到的故障傳播圖上進行考慮，利用的信息不充分；該方法仍是基于傳統隨機游走的算法，基于隨機游走的方法都存在一個缺陷，即當系統中同時出現多個故障時，服務可能會受到疊加影響，而導致分析的準確性下降。2023 深圳站方案介紹2023 深圳站服務性能惡化檢測及定界方案特點1：使用基于歷史數據(7天)的機器學習方法，獨立學習待分析服務每個接

7、口在3個不同維度上的習慣性特征，相比于手工設置的閾值，自適應性更強，且無需人工打標異常檢測（AD）性能更好。特點2：使用Top-3推薦準確率作為最終的性能問題定界能力衡量標準，以縮小接口范圍作為定界目標，保證根因接口不會被漏報。2023 深圳站異常檢測(AD)算法說明stationaryseasonalNon-stationarySigmaADPeriodADDifferentiateAD平穩數據（絕大部分）周期數據（少部分）非平穩數據（少部分）從周期性、穩定性和自相關性等多維度對數據進行特征提取，并根據提取出來的特征選擇最優的檢測器。針對不同的服務場景選擇對應的算法，得到更準確的結果。202

8、3 深圳站服務性能惡化定位方案主要目標：基于單接口根因分析算法確定異常值比較高的前N個接口的根因，并利用根因自底向上的歸納和反推N個接口中的Top-3根因接口。2023 深圳站單接口惡化根因定位方法數據驅動下自動化提取調用鏈參數級正常模式，識別調用鏈異常點推薦潛在根因歷史上正常執行的n次調用鏈模塊1：離線訓練單接口的調用鏈正常模式數據預處理有向圖表示分支模板周期性更新正常模式庫調用鏈聚類識別不同分支提取序列與參數級模板模塊2：在線定位該接口問題根因對推薦根因進行評分、排序多維評價候選根因（2）對異常多調用鏈候選根因進行匯聚，得到最終根因鏈上分數計算鏈間分數計算拓撲分數計算三個規則排序考慮耗時和

9、波動剔除邏輯下游計算最終得分異常單調用鏈數據預處理分支匹配單調用鏈候選根因調用鏈模式差異對比時延差異參數差異結構差異（1）獲取單調用鏈候選根因2023 深圳站面臨的挑戰&多根因匯聚首先對單條調用鏈進行分析，獲取鏈上得分，并推薦出鏈上候選根因調用鏈根因定位的兩個棘手難題：故障可能跨調用鏈傳播，因此要有跨調用鏈的共因識別能力，排除假陽性。服務之間依賴關系復雜，不僅要考慮服務之間調用關系，還需考慮一些環境問題（如服務節點之間的資源競爭問題）盡可能綜合更多的信息，才能更好地解決根因定位問題。在真實場景中，一個根因點可以從三個不同的維度進行分析:鏈上：將異常點在所處調用鏈上進行分析，推薦候選根因鏈間：處

10、在不同調用鏈上的候選根因成為最終根因的可能性是不同的全局拓撲：考慮全局異常傳播拓撲，將候選根因進行邏輯匯聚，推薦最終根因在候選根因集合中，考慮全局拓撲、鏈間因素和鏈上因素，最終推薦接口級根因結合全局拓撲進行分析2023 深圳站三個分析維度鏈上鏈間全局拓撲2023 深圳站全局拓撲分析方法：基于狀態壓縮設計反向可達性表 注意到，在進行預處理時，首先會遍歷該接口一定時間窗口內的正常調用鏈，此時可以考慮綜合這些正常調用鏈，構建一張節點為各個服務的全局拓撲。不需要維護整張圖，只需要關注節點之間的邏輯上下游關系?？紤]對每個節點維護一張表，存儲這個節點到其他節點的反向可達性。微服務眾多，維護全局拓撲代價大，

11、能否優化？若A節點在B節點的邏輯上游且B反向可達A，則認為B處發生的異常由A處的異常傳播導致。根因在圖上兩個節點的最近公共祖先(LCA)。進一步地，對于每個節點反向可達性表的維護，可采用狀態壓縮的思想，將節點是否反向可達的信息壓縮成二進制串。用Bitmap等數據結構維護，能進一步減少時空開銷(降低到64分之1)2023 深圳站候選根因排序：綜合鏈上、鏈間、拓撲三個維度鏈上得分的確定:考慮鏈上span-event的結束時間戳，有理由認為結束時間越早的異常越可能是根因考慮異常偏離正常情況的程度，有理由認為偏離正常值越遠的異常越可能是根因考慮異常類型的不同，有理由認為不用類型的異常成為根因的可能性是

12、不一樣的鏈間得分的確定:認為耗時越大的調用鏈越需要被關注，得分越高對于鏈間耗時得分，更關注是否有離群點，對于耗時差別不大的一系列調用鏈，則耗時得分影響占比應較??；若有顯著的耗時差異，則耗時得分影響占比應較大拓撲得分的確定:認為依次分析每條異常調用鏈得到的根因是候選根因，根據全局拓撲對這些候選根因進行處理：方式一(較嚴格)：剔除存在邏輯上游的性能候選根因，最終得到的無上游候選根因即為最終推薦根因方式二(較寬松)：對每個服務節點，根據全局拓撲計算處于其邏輯下游的候選根因個數，將這個數量記為該節點的傳播分數，傳播分數越大，越認為該服務節點為根因節點最終根據對以上三類得分的評價情況，綜合上述考慮進行合

13、成，最終得到最終根因得分公式：2023 深圳站基于反饋數據的排序學習模型改善推薦根因準確性排序學習：排序學習是一個有監督的機器學習過程，對每一個給定的查詢文檔對，抽取特征，通過日志挖掘或者人工標注的方法獲得真實數據標注。然后通過排序模型（LambdaMart），使得輸入能夠和實際的數據相似。排序場景文檔檢索性能惡化根因定位查詢用戶輸入語句待分析服務信息信息文檔集合調用鏈偏離正常模式差異點排序結果文檔排序性能惡化根因排序標簽獲取人工標注/日志挖掘/點擊率/停留時間人工反饋（打分/正負判斷/點擊率/順序）待分析服務信息調用鏈偏離正常模式差異點差異點包含服務類型、事件關系、各類參數、時間、關鍵詞、原

14、始文本等及它們發生的順序專家規則/利用失敗表象-差異相似性排序/排序學習模型差異點排序根因推薦主動/被動式收集反饋數據驅動的排序學習模型推薦根因類比性能惡化根因定位場景2023 深圳站有益效果2023 深圳站有益效果本方案可自動化比較異常點，并給出接口粒度的根因，如服務增減、事件關系增減、參數異變、耗時過長等本方案不/弱依賴人工經驗：服務的調用鏈正常模式提取是數據驅動，不需要或只需要少量業務知識本方案無需人工標注數據，且能推薦未知根因本方案能匯聚多條調用鏈數據進行綜合分析，結合全局拓撲情況給出有效推薦本方案綜合鏈上因素、鏈間因素和拓撲因素進行綜合分析，考慮因素全面，能對多根因問題和調用鏈異常相

15、互影響問題作出較好識別在華為業務場景中，采用本方案效果有較大提升2023 深圳站效率提升5040855050100分析準確率單次分析耗時分析效率提升改進前改進后效率提升：1、服務性能惡化根因分析準確率由50%提升至85%2、服務單次分析平均耗時由40分鐘降低至5分鐘，提升分析效率87.5%2023 深圳站真實案例2023 深圳站真實案例2023 深圳站總結2023 深圳站總結本方案提出了一種先在異常調用鏈內部分析候選根因，再在全局拓撲環境下對候選根因進行匯聚的二級分析方法，主要步驟如下：正常調用鏈模板庫的建立全局拓撲(節點反向可達性表)的建立調用鏈上的異常檢測和候選根因分析結合全局拓撲，多維打

16、分，對候選根因進行匯聚并推薦最終根因對于全局拓撲的構建，本方案創新性地提出了利用節點反向可達性表來維護的思想，進一步提出了結合狀態壓縮的二進制存儲思路，提升了算法的時空效率。對于最終根因的推薦，本方案提出計算三項得分的多維評價方法，綜合考慮真實環境中的各種可能因素，更好地推薦根因。感謝聆聽CSDN全球最大的中文開發者社區平臺CSDN全球最大的中文開發者社區平臺CSDN創立于1999年全球編程類網站排名第7（來源：Similarweb 2023.04）注冊用戶超過4300萬，覆蓋90%的中文開發者新媒體矩陣粉絲數量超過3100萬超過1000家企業客戶和合作伙伴目前公司員工近800名，分布在北京、長沙、上海、深圳、杭州、成都等城市，并在美國硅谷常設辦事處旗下品牌旗下品牌專業中文IT技術社區：CSDN.NET多媒體專業出版：新程序員開發者專屬移動APP:CSDN APP代碼托管協作平臺：GitCode代碼工具協同平臺：InsCodeIT人力資源服務：科銳?？怂关俗W絡高校IT技術學習成長平臺：高校俱樂部