在雲計算環境中，Kubernetes（K8s）集羣與容器化部署已成為行業標準化實踐，但同時也對運維體系及可觀測性提出了顯著挑戰：一方面，主流監控工具（如 Node Exporter、cAdvisor 和 Datadog）雖能提供系統級與容器級的基礎指標，卻難以覆蓋操作系統深層次問題（如調度延遲、內存回收延遲、TCP 重傳率等），而引入增強型指標又面臨操作系統知識門檻高、分析複雜度大的難題；另一方面，傳統監控體系在告警觸發或問題發生時往往缺乏完整的上下文數據，導致根因定位困難，需依賴問題多次復現才能排查。此外，指標與問題之間的關聯複雜——單一指標變化可能由多個問題引發，同一問題也可能影響多個指標，而集羣、節點、Pod 的分層架構雖為資源管理提供了邏輯劃分，但業務問題與節點的承載關係常因維度割裂未能有效關聯，進一步加劇了運維複雜性。

為應對以上挑戰，阿里雲操作系統控制枱（簡稱“操作系統控制枱或 OS 控制枱”）依託於大量操作系統問題案例沉澱及知識總結，結合 AIOps 等相關技術，提出了從智能異常檢測到智能根因分析，再到智能修復建議的全鏈路一站式運維解決方案。從中提煉出如系統 OOM、系統內存黑洞、調度延時、負載（load）高、IO Burst、網絡延時、丟包等典型的操作系統問題場景，沉澱出對應的端到端的解決方案。如圖 1 所示，通過全鏈路閉環流程高效管理與解決上述業務挑戰。

針對問題場景，提取相關指標，結合領域專家經驗設定的閾值規則以及智能化異常檢測算法，構建多維度的異常發現機制，從而實現對潛在問題的精準識別與實時檢測。

對於實時檢測到的異常事件，為了分析異常響應及根因，需進一步採取以下措施：

• 現場信息採集與根因診斷：通過自動化工具對異常發生時的運行環境進行全面的信息採集，從而進一步定位問題的根本原因，並生成針對性的解決方案或修復建議。
• 告警通知與分發：將異常事件及其診斷結果通過多渠道（如郵件、短信、即時通訊工具等）推送至相關運維團隊或責任人，確保問題能夠被及時響應與處理。
• 健康評分動態更新：基於異常事件的影響範圍與嚴重程度，實時更新集羣、節點及 Pod 的健康評分，為資源調度、容量規劃及故障預測提供量化依據，同時支持全局視角下的系統狀態評估與決策優化。

（圖 1: 操作系統控制枱系統概述閉環鏈路）

下面我們具體介紹上述鏈路中較為關鍵的異常檢測、信息採集與根因診斷和集羣、節點、Pod 健康度計算
這三個功能。

異常檢測

多種多樣的操作系統相關的監控指標，在不同場景中，這些指標呈現的規律也不盡相同，如何能有效，準確地識別出監控指標中的異常也是一種挑戰。

為了儘可能地適應不同場景的指標異常發現，操作系統控制枱採用一種通用的監控指標處理算法和多模型集成的通用異常檢測算法，該算法如圖 2 所示：

• 多種不同類型的監控指標輸入後先進行分類，如整體平穩的、呈一定變化趨勢的、和無規則波動
• 分類的指標由無監督的多模型結合的異常檢測算法進行檢測，結合專家閾值和多種模型聯合判決有效提高了檢測準確率，同時根據系統指標的特徵進行優化，在處理監控指標之前進行預處理，進一步提升效率。

（圖 2: 通用異常檢測模塊）
下面通過一些典型的指標類型，來舉例簡單説明異常檢測的預期效果：

• 平穩性高水位指標：對於 CPU 利用率，內存利用率等指標可能持續處於一個非常高的水位，雖然對系統健康有一定影響，但是是預期內的，檢測水位閾值和其平穩性，最終會識別為一個潛在的異常。

（圖 3: 平穩性高水位指標）

• 毛刺、波動型指標：對於毛刺，波動型指標，我們結合專家閾值和抖動檢測算法，根據指標的波動大小，以及其離我們設置的最小，對大閾值的具體，綜合評估出當前指標的異常程度。

（圖 4: 波動型指標）

信息採集與根因診斷

