馮富秋-阿里基于內核剖析的故障分析和智能運維實踐.pdf

《馮富秋-阿里基于內核剖析的故障分析和智能運維實踐.pdf》由會員分享，可在線閱讀，更多相關《馮富秋-阿里基于內核剖析的故障分析和智能運維實踐.pdf（35頁珍藏版）》請在三個皮匠報告上搜索。

1、阿里基于內核剖析的故障分析和智能運維實現馮富秋 資深技術專家目前致力于阿里超大規模數據中心的穩定性和可靠性建設，新硬件與軟件的協同設計等基礎技術領域的研發與工程化落地。主要研究領域包括：SOC芯片的前端構建、仿真，電信級Linux內核研發，百萬級系統智能運維，以及行業應用的全生棧軟硬件技術及其融合應用。曾參與中國嵌入式系統學科體系建設，國家電網智能電網國家標準的制定。運維的趨勢運維的現狀和挑戰更好的運維體驗龍蜥運維SIG（興趣組）運維的趨勢FaaS、Serverless只關注自身的應用實現，開發更為專注。對整體運維環境無感知，無法應對任何的基礎設施運維工作，對運維工作無所適從。容器化部署/Pa

2、aS只關注業務容器，但可感知系統相關指標。開發人員連帶運維支持,對系統的了解低，運維難度大。傳統機房以及IaaS方式用戶感知操作系統以下組件，對全棧軟件的理解度高。存在基礎設施的運維人員，運維的成本高云原生倒逼智能化“零”運維New Future on Cloud運維的現狀和挑戰目前的運維產品現狀配置部署管理系統監控社區工具New Future on Cloud系統配置、批量程序部署、批量運行命令等提供系統的基本指標監控以及基于基線的告警大量專業的社區工具Ansible/AWXGrafana/zabbixperf/ftrace配置部署管理系統監控社區工具目前的運維的挑戰New Future o

3、n Cloud基于操作系統現有的數據接口、日記進行采集基于基線的告警存在大量的誤報需要專業級別系統運維人員通過大量工具的組合應用。開環的執行過程無法對部署的系統進行穩定性評估不知其然只知其然而不知其所以然難知所以然AI計算任務TensorFlow框架Linux操作系統大量中間件的使用，讓問題離根因越來越遠New Future on Cloud微服務框架RPC框架GlibCPython計算存儲網絡傳統IaaS提供商的視角傳統運維平臺的視角客戶的應用視角進程A讀寫文件大量Page Cache形成內核的復雜性導致問題解決難度居高不下New Future on Cloud系統空閑內存急劇減少進程B申請

4、內存并訪問內存回收可能引發的內存不足告警可能引發的內存訪問時延更糟的是，我們沒有辦法知道，究竟在哪個時刻會引發問題。進程B的內存問題，很難讓運維人員關聯到進程A的寫文件操作糟糕的是，不僅僅是案例所闡述的內存問題，在操作系統內部網絡、IO、內存、調度皆大量存在類似問題。內存案例更好的運維體驗應用自頂向下的分析實現診斷功能與客戶應用表象的關聯，任何的運維建議都是客戶可直接理解和操作的?；趦群松疃绕饰鲋悄芤惑w化運維流程監控與深度問題診斷聯動，知其然又知所以然；集群化的大數據、AI分析，實現智能基線、智能告警、智能問題分析。降低應用的運維門檻深度剖析問題成因智能化告警、監控診斷聯動更好的運維體驗Ne

5、w Future on Cloud發揮內核的全視角優勢，深度分析進程間行為關聯深度剖析內核自身，以直觀、可讀的形式剖析內核行為SysOM（System Operation&Maintenance）是由龍蜥社區系統運維 SIG 打造的一站式操作系統運維平臺，致力于解決業內工具碎片化，門檻高的挑戰。深入內核的運維SysOM運維中的內存難題無法掌握內存分布無法從系統中直接獲取當前內存的分布和內存健康狀況用戶無法快速確定耗內存的應用或者容器無法快速找出內存使用Top進程或者容器無法快速診斷分析內存問題無法快速找到內存問題及其根因，分析需要大量數據和已知經驗SysOM 2.0 內存診斷功能和實踐場景OO

