背景

隨着雲上規模持續擴張，AI 訓練數據、實時日誌、多媒體內容等數據類型呈指數級增長，推動雲存儲成為主流選擇，同時也帶來了 IO 請求量的急劇上升。在多租户雲環境中，多個用户共享底層存儲資源，高併發訪問容易引發 IO 資源爭搶，造成性能瓶頸。此外，混合雲和多雲架構的廣泛應用，使得數據在不同雲平台間頻繁流動，而各異的存儲策略和監控體系進一步增加了 IO 問題的排查與定位難度。為了進一步提升問題的解決效率，阿里雲操作系統控制枱聚焦高頻的 IO 異常場景，構建了從問題發現，根因診斷到解決方案的 IO 一鍵診斷能力。

業務痛點解析

痛點1：問題類型只是能力缺失

用户普遍缺乏對 IO 異常類型的識別能力（如區分 IO 延遲高還是打滿問題），導致無法自主調用針對性診斷工具，必須依賴運維人員介入定位，導致診斷流程效率低下，增加了人力成本。一鍵診斷能夠聚焦於 IO 延遲高、IO 流量異常、iowait 高等幾類出現頻次高的問題，捕捉 IO 子系統相關的異常，幫助用户快速自動地識別問題類型。

痛點2：問題現場丟失與取證困難

目前傳統監控普遍集成了 OS 的 IO 相關指標，如 await、util、tps、bps 等，同時會依賴指標的突變作為告警依據，但是當指標異常時可能已錯過問題發生的窗口期，沒法再去針對性地抓取更多幫助信息，獲取關鍵診斷證據（如細粒度的必要輔助信息）。所以快速識別問題並採取相應的措施，是把握住最佳診斷時機的關鍵。

痛點3：監控指標割裂與診斷關聯弱

現有監控指標體系存在"數據孤島"現象，各指標獨立存在，並且與具體 IO 問題類型缺乏直觀的映射關係。例如在 util 指標（硬盤設備的繁忙比率）偏高的時候，往往需關聯觀察 await 等多個指標，同時結合磁盤 iops、bps 的理論上限來綜合判斷問題。即使識別出了問題類型，也需要對相應診斷工具有使用方法相關的先驗知識，考慮如何根據監控指標的數值來設置診斷參數，而 IO 一鍵診斷旨在能夠屏蔽了這些複雜的關聯流程，直抵分析報告。

解決方案

架構介紹

「阿里雲操作系統控制枱」提供的 SysOM 管控組件已具備應對 IO 延遲高，IO 流量異常，iowait 高等幾類問題的診斷能力，但是客户往往不會允許在機器上常態化執行診斷工具去不停地抓取信息。因此，IO 一鍵診斷設計為在診斷時段內，週期性讀取 IO 監控指標數據來檢測異常，定界問題，到最後觸發子診斷工具輸出報告的模式，實現“發現問題->診斷問題->根因分析”的自閉環。

由於不同的業務場景，關注的指標閾值會不一樣，如果統一一個靜態閾值覆蓋各種場景，很可能引起異常的誤報或者漏報，因此 IO 一鍵診斷通過動態閾值來識別異常，總體架構圖設計如下圖所示：

IO 指標監控：從系統獲取 IO 的關鍵指標，例如 await、util、tps、iops、qu-size、iowait。

異常識別：當採集到的 IO 指標大於動態閾值時，判定為異常，因此異常識別的核心在於動態閾值的計算，具體算法將在下文解釋。

異常診斷：根據不同的指標異常，觸發對應的診斷工具，並且會對觸發頻率做了一定的限制。

數據清洗&可視化：根據診斷結果呈現出可視化的輸出，給出根因和解決建議。

實現原理

指標採集

觸發一鍵診斷後，每間隔cycle毫秒（數值可配置）會讀取並計算iowait、iops、bps、qusize、await、util等指標的值，並檢查是否有異常。

動態閾值計算
為了能夠識別秒級的 IO 異常行為，需要將系統中採集到的各個孤立的 IO 指標聚合起來，形成對 IO Burst 等問題的監控能力，這個過程的核心在於動態閾值的計算，動態閾值經過三步計算得到：基礎閾值計算，補償閾值計算以及最小閾值計算。

基礎閾值計算
IO 指標其實是一種時間序列，而且一般地，在一個時間區間內，可以認為絕大部分時間是沒有異常的，因此序列形成的曲線趨勢是趨於平穩的，當出現異常的時候，會產生一個明顯偏離平穩趨勢的尖峯，因此第一步要做的就是通過本節計算得到的基礎閾值把 IO 指標中的尖峯毛刺篩選出來。

我們通過動態窗口持續觀察數據，計算窗口內數據的最大偏離平均值作為“瞬時波動值”。然後，將所有“瞬時波動值”的平均值作為“基礎閾值”。這個閾值會持續自適應地更新，以反映數據最新的波動特徵。

