【華為云Stack】【大架光臨】第10期：云原生時代，政企混合云場景IT監控和診斷的難點和應對之道

一、政企混合云的架構演進和監控診斷進化路線解析

隨著2013年云原生(Cloud Native)概念的正式提出到現在，云原生架構發展已經歷了快10年了。雖然發展過程中，其概念被CNCF組織、各大云廠商不斷豐富和發展，但是其核心理念——面向大規模分布式場景的微服務和容器化架構，一直貫穿其中。伴隨著政企的IT架構從傳統的單體煙囪式架構朝著云化的云原生架構邁進，IT的監控診斷難度也隨之指數級增加。正是因為政企IT架構云化的云原生架構，相比之前的單體煙囪式架構，在監控診斷方面有著更多的難點和挑戰，這也在業界催生出大量相關的標準和工具。以下舉出5個例子，分別從微服務架構、容器彈性架構、海量中間件、SDN網絡、云管平臺 五個維度加以說明。

海量微服務化的業務應用架構，催生出基于全鏈路追蹤的APM工具

傳統的政企IT架構，由于按照項目進行"煙囪式"建設，演化出一個個單體應用。雖然在架構擴展性上存在一定問題，但是對于運維人員來講，運維難度相對較低。傳統的IT運維人員只需要熟悉相關的OS, 中間件，和相關應用軟件的運維操作即可。但是在微服務架構下，由于整體業務無論在橫向還是縱向的劃分上，都進行了很大程度上的拆分，導致運維難度快速上升。例如對于一個基于微服務架構改造后的電子商務系統，核心的交易應用突然異常的情況下，到底是應用本身某個單實例或所有實例出了問題，或是應用的下游中間件出現問題，還是應用的下游的某個應用出了問題，這些各種異常的可能性，都大大增加了微服務架構下的應用診斷難度。顯然，常規的針對單體應用的上線看日志診斷故障的思路已經不能滿足運維需求了。

基于以上問題，業界提出了分布式鏈路追蹤的解決方案。其核心思路始于Google Dapper的論文，通過注入trace、span等信息打通微服務之間的調用，以對復雜微服務的環境下對業務問題進行面向微服務的故障定位。類似的開源界標準 Opentracing, 開源社區如Pinpoint，Jaeger等，包括各類商業化APM產品也大都基于此原理解決該場景的運維問題。

面向容器的彈性架構，強調故障時動態運行現場信息采集

相比于傳統物理機或虛擬機架構，面向容器化架構的故障診斷又為運維難度帶來新的挑戰。首先，應用不再是靜態地和計算資源綁定，而是動態地基于容器調度器實時調度。比如事發故障到底是在哪天物理機或虛擬機上？根因可能是因為什么資源故障引起的？這些都變得難以判斷。其次，由于容器進程默認進程結束后，相關資源會被清理，導致現場信息收集難度進一步加大。比如，崩潰內核文件在哪里？現場日志文件哪里找？在默認情況下，由于文件系統會被清理，上訴關鍵文件或信息都無法獲取。

由此衍生出的各類的容器監控服務、日志服務，重點解決此類問題。專業的容器服務除了收集容器性能指標以外（如cadvisor、promethues），還需要重點保留現場的容器拓撲快照（如kur8），以方便進行問題場景還原。與此同時，日志服務(如ElasticSearch+Logstash組合)被廣泛用于容器場景，保證重要的日志文件都能動態地被服務采集收集到云端，在必要的時候在POD即便已被銷毀的情況下，對第一故障事發現場進行有效還原。

分布式應用架構下海量中間件監控難度提高，引出面向標準化的Metrics、Log采集和分析工具

傳統架構下的單一應用僅需傳統關系型數據庫即可。由于架構和業務簡單，除了傳統的事務類信息，其他信息比如日志、時序數據、甚至消息 (參考rabbitmq實現) 都有可能通過數據庫實現。因此在傳統架構下，往往核心中間件只需要掌握數據庫運維一個核心技能即可。但是在云原生時代，隨著業務的多樣化，規模化，各種極限場景下發揮出色的 NoSQL數據庫和其他各類中間件 層出不窮。例如使用緩存解決高性能場景、使用消息進行業務系統解耦、使用搜索引擎解決各類復雜搜索場景，使用列存數據庫應對時序時空數據，使用ZooKeeper、Etcd確保分布式場景下的數據一致性等等。復雜系統對人員的運維水平提出新的挑戰。如何針對這些中間件提供有效統一的運維手段，也成為運維的關鍵難點。