6、M診斷Cache分析內存大盤查詢整個系統的內存健康，快速查看內核用戶態的內存占比，進程使用分析主要使用場景：1、快速檢查當前內存的健康程度2、快速發現內存消耗最大板塊給出系統OOM時的內存狀態和不同OOM的原因和建議，主要使用場景：1.系統或者cgroup下進程被殺掉，檢測是否發生OOM2.查詢OOM原因，并做出優化改進，預防下次發生給出多個維度cache分析主要使用場景：1、分析主機或者容器Cache占比多時的占比情況SysOM 2.0 內存診斷-內存大盤SysOM 2.0 內存診斷-OOM診斷SysOM 2.0 內存診斷-Cache分析常見調度問題調度LOAD負載高調度抖動應用抖動原因各種

7、各樣，除應用自身邏輯處理有缺陷外，很多時候更多是和應用運行所處的系統環境有關系。執行過程偶爾耗時增加吞吐突然降低響應規律性或頻繁性變慢系統負載高是由哪些進程引起？負載高是否對系統其他部分指標也造成了影響？功能定位：診斷系統負載高是由哪些進程引起，及負載高是否對系統其他部分指標也造成了影響系統負載高診斷sys影響診斷hardirq影響診斷softirq影響診斷IO影響診斷進程負載貢獻度R進程貢獻度D進程貢獻度呈現進程調用棧，用于分析D住的原因系統調度火焰圖1.診斷系統負載高是否對系統的sys利用率、harirq/softirq和io造成了影響2.診斷系統進程對負載的貢獻度，并抓取D狀態進程的當前

8、調用棧3.呈現當前系統調度火焰圖，可查詢造成負載高的熱點函數SysOM 2.0 調度負載診斷介紹SysOM 2.0調度負載診斷介紹SysOM 2.0 調度負載診斷介紹SysOM 2.0 調度抖動診斷介紹sys態不調度系統關中斷runq延遲了解各個cpu就緒隊列延遲追蹤延遲發生上下文的前一個task定位內核中長時間不調度corner追蹤內核長時間corner的堆棧定位內核中長關中斷corner追蹤內核長關中斷堆棧事件總覽調度問題發生的頻次調度問題詳細信息SysOM2.0 調度抖動診斷介紹SysOM 2.0 存儲診斷簡介IO延遲分析IO HANG診斷IO流量分析追溯IO流量沖高來源進程、文件、磁盤

9、細粒度分析系統內IO流量分布IO延遲分布可視化進程級IO耗時問題分析檢測系統中的IO HANG問題定界IO HANG問題進程級IO流量統計、IO行為、操作哪個文件、被哪個磁盤消費read.write.mmapblock_getrq/issuekprobekprobekprobekprobe進程信息文件信息磁盤信息進程信息磁盤信息流量信息Block-based File systemBlock layer聚合分析內核態用戶態ioioio通過在文件系統、塊層追蹤IO，獲取更細粒度的IO流量分布信息，支持追溯IO來源通過信息聚合分析，支持追溯buffer io實際來源SysOM 2.0 IO流量分析

10、診斷IO Burst問題SysOM 2.0 IO流量分析介紹Disk Device Driverqueue mappingbufferdonekickBlock layerMake requestqueuequeue rqApp/filesystem/Diskcompletebp1bp5bp2interruptdp4dp3dp:driver pointbp:block pointio routing通過對IO鏈路追蹤，獲取IO各鏈路延遲分布通過展開IO更多細節信息，分析進程IO的延遲性能瓶頸IO鏈路時延追蹤SysOM 2.0 IO延遲分析診斷IO延遲性能問題SysOM 2.0 IO延遲分析介紹

11、DiskVirtio-blkDiskdriverBlocklayerdonekickio timestampqueue rqio complete statuscompleteIO未下發問題中斷處理問題IO回收問題buf通過提取vring特征，界定磁盤HANG或OS HANGOS HANG情況下，能細化到具體的軟件流程OS HANG原因分析界定磁盤HANGSysOM 2.0 IO HANG診斷分析IO HANG問題SysOM 2.0 IO HANG診斷介紹龍蜥運維SIG（興趣組）龍蜥大講堂 系統運維SIGhttps:/ 小龍 微信號：openanolis_assis備注：請求加入“龍蜥社區系統運維SIG”群釘釘微信網址：https:/ 系統運維SIGThanks開放運維聯盟高效運維社區DevOps 時代榮譽出品