補償閾值計算基礎閾值曲線（如下圖中的黃色曲線）反映的是真實 IO 指標數據的波動情況，但是 IO 指標在平穩狀態下往往是限於一個範圍內波動，所以需要計算一個補償閾值，疊加到基礎閾值上會減緩基礎閾值的快速下降，而從而減少帶來誤報的情況。

當基礎閾值持續下降一段時間後，可以認為系統進入“常態穩定”模式。此時，我們會過濾掉明顯的噪音數據，並在剩餘的“安靜”數據中，計算一個“常穩態補償值”來衡量這種穩定狀態下的微小波動。在“常穩態補償值”正式計算出來之前，我們會臨時用當前窗口最大的基礎閾值作為補償值，並且在每個新窗口開始時都重置。一旦基礎閾值停止下降或反彈，該機制將重置，迴歸更宏觀的觀察模式。

最小閾值
最小靜態閾值是一個預先設定好的最低門檻，。最終的異常判定閾值為 “最小靜態閾值” 和 “動態調整閾值（基礎閾值 + 補償值）” 兩者中的最大值，確保只有同時超過業務容忍底線和系統動態波動範圍的數據才被視為異常。

特別地，如果數據已超出“最小靜態閾值”，則“動態調整閾值”的計算會簡化，不再考慮“常態補償值”，直接使用“基礎閾值”作為判斷依據，以聚焦更明顯的異常情況。

異常識別
當採集到的 IO 指標大於動態閾值時判定為異常。不同異常類型雖有各自的判斷算法，但都遵循以下原則：

• 確定警戒線： 設定一個“指標警戒線”，取 “最小靜態閾值”（業務容忍的最低門檻）與“動態閾值”（系統根據歷史數據計算的正常波動範圍）中的最大值。
• 觸發診斷： 若當前指標值超過此“警戒線”，且監測和診斷條件滿足，則立即啓動診斷。
• 動態學習： 系統會持續根據最新的指標數據，更新並調整“動態閾值”，使其始終反映指標的正常波動範圍。

智能診斷

當系統監測到 IO 異常時，一鍵診斷工具能夠自動調用診斷功能，及時抓取和分析關鍵信息，快速定位問題。為避免診斷過於頻繁，我們通過以下參數進行頻率控制：

• “診斷冷靜期”（triggerInterval）： 設定兩次診斷之間的最短間隔，確保系統不會在短時間內重複診斷。
• “異常堆積計數器”（reportInterval）： 控制診斷髮起的條件。若為0，則異常發生且過了冷靜期即可診斷；若不為0，則需在冷靜期過後，且在規定時間內積累了足夠數量的異常事件，才觸發診斷。

根因分析
在診斷工具抓取了信息之後，面對各種信息，從何處着手，也令人困擾，因此瞄準方向，進行專業的分析、剝絲抽繭地從中篩查跟問題相關的線索顯得非常重要；IO 一鍵診斷則具備這個抽絲剝繭的分析能力，並且能夠彙報跟問題相關的結論性信息：

• 對於 IO Burst 異常，經過分析後，在監控的日誌欄中彙報異常期間貢獻IO最多的進程，其中極具特色的是，對於寫 buffer io 後由 kworker 刷髒的情況，也能分析出來是哪個進程在寫 buffer io。
• 對於 IO 高延遲異常，經過分析後，在監控的日誌欄中彙報異常期間 IO 的延遲分佈，輸出 IO 延遲最大的路徑。
• 對於 iowait 高異常，經過分析後，在監控的日誌欄中彙報觸發 iowait 高的進程、以及觸發原因。

案例分析

iowait 高

對於 iowait 高異常場景，IO 一鍵診斷可以直接定位到等待磁盤 IO 的進程來源以及等待時長，分析阻塞的原因。以下案例即是診斷出業務場景 IO 壓力過大，髒頁過多過多，導致業務進程 task_server 等待 IO 時長過長的問題。對此場景，報告中也提出謹慎地調整 dirty_ratio和dirty_bytes 參數，來減少刷髒壓力，從而緩解 IO 壓力的建議。

IO 延遲高

用户通過監控發現機器上 IO 寫流量出現了延遲比較高的現象，我們建議他嘗試通過 IO 一鍵診斷來判斷根因。

在用户執行的結果中，診斷識別到了是 DiskBlockWrite 進程產生的 IO 壓力，主要延遲集中在磁盤刷髒，幫助用户查到了延遲根因。對此，我們在結果中建議用户嘗試減少 buffer IO 的寫入或者調整機器上的配置的 dirty_ratio 和 dirty_background_ratio 參數數值，來緩解 IO 延遲高的問題。

聯繫我們

您在使用操作系統控制枱的過程中，有任何疑問和建議，可以搜索羣號：94405014449 加入釘釘羣反饋，歡迎大家掃碼加入交流。

阿里雲操作系統控制枱PC端鏈接：https://alinux.console.aliyun.com/