為了統一運維語言，業界也基于Promethues演化出了OpenMetircs的實時標準。由此，各中間件自行提煉出核心關鍵的性能指標，并以OpenMetrics標準對外予以暴露，逐漸變成了行業標準。再加上流行的Promethues + Grafana架構不僅可以基于數據采集標準進行實時數據收集和報警的同時，還可以基于采集數據快速定制可視化的報表或大盤，大大方便了業務人員第一時間定位業務問題。借此，雖然專業的各中間件專業級運維難度仍然居高不下，但是核心的業務指標的提煉和開發直接下層到了各商業或開源中間件社區本身，從而大大降低了運維人員的入門門檻。

虛擬化SDN網絡架構普及，面向軟硬一體的網絡監控成為剛需

傳統架構下，物理網絡、VLAN、VxLAN的應用基本上能應對大部分網絡需求。但是在云原生架構下，往往需要借助更復雜的SDN和網絡虛擬化來進一步解決網絡問題。從容器、虛擬機網絡出口，到虛擬機交換機、虛擬機路由器、虛擬防火墻、虛擬網絡負載均衡、虛擬終端節點，再到底層物理網絡設備，中間任何一個節點出現問題，將導致上層應用鏈路出現故障。而由于中間的網絡鏈路往往過于復雜，導致診斷難度也同樣無限放大。

為應對復雜的云網絡監控需求，大量針對SDN的NPM網絡監控技術也運營而生。此時的網絡監控工具不僅能對各個維度，譬如vlan，站點,vxlan, QoS等進行自由組合分析，還需要全面支持虛擬化的網元監控。這里面既包括通過主動撥測技術監控宿主機內部虛擬機之間的流量；又能夠基于SDN控制器通過ERSPAN技術創建虛擬鏡像端口或者其它方式來獲得鏡像流量，進行特定場景的問題診斷或后續大數據分析。最終，結合相應AI算法和網絡知識圖譜，運維人員針對SDN的網絡運維得到極大簡化。

由于云平臺本身的復雜運維，專業的云管平臺運維工具成為標配

云計算相對于傳統IT架構來講來講，云管平臺本身的運維是一個復雜的課題。試想一個IOE架構下的網絡設計，在小型機上的網絡設置，無論是中間件運維和還是數據庫運維，都是針對業務本身的運維，并不涉及復雜的平臺運維。但是在云時代，由于云平臺的管理本身是一個非常復雜的系統，對租戶應用一般不可見，再加上其本身之上承載了很多租戶面的運維工具，為了防止循環依賴，因此如何針對云管平臺本身的運維是各個云廠商需要亟待解決的問題。

二、混合云全棧中的監控診斷的工具孤島問題

在云計算方面，對于以上各個領域的組件運維，似乎業界都有比較明確的架構思路和相關產品。但是當各類方案和架構放一起的時候，往往運維人員會變得無所適從。

試想，在基于云原生業務架構的混合云運維場景中，您的記憶中是否出現過以下扯皮問題：

? 業務黃金指標異常，到底該把哪些運維人員召集起來一起診斷？云平臺運維人員還是應用運維人員？

? 中間件故障頻發，到底是業務使用問題，還是云平臺故障，抑或是中間件自身問題？

? 為啥物理網絡顯示正常，業務網絡還是頻現閃斷？中間的虛擬網元鏈路到底是否異常？又有哪些涉及到的虛擬網元？

以上問題都無疑加劇了運維的困難。究其原因，無外乎因為以下原因，

? 眾多工具，往往由于面向各自運維領域和專業技術略有不同，導致工具形成了一個個工具孤島。

