編者按：龍蜥社區系統運維 SIG Contributor 劉馨蔚在 2023 龍蜥操作系統大會上分享了隨着雲原生的發展，給運維帶來了極大挑戰，並提到了現有運維產品的現狀和不足。爲了解決這些痛點，實現“零”運維，提出了兩點解決方案。以下爲本次分享全文：
（圖/龍蜥社區系統運維 SIG Contributor 劉馨蔚）
01 當前運維的趨勢和挑戰
隨着雲原生不斷的發展，給用戶帶來了非常多的便利，開發會變得更簡單。同時大家不用再去感知機器、容器甚至系統底層的信息。相反，用戶體驗的提升也帶來一些挑戰和機遇。
應用的運維功能上移，系統運行的情況無法深入感知，導致系統運維無所適從。基於此，龍蜥社區系統運維 SIG 打造了一站式操作系統運維平臺，融入了 SIG 成員的成功商用運維實踐經驗，能夠幫助用戶在統一平臺上實現主機管理、系統監控、異常診斷、日誌審計、安全管控等複雜操作系統管理 SysOM（ System Operation&Maintenance）。SysOM 從兩個方向去解決類似的問題，一是 SysOM 的應用觀測方案，從應用視角主動觀測、通過垂直往下的剖析，分析問題根因，針對 MySQL、應用調用關係追蹤、Java 場景的觀測方案；第二是針對大規模集羣的智能監控方案，其中從容器角度、節點角度去評估集羣的健康狀態，並結合 AI 指標關聯分析、智能化深度診斷，分析問題根因。
上圖是目前運維產品的現狀和挑戰。比如有些配置型的部署，可能有比較多的指標，看着這些指標只知其然，不知所以然。對於系統監控，有比較熟悉的 Grafana，也有比較多的指標數據、指標大盤。但有一個問題，大家在看到這些大盤之後，並不能清楚接下來需要做什麼操作動作，也不知道這些指標帶來的告警意義。同樣的，大家可以在用戶態通過 perf 等工具進行問題的定位，而這個就需要專業級別的系統運維人員，同時通過大量的工具組合的應用，這個也可以說是難知所以然。
上圖中出現的內核問題案例，由進程 B 引發了這樣的申請內存並訪問，進而引發了一些內存訪問延時或者是內存不足的警告。但是大家可能無法立即看到它是由進程 A 不斷的頻繁讀寫文件造成大量的 page Cache 而形成的。在日常操作中，不僅是以上案例所闡述的內存問題，可能在操作系統內部網絡、IO、內存、文件系統調度都存在大量的類似問題。
02 探索及實現路徑
基於運維產品的現狀和挑戰，帶大家回顧一下 Llinux 的跟蹤及觀測技術。
從內核態到用戶態中間，比如有內核的 KO、kprobe，中間一層有 eBPF 及 tracing 的一些功能，到用戶態通過 perf 或者是 libbpf 都可以實現跟蹤及觀測。
SysOM 也希望從底部到頂部，不管是從內核模塊或者是 trace，還是 BPF，到更接近客戶的應用層的 profiling，再到應用的可觀測，我們希望更貼近用戶，即使知道可能是比較底層的問題。但是也希望從用戶的角度去解決這些問題。
上圖是可觀測的成熟度模型。通過可靠性和用戶的滿意度，希望達到最高的業務的可觀測性。如最普通的監控，可以監測相關的健康的狀態，或者是通過報警的規則去自動觸發報警。通過不斷的進步，可以從基礎的可觀測性到因果，到主動的可觀測性，最後更加貼近用戶，達到業務的可觀測性。
接下來分享下 SysOM 在智能監控上的一些措施和演進道路。主要關注四個大的指標，一是延時，比如說在通過系統調用的延時或者中斷的延時。第二個就是流量，包括網絡的流量，或者是一些系統的吞吐和負載。第三個就是可能遇到的系統錯誤，包括可能會遇到的宕機、Hungtask 等，可以在系統日誌中找到一些錯誤。第四個就是飽和度，這個是在有限資源的使用情況下，比如說 CPU 或者內存，是否有使用超限的情況。通過以上監控報警指標，結合自動化分析診斷、根因分析，達到自動化修復，快速修復的過程。
值得一提的是，智能監控包含了集羣健康度的評估。包括容器、節點到整個集羣方面，都有一系列的評估標準，以此來去評估節點、容器、集羣是否有健康度。由於在多個指標當中，並不一定能夠快速的去定位到當前整個集羣的狀態，可能某一些指標或者是一些聯合的指標都有問題的時候，可以反映出集羣是否健康的程度。同時再結合指標關聯的根因分析，去實現從衆多的指標監控收集上來的信息去自動化的分發診斷，匹配更深層的診斷，得到更好的解決方案。
對於混部場景，龍蜥社區系統運維 SIG 也有一些探索。首先是對整個資源畫像去做了算法上的研究。由於在線任務是普遍存在潮汐規律的，所以在混步場景中會對它進行資源畫像的訓練。同時，還會對相關的水位進行評估。通過訓練和評估之後，會給出系統參數的一些配置和調整建議。
綜上兩個方面，我們是希望從底層去進行監控上的採集指標，結合中心端數據分析，例如指標關聯分析、日誌分析、異常事件分析，做到輕量級的診斷，能夠自動化的進行，或者是提示給用戶可以進行更深層次的一些診斷。做到這樣的 AI 根因分析和智能診斷，實現應用性能和瓶頸發現、智能監控、異常告警及深入診斷。
03 SysOM 應用觀測實踐
從應用觀測上來說，主要是想深度剖析的問題成因，自頂向下的關聯去降低應用運維門檻，可以覆蓋典型的包括 Mysql、Java 和 Nginx 這樣的應用，包括全局的流量拓撲、數據庫可應用的觀測、Java 應用的可觀測和 HTTP 應用的可觀測。
上圖就是全局流量拓撲。可以看到如果節點異常的時候會將它標紅，同時輕觸會有相關的彈出指標，可以跳轉到應用的監控大盤或者是異常事件的大盤。通過調轉之後，再去進行相應的分析診斷，根因分析。這樣的全局流量拓撲，也使得用戶能夠有更直觀的場景，去看到集羣或者主機上的應用狀態。
上圖是 Mysql 的應用實踐。可以看到指標監控出現了一些異常的浮動。點擊相關的異常，看到下面可以觀測到 RT 也高上來，點擊圖示的一些異常或者 RT 高的事件之後，可以進入相關的分析診斷頁面，會給用戶提示出相關的診斷信息，或者是否需要進行相關的深入診斷。
對於 Nginx 應用也是類似，會觀測到指標的異常或者是數據的抖動，也有相對應的異常事件可以進行點擊跳轉，去到更加深層次的診斷。
對於Java 的應用，會關注實時 RT 或者是一佔用 CPU 高的一些指標，或者是如上圖右下角所示的一些抖動。對於Java 運行時的分析，在 SysOM 整個運行頁面上，可以點擊左上角去進行異常原因的進一步診斷，同時會給出修復的建議。同時結合 Java 調用棧去給出關鍵的調用棧信息。再比如剛剛上圖還有實時 RT，可能也有一些走延時增大這樣的現象，也是同樣的進入診斷界面可以看到，此時主要時間是消耗在 CPU 上。對於抖動，也可以從左鍵點入進入指標異常分析，類似的有對於多個指標進行指標關聯，指標對比，再去通過指標給出更加詳細的異常原因和推薦進一步的診斷和修復建議。
04 SysOM 智能監控實踐
上圖是對機器上的監控告警，是系統 fd 超過的告警。通過點擊告警按鈕的詳細之後，可以看到目前是怎樣的系統情況會報警，同時可以看到節點 fd 使用量的 top10 的進程，可以很快的找出是哪些進程去造成了這一次的異常，進而給出相關的修復建議。
上圖是集羣健康度的實際實踐應用，包括節點、容器、集羣，都有一套衡量健康度的體系，不需要關注過多的指標，後臺就會將這些指標進行關聯根因分析，再去體現集羣節點健康度。
指標關聯，會去關聯後臺衆多的指標，給出異常原因的分析和接下來可以用到的診斷建議。
上圖中的案例是分析 CPU 利用率高的問題。大家在指標異常點中，可以點擊異常點，會跳轉診斷中心鏈接，再去用深度診斷的工具，進行 CPU 高的問題分析。
本文爲阿里雲原創內容，未經允許不得轉載。