為了避免現場丟失導致後續問題定位困難。在捕獲異常的同時，操作系統控制枱會根據對應的策略結合其提供的相應的診斷功能，在異常現場對識別出的異常進行信息採集和根因診斷。如下圖所示：當內存高異常被捕獲後，操作系統控制枱通過對異常現場進行診斷，最終得出當前內存高異常是由 python 應用內存佔用導致。

集羣、節點、Pod 健康綜合評價

為了方便用户能快速識別集羣或節點中的風險， 操作系統控制枱在系統概述頁面提供了整個集羣的健康概論，在這背後，我們採用了一套多維度的綜合評估算法，希望將 pod，節點的風險層層遞進，反映到集羣的健康風險中，如圖 5 所示，以節點健康度為例：

節點健康由節點的異常項（圖中為當前實例健康分）和節點中 pod（如有）的健康（圖中為下一層級實例健康分）綜合影響，其中：

• 當前實例健康分通過為各檢查項設立相應的權重通過綜合評估方法計算得出。
• 下一層級實例健康分通過分級木桶原理的方式，根據處於不同健康等級的 pod 數量計算得出。

（圖 5: 實例健康綜合評估）

如何通過阿里雲操作系統控制枱一站式定位系統問題案例解析

案例一:通過操作系統控制枱定位IO流量高問題

汽車行業某客户從監控中發現集羣中總是偶發出現節點 IO 流量非預期打高的現象，由於出現的機率不高，且出現的節點隨機，所以沒有好的辦法定位 IO 流量打高的具體原因。

針對上述場景，客户通過使用系統概覽提供的異常識別診斷能力來監控和定位該問題。

• 客户開通操作系統控制枱後，首先通過集羣的歷史健康分趨勢觀察到某一時間集羣分數（負載分）有下降。

• 通過節點健康列表可以進一步看到低分的實例：

• 跳轉至節點健康頁面後，通過異常事件分析面板可以看到當天的某一時刻節點發生了 IO 流量突增的異常，並且已經生成了對應的診斷報告。

• 通過查看診斷報告，如下圖所示，可以發現產生 IO 流量的主要是 kworker 內核線程和客户的日誌轉儲進程。kworker 線程 IO 高通常來説意味着 kworker 正在進行刷髒（將文件髒頁刷到磁盤中）操作。經過和正常機器的對比發現，問題機器的 vm.dirty_background_ratio 被設置的非常低，設置成 5%；這意味着當髒頁數量達到系統內存的 5% 後就會觸發內核線程進行髒頁回寫，導致 IO 打高。
• 客户通過將 vm.dirty_background_ratio 和 dirty_ratio 參數調大後，IO 流量規律恢復正常。

案例二：通過操作系統控制枱定位 load 高問題

汽車行業某客户業務從節點切換至容器部署後發現節點 load 總是定期飆高，需要進一步定位根因。

針對該問題，客户通過操作系統控制枱納管集羣后，客户從系統概述頁面觀察到對應集羣/節點健康分下降，異常事件中出現 load 高異常。

通過進一步查看診斷報告，可以發現在負載增加是由於大量 R 狀態進程產生造成，客户通過確認後可以確定在 load 增高的時間點業務流量增加，業務會通過創建大量線程進行處理；結合同一時間Pod中產生連續的 Pod 限流異常，可以確定是由於容器的 cpu limit 設置過小，導致線程無法短時間內完成相關邏輯，從而進一步導致線程以R狀態堆積在運行隊列中，導致 load 飆高。

問題定位後，客户通過調整業務容器 cpu limit 後，load 恢復正常。

客户收益

通過操作系統控制枱產品來快速定位集羣系統問題，客户可以獲得以下收益：

• 降低操作系統運維門檻：通過操作系統控制枱為客户設立的異常檢查項、異常識別規則以及配套的診斷工具。客户無需具有一定的操作系統知識儲備即可對操作系統問題一站式解決。
• 簡化運維流程和相關人力投入：通過操作系統控制枱系統概述，客户可以快速識別出集羣中的告警和風險，並找到問題的根源和解決方案，縮短故障的發現和排除時間。

總而言之，操作系統控制枱給雲計算和容器化運維帶來新的可能，能夠提高系統性能與運維效率，同時為企業減少了系統相關問題帶來的困擾。

我們通過阿里雲操作系統控制枱系列文章，解析系統運維遇到的痛點問題。下一期文章中，我們將分享異常檢測算法相關內容，敬請期待。

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

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