? 不同的工具孤島間接導致不同的使用群體，出現問題時由于信息流、溝通語言不統一，不僅導致問題困難，又容易造成各類推諉扯皮。、

因此，在全棧云體系中，如何構建一個底層的系統，其具備統一的運維體系和語言，使得業務黃金指標出現故障時，能有效通過該系統，綜合各個系統維度的日志、指標、鏈路、事件信息，快速進行根因定位和故障恢復，成為混合云全棧監控的新的挑戰。我們把這個目標系統簡稱為：混合云的全息排查系統。

三、未來方向：構建面向政企混合云全棧的全息排查系統

為解決混合云全棧中的監控診斷的工具孤島問題，我們提出全息排查系統。混合云的全息排查系統核心思路是，在不破壞各專業運維工具邊界情況下，基于業界各類標準進行核心數據采集，構筑一個統一的北向實時分析系統。該系統的核心模塊有兩個，

? 面向Metrics、Log、Tracing的異常檢測模塊。該異常檢測模塊可基于各類數據標準 (參考OpenCensus、OpenTracing、OpenMetrics等標準) 上收數據，通過各類AI算法，對各類異常事件進行有效檢測。通過此模塊，全息排查系統不僅可大幅度提高異常檢測精度、降低人工干預的報警配置工作量，還可以進一步降低和各類標準運維工具的耦合程度，即：各類標準運維工具專注原生數據(Native Data)采集和處理、以及特定技術場景的運維輔助流程；智能的異常診斷交由異常檢測模塊統一處理。

? 結合基于各類系統、應用拓撲 和 運維經驗的知識圖譜和全棧各類事件的根因診斷模塊。根因診斷算法業界有很多種，但是基于知識圖譜的根因診斷無疑可以大大增加根因診斷的精確度。在混合云的根因診斷中，知識圖譜的核心是構筑混合云全棧的資源拓撲關系，包括虛擬機和物理機、網絡各類SDN網元、容器、數據庫和中間件、應用和應用實例、以及業務數據流的調用走向等。結合相關運維經驗，通過數據挖掘算法，既可以針對業務黃金指標異常事件快速進行根因定位，也可以針對特定的異常事件進行爆炸半徑估算，控制爆炸半徑范圍。

基于混合云全息排查系統，混合云全棧故障診斷的復雜問題有望得到極大程度解決。這里最核心的邏輯是，全息排查提供了一個基于全棧云架構的統一模型之上的全景監控平臺，方便來自各個領域的運維專家匯聚于此進行專家會診。

? 首先，各個領域的運維專家都能在全息排查系統以其獨有的視角觀察其關心的核心組件的健康狀態。

? 其次，各個領域的運維專家還能直接在其之上觀察其直接或間接關聯的組件的監控狀態。

? 核心業務負責人可以觀測其核心依賴鏈路上所有相關的上下游應用 以及其底層虛擬和物理資源的監控狀況。

? 中間件負責人可以觀測其上游應用和其所在虛擬資源和物理硬件的監控情況。

? 業務負責人還可以詳細觀測基于業務流量實際跨過的物理和虛擬網元的狀態，到底是虛擬交換機還是物理交換機出問題，一目了然。

? 最重要的，針對各類故障場景，全息排查系統提供各類場景化頁面，供運維人員在各類場景進行診斷。

? 針對特定業務的黃金指標異常，運維人員可以通過系統進行快速根因診斷，并提供對應的故障恢復建議。

? 針對特定重要組件異常，運維人員可以通過系統進行爆炸半徑估算，及時采取措施，進行風險防控。

? 對于特定的運維場景，全息排查系統還可以通過特定事件信息，跳轉到特定的運維系統頁面(如APM、AOM、等)，方便運維人員進行事件明細查看。

混合云的全息排查系統無疑在診斷方面可以彌補各孤島工具中的斷裂點，為用戶構建一個整合過的監控診斷平臺，從而大大可提高混合云全棧的監控診斷效率。

在最近的華為云Stack中，我們將會推出相關的工具和平臺，以幫助IT管理人員大幅降低混合云全棧監控的難度，敬請期待。

云原生 華為云Stack 混合云 運維

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。