京東科技全鏈路故障診斷智慧運維實踐
一、京東科技智慧運維整體能力
我們在2018年就開始建設了智慧運維,針對京東科技內部,我們運維面臨的問題主要是三點:
難度逐步增加
體系化要求越來越高
成本要全面節省
我們在建設智慧運維的基本目標與業界是一致的,主要都是為了降低故障的平均修復時間,延長系統的無故障的執行的時間,以此提升系統的可用性以及運維效率。在京東內部,主要依託於三大技術底座:運維知識圖譜、運維大資料處理技術、運維演算法技術。
為賦能三大技術底座,我們主要做了兩件事情:
一是透過運維演算法技術,賦能我們的業務運維的監控,做到故障的快速發現和快速定位;
二是運維演算法賦能智慧排程,提升資源的利用率。以及在去年開始,我們在硬體故故障預測上也投入了研發,並實現了場景落地。
下圖是我們智慧運維的一個技術架構圖,主要包含資料採集計算層、資料儲存層、資料服務層、資料應用層。
此外,我們也會在每年618雙十一大促前,會對我們的業務應用進行應用健康度的體檢,並對核心應用也會進行整改,整體能力依託於我們運維知識圖譜的建設。
上圖我們整個京東科技智慧運維產品的一個全景圖,主要包含資料層(腦)、學件層(心)、業務層(眼)。
二、運維演算法賦能業務可觀測性落地經驗
1、指標異常檢測
指標異常檢測主要是為實現集中管理監控指標,並透過運維演算法技術自動化地對線上的時序監控指標進行異常診斷。
在日誌分析上,我們能夠對線上服務元件這類日誌進行實時聚類分析,包括透過日誌實時語義匹配轉成指標等監控手段,從日誌、指標層面的不足。
在故障定位上,主要分為兩種,一是基於apm呼叫鏈的關聯分析掃描全域性的故障根因,二是將NLP日誌模板提取技術,與運維圖譜關係進行融合,集中對整體的故障根因進行掃描分析。
異常檢測最開始引入了統計學習落地試點,後面則引入了時序聚類、時序網路等異常檢測演算法,相比於固定閾值,能否自適應去適配不同場景下的監控資料。除了異常檢測外,我們還做了一套自迴歸動態基線的預測演算法能力沉澱。在京東內部,主要落地了兩個場景:
一是學習歷史資料7-14天的指標波動規律性,對指標的未來趨勢及動態波動區間做預測,當跌破動態區間時,就會實時發出這類告警;
二是做事前的判斷,比如記憶體使用率開始從20%增加到30%-40%時,不會引起運維同學的關注,但可能突然間10-15分鐘會達到80%,這時候可能就會反應不歸來,因此,我們會去提前發下這類資料的增長趨勢,在故障真正發生的時候,爭取故障處理的響應時間。
另外,在異常檢測以及動態基線預測模型上,我們在內部多個資料集上的準確率評估有90%以上,目前這套模型也有被IEEE的國際論文所收錄。
2、智慧文字分析
京東科技有一款自研產品能夠支援包括基礎元件、容器、中介軟體、資料庫等多型別的日誌接入,日誌接入之後,能夠支援分散式日誌檢索並進入智慧分析層。因此,故障發生的時候,運維同學除了接收智慧告警之外,還能透過平臺快速查詢,去看實時的日誌。
在日誌接入智慧分析層後,會對運維日誌進行模板的提取和預聚類,能及時發現一些線上未知的業務問題。此外,如果出現監控指標沒有采集上來、配置的監控告警並不準確、告警沒有及時發出等問題,我們也可以透過日誌分析的手段,結合圖譜關係定位到真正的根因。
智慧文字分析主要引入了NLP的技術,對全量運維日誌進行聚類分析,訓練生成日誌模板,運維、研發同學會在平臺標註關心的問題,再生成模板庫,線上實時匹配已知問題。也就是說,我們會將原始的運維日誌,按照預定義好的類別進行語義匹配,並轉成時序的監控指標,當一類問題日誌突增時,我們也會及時發出告警。
我們在實踐中也發現,不管是哪一種運維場景,對日誌裡面的動詞、形容詞、名詞都是較關心的,所以為了提升整個日誌分析模型的準確度,我們引入了詞性分析技術,做了一部分特徵增強。模型部分我們也是用Bert預訓練模型,並對Bert模型進行微調。
和業界deep log、logclass等比較火的模型相比,我們這套模型的效果都是較優的,目前這套模型有被IEEE論文所收錄。
大家在做運維日誌NLP分析的時候,可能會面臨一個問題:到底要標註對少日誌,才算完成了模型學習?
針對這個問題,我們採用的是半監督的方式。比如運維、研發同學會定期收到告警通知,裡面會詳細記錄新日誌產生量、佔比量及告知標註需要,他們就會進入智慧運維平臺,對所關心的問題進行定義,標註出來的部分則訓練出基於詞性標註的命名實體抽取模型,將其他相似文字中比較關係的實體抽取出來,再輔以運維、研發同學進行日誌問題標註。
下面對京東科技內部的智慧文字分析案例-k8s場景進行介紹:
我們透過k8s核心元件日誌的實時聚類以及實時語義匹配,發現一些在指標層面發生不了的問題,比如日誌佔用檔案控制程式碼沒釋放、孤兒pod問題等。
上面是去年雙十一大促備戰前的案例,應用程式去呼叫叢集時,我們發現它在往某一個叢集快取的節點頻繁列印日誌。自動觸發診斷告警後,PE同學緊急排查,發現這個節點關聯到的是大促比較核心的一個應用,聯絡應用研發同學後發現,確實是線上程式開啟了除錯模式,導致應用呼叫叢集時,頻繁往這個節點列印日誌,除錯模式關閉後,也規避了在大促中可能出現的計算瓶頸問題。
在京東內部落地時,除了有按場景的服務元件日誌,還有快取、大資料、MySQL、網路裝置的日誌。另外,近兩年做的比較多的k8s的node日誌分析,實現了快速發現線上未知故障,發現了之前透過監控發現不了的那些問題。
另外,運維日誌分析落地到了不同場景,包括日誌聚類、模板訓練提取、語義分析和日誌分類等,我們也做了部分的模型蒸餾,這部分的實踐目前IEEE論文收錄了5項。
另外,我們也做了應用告警日誌的MySQL、Redis根因分析。
3、健康度巡檢
接下來是健康度巡檢,其主要方式是結合運維專家排障制定巡檢的規則及異常檢測的能力,主動對線上核心的應用進行巡檢,去發現一些潛在問題,並分析資料健康度等,並且在大促重保之前,我們會對這些亞健康的應用進行核心整改。
另外,透過這套自動化巡檢能力,我們也能夠提升快取的命中率,提升閒置伺服器資源的使用率,經過歷年運維場景的經驗積累,我們目前有100+的應用業務巡檢規則。
4、全鏈路監控體系
接下來全鏈路故障定位落地實踐,其中包括移動端、前端、服務端等監控。
服務一旦發生瓶頸,可以綜合分析呼叫鏈、介面耗時、返回狀態碼、異常日誌,網路日誌等,快速診斷問題。
同時,我們還能透過這套全鏈路監控的追蹤能力,去看每一塊節點的耗時佔比情況。
另外,我們自動化生成了呼叫鏈拓撲關係,直觀展示服務之間的依賴強弱,實時監控每一個應用的服務質量(TPS、耗時、成功率、可用率)。
再者,將整個全鏈路的監控資料,統一地收集起來輸入到智慧運維監控中心,再做全域性的根因定位。
在京東內部,主機問題定位及排查、操作變更、網路/資料庫等場景,都覆蓋了這套全鏈路監控,大促等重保期間都會投入使用,出現問題故障時,運維、研發用都較依賴於這套全鏈路監控體系。
上圖關於日誌模板根因定位的一個案例,在2022年618大促期間,我們從快取服務端的元件層面發現一類日誌模板大量突增,是一個AOF盤阻塞問題,恰好該問題直接關聯到業務營銷應用,關聯到的客戶端連線數超過最大連線數限制,造成刷盤阻塞的報警,關聯到的業務成功率也有下跌,當時業務監控告警沒有提前發出,所以重保團隊非常關注,最後我們透過這套能力及時發現了這類問題。
5、多維指標根因定位
除此之外,我們做了多維指標明細的根因定位,主要是定位web場景的異常,當某個域名的TP耗時/TPS發生異常產生告警後,可按省份、運營商、機房、機櫃、主機等各維度的TP耗時/錯誤狀態碼TPS突增等指標進行明細下鑽分析,透過強化學習搜尋演算法從數萬維度交叉組合資料中快速定位出異常的維度組合。
三、運維演算法賦能降本增效落地經驗
1、智慧排程
我們會將master、node等監控資料統一輸入到智慧排程器,對應用資源使用情況及未來使用情況進行預測,將線上、離線應用進行合理的混合部署排程,以此提升資源利用率。
京東雲在支援京東全線業務正常執行下,超大規模叢集的CPU資源利用率提升3倍,單位訂單資源成本下降30%,記憶體平均使用率提升57%,目前這套模型也有被IEEE論文所收錄。
2、硬體故障預測
2022年開始,我們把運維演算法落地到了硬體故障預測場景,和業界實踐同樣面臨著標籤不充分的問題。
因此,我們引入了半監督學習的方式,去擴充硬碟的故障資料;另我們基於時間視窗計算增強smart特徵,輸入給時間注意力分析模型,讓模型得以充分訓練,提升硬碟故障預測準確性。
在支撐京東全線業務正常執行下,硬碟故障預測模型平均準確率達90%以上,平均召回率達80%左右,在業界處在靠前的水平。
3、運維演算法
從2018年開始,我們開始沉澱智慧運維演算法能力,比如動態基線預測、運維日誌預訓練模型、蒙特卡洛樹根因定位、相似度計算、告警共性分析演算法、因果推斷演算法等。
以告警共性分析演算法為例,在內部落地比較核心的就是pingmesh場景(網路場景)。在源和目的IP相互ping的時候,會有大量的延時以及丟包的指標監控,當延時和丟包大量突增時,中間經過的網路裝置共性的路徑是什麼?這個時候,我們就是透過告警共性分析演算法去分析解決的。
4、模型工廠
模型工廠主要用以整個智慧運維演算法學件的資料集快速增量學習,幫助運維演算法迭代更新及再訓練,這其中包含前面介紹的8大元件。
5、運維監控視覺化大屏
除了以上功能,我們整個智慧運維平臺也支援視覺化。
做可觀測性實踐,一部分要做到快速定位,還要做到分散式的全鏈路追蹤,快速發現並響應,還有一部分是視覺化,實現全域性資料概覽。
來自 “ dbaplus社群 ”, 原文作者:京東;原文連結:http://server.it168.com/a2023/0508/6802/000006802815.shtml,如有侵權,請聯絡管理員刪除。
相關文章
- Oracle故障診斷Oracle
- Oracle DBA實戰攻略:運維管理、診斷優化、高可用與最佳實踐——序Oracle運維優化
- 資料庫簡化運維,智慧診斷助手幫你搞定!資料庫運維
- Oracle DBA實戰攻略:運維管理、診斷最佳化、高可用與最佳實踐——序Oracle運維
- 網路故障診斷應該實現的三個目的
- 光纖故障診斷和故障排查
- Istio的運維-診斷工具(istio 系列五)運維
- 京東雲開發者|提高IT運維效率,深度解讀京東雲AIOps落地實踐運維AI
- ASM磁碟故障診斷(二)ASM
- ASM磁碟故障診斷(一)ASM
- 故障診斷學習工具
- RAC故障診斷指令碼指令碼
- 透過運維編排實現自動化智慧運維與故障自愈運維
- 網路自查 用Pathping命令診斷網路故障(轉)
- 故障分析 | Kubernetes 故障診斷流程
- 全鏈路壓測自動化實踐
- EMR重磅釋出智慧運維診斷系統(EMR Doctor)——開源大資料平臺運維利器運維大資料
- 資料庫智慧運維探索與實踐資料庫運維
- 直播分享| 騰訊雲 MongoDB 智慧診斷及效能優化實踐MongoDB優化
- 企業內部區域網網路故障診斷
- 9 Oracle Data Guard 故障診斷Oracle
- DB2故障診斷工具DB2
- 從百度運維實踐談“基於機器學習的智慧運維”運維機器學習
- 聽音識故障,人工智慧“診斷”機器新形式人工智慧
- 阿里智慧運維實踐|阿里巴巴DevOps實踐指南阿里運維dev
- 大型DCI網路智慧運營實踐
- 深度學習故障診斷——深度殘差收縮網路深度學習
- 全鏈路追蹤!微服務運維人員終於解放了微服務運維
- mysql複製故障診斷與排除MySql
- 部落格連結—Oracle故障診斷Oracle
- 技術沙龍|京東雲DevOps自動化運維技術實踐dev運維
- 沙龍報名 | 京東雲DevOps——自動化運維技術實踐dev運維
- 案例實踐|Apache Pulsar 在移動雲智慧運維平臺的實踐Apache運維
- 最佳實踐:Kubernetes 叢集中 DNS 故障的可觀測性與根因診斷DNS
- websphere中介軟體故障診斷troubleshootingWeb
- 利用 Java dump 進行 JVM 故障診斷JavaJVM
- 京東資料庫智慧運維平臺建設之路資料庫運維
- 分散式全鏈路灰度釋出的探索與實踐分散式