萇程--eBPF揭開程序執行盲區——構建根因推導引擎.pdf

《萇程--eBPF揭開程序執行盲區——構建根因推導引擎.pdf》由會員分享，可在線閱讀，更多相關《萇程--eBPF揭開程序執行盲區——構建根因推導引擎.pdf（18頁珍藏版）》請在三個皮匠報告上搜索。

1、第二屆 eBPF開發者大會w w w.e b p f t r a v e l.c o m中 國 西 安Kindling-Originx全球首創的故障根因推理引擎eBPF揭開可觀測性盲區實現根因推導杭州云觀秋毫 萇程第 二 屆 e B P F 開 發 者 大 會自我介紹1、2010年浙江大學SEL實驗室助理研究員工作10年，專注在云原生和分布式計算領域2016年作為技術聯合創始人創立杭州諧云科技，專注在容器云2022年基于eBPF的Kindling開源項目創始人https:/ 年1月推出全球首創的故障根因推理引擎專家的故障排查之道現象一：XX延時升高現象二：XX報錯現象三：網絡在XX時刻出現抖動

2、現象四：日志報XXX錯經驗豐富的專家可能性一XXX可能性二XXX可能性三XXX.第 二 屆 中 國 e B P F 開 發 者 大 會W W W.e b p f t r a v e l.c o m問題的源點專家為什么要使用啟發式的排障方式圖片放置區域如果我們知道發生了什么找到根因是容易的可觀測性工具的出現幫助我們理解程序執行過程中發生了什么在可觀測性性工具的幫助之下仍然有很多盲區盲區的存在，導致人對故障根因的認識都是有限的Gartner對于盲區問題的觀點啟發式排障解決盲區Unknown-Unknown問題The ability to perform interactive exploratio

3、n and analysis of multiple telemetry types(such as traces,metrics,logs)to detect“unknown unknowns”專家利用現有工具都需要靈感啟發才能定位故障根因對于AIOPS，難以提供準確故障根因標記數據第 二 屆 e B P F 開 發 者 大 會過度依賴于專家帶來的問題技術能力的不均衡，專家過于忙碌：團隊內技能水平的差異導致高級工具和數據的利用率低下。知識傳遞的困難：缺乏有效的機制將高級用戶的經驗和知識快速傳遞給新手或非專家用戶。故障響應的時效性：在發生故障時，需要快速有效的響應，但技術水平不一致可能導致延遲

4、。培訓和提升的成本：提升團隊整體技術水平需要大量的時間和資源投入。第 二 屆 e B P F 開 發 者 大 會基于eBPF實踐TSA方法論完整還原程序執行過程開源Kindling Trace-Profiling打開盲區2、The TSA Method：https:/ 二 屆 e B P F 開 發 者 大 會基于排障北極星指標來完成盲區的覆蓋Trace sPAN BEGINTrace sPAN END第 二 屆 e B P F 開 發 者 大 會構建請求的北極星指標基線很容易識別一次請求的局部異常第 二 屆 e B P F 開 發 者 大 會局部異常的統計分析作為故障的初因判定單次請求的局部

5、異?？赡苁桥及l因素對局部異常進行統計分析可以進一步判定故障節點的局部異常是否為故障根因，準確度大幅提高出現這個特征的疑似節點大概率不是根因節點第 二 屆 e B P F 開 發 者 大 會利用算法對全局故障節點做疑似節點的篩查完成根因的定位根據各種論文模型對疑似節點進行篩查MicroRankTraceRCAGTraceTraceVAE CRISPTraceAnomalyTrace Analysis for Microservice Architecture疑似節點準確度不是最重要的，允許誤報情況局部根因統計能夠對算法結論進行進一步根因的確定，所以能允許誤報第 二 屆 e B P F 開 發 者

6、 大 會故障推理引擎Originx對eBPF能力的理解以內核可觀測性數據（程序行為建模）關聯其它可觀測性數據3、通過eBPF內核可觀測性數據對程序行為建模：穿針引線聯動各種可觀測性數據 應用可觀測性數據 網絡可觀測性數據 日志可觀測性數據 各種事件規避了構建運維數據大集中平臺的大投入第 二 屆 e B P F 開 發 者 大 會“穿針引線”可觀測性數據CPU異常代碼執行效率CPU利用率代碼執行堆棧網絡耗時發生在Client、Server、傳輸三者一側RUNQ異常CPU資源緊張NET異常疑似網絡問題CPU ThrottleCPU Steal網絡重傳和網絡延時網絡帶寬和節點的CPU利用率IOPSF

7、ile異常疑似存儲問題節點讀磁盤指標節點寫磁盤指標程序GC判斷LOREMFutex異常業務鎖鎖的代碼堆棧第 二 屆 e B P F 開 發 者 大 會4、北極星指標異常的告警 vs 傳統基于指標告警傳統基于指標告警對程序執行結果告警閥值設定困難告警與根因關系不明顯信息不足告警風暴基于北極星指標告警對程序執行過程異常告警閥值設定簡單易懂異常與根因關系非常清晰直接引導排障方向告警風暴可以規避VS第 二 屆 e B P F 開 發 者 大 會案例說明一北極星指標CPU相關異常 CPU異常代碼循環嵌套比以往多 RUNQ異常節點的CPU資源不足（不管其CPU使用率）或者容器的Limit設置不合理Node的CPU利用率60%該告警嗎？具體閥值很難合理設置（業務IO密集型和CPU密集型有關）VS第 二 屆 e B P F 開 發 者 大 會案例說明二北極星指標網絡也許沒有告警 網絡重傳并不一定會導致程序執行出現異常網絡監控發現重傳指標波動告警業務現在抖動大概率是由于重傳指標波動告警導致的VS第 二 屆 e B P F 開 發 者 大 會案例說明三北極星指標告知網絡調用偏差很大 網絡異常 Futex等待異常 結論：大概率該節點并不是根因應用監控反應出某節點執行時間偏差最大排查日志排查代碼執行情況結論這個節點為什么異常？不一定能給出結論VS第 二 屆 e B P F 開 發 者 大 會視頻效果展示