當容器應用愈加普遍，咱們又該如何監測容器？

​簡介： 隨着容器技術蓬勃發展與落地推行，愈來愈多企業的業務運行於容器中。做爲主流部署方式之一，容器將團隊的任務和關注點分割開，開發團隊只需關注應用程序邏輯和依賴項，而運維團隊只需關注部署和管理，無需再爲特定軟件版本和應用程序特定配置等應用程序細節而提心吊膽。這意味着開發團隊和運維團隊能夠花費更少時間進行調試上線，將更多時間用於向最終用戶交付新功能。容器使企業能夠更加輕鬆的提升應用程序可移植性和操做彈性。據 CNCF 的調研報告顯示，73% 受訪者正在使用容器來提升生產敏捷性並加快創新速度。

做者 | 白璵

爲何咱們須要容器監測

在大規模使用容器過程當中，面對高動態且須要持續監測的容器化環境，創建監測體系對於維持運行環境穩定、優化資源成本具備巨大意義。每一個容器鏡像可能有大量運行實例，因爲新鏡像和新版本的引入速度很快，故障很容易經過容器、應用程序和架構擴散。這使得在問題發生後，爲了防止異常擴散，當即進行問題根因定位變得相當重要。通過大量實踐，咱們認爲在容器使用過程當中，如下組件的監測相當重要：

• 主機服務器；
• 容器運行時；
• Orchestrator 控制平面；
• 中間件依賴；
• 在容器內運行的應用程序。

在完整的監測體系下，經過深刻了解指標、日誌和鏈路，團隊不只能夠了解在集羣以及在容器運行時和應用程序中發生的事情，也能夠爲團隊進行業務決策時提供數據支持，好比什麼時候擴展/縮減實例/任務/Pod、更改實例類型。DevOps 工程師還能夠經過添加自動化告警以及相關配置，來提升故障排除以及資源管理效率，好比經過主動監測內存利用率，當資源消耗接近所設定的閾值時通知運維團隊對可用 CPU 、內存資源耗盡以前添加額外節點。這其中的價值包括：

• 及早發現問題，以免系統中斷；
• 跨雲環境分析容器健康情況；
• 識別分配過多/不足的可用資源的集羣，調整應用程序以得到更好性能；
• 建立智能警報，提升報警精準率，避免誤報；
• 藉助監測數據進行優化，得到最佳系統性能，下降運營成本。

但在實際落地過程當中，運維團隊會以爲以上價值相對淺顯，彷佛現有運維工具都能達到上述目的。但針對容器相關場景，若是沒法構建相應監測體系，隨着業務不斷擴張，就不得不面臨如下兩個很是棘手的針對性問題：

一、排障時間拖長，SLA 沒法知足。

開發團隊與運維團隊很難了解正在運行的內容及其執行狀況。維護應用程序、知足 SLA 和故障排除異常困難。

二、可擴展性被拖累，沒法實現彈性。

按需快速擴展應用程序或微服務實例的能力是容器化環境的重要要求。監測體系是衡量需求和用戶體驗的惟一可視化方法。擴展太晚，致使性能與用戶體驗的降低；過晚縮小規模，又會致使資源以及成本的浪費。

所以，當容器監測的問題以及價值，不斷疊加且浮出水面，愈來愈多運維團隊開始重視容器監測體系的搭建。但在實際落地容器監測這一過程當中，又遇到各類各樣意料以外的問題。

好比短暫存在特性帶來的跟蹤困難，因爲容器自身存在着複雜性，容器不只包含底層代碼，還包含應用程序運行所需的全部底層服務。隨着新部署投入生產，並更改代碼和底層服務，容器化應用程序會頻繁更新，這就增長了出錯的可能。快速建立、快速銷燬的特性，使得在大規模複雜系統中跟蹤變化變得異常困難。

又好比，因爲共享資源帶來的監控困難，因爲容器使用的內存和 CPU 等資源在一臺或多臺主機之間共享，所以很難監控物理主機上資源消耗狀況，也致使很難得到容器性能或應用程序健康情況的良好指示。

最後，就是傳統工具難以知足容器監測需求。傳統的監測解決方案一般缺少虛擬化環境所需的指標、跟蹤和日誌所需的工具，容器的健康和性能指標及工具更是如此。

所以，結合以上的價值、問題、難點，咱們在創建容器監測體系時，須要從如下幾個維度進行考量與設計：

• 無侵入性：監測SDK或者探針集成到業務代碼是否存在侵入性，影響業務穩定下；
• 總體性：是否能夠觀測整個應用程序在業務和技術平臺方面的表現；
• 多源性：是否能夠從不一樣數據源獲取相關指標和日誌集進行彙總顯示、分析和警報；
• 便捷性：是否能夠關聯事件和日誌，發現異常並主被動地排除故障並下降損失，相關告警策略配置是否便捷。

在明確業務需求以及設計監測體系過程當中，有很是多開源工具供運維團隊選擇，但運維團隊還須要評估可能存在的業務與項目風險。這其中包括：

• 存在影響業務穩定性的未知風險，監測服務是否能夠作到「無痕」。監測過程自己是否影響系統正常運做。
• 開源或自研的人力/時間投入難以預計，關聯組件或資源須要自行配置或搭建，缺少相應支持與服務，隨着業務不斷變化，是否可能耗費更多人力及時間成本。且面對大規模場景下性能問題，開源或企業自有團隊是否能夠快速應對。

阿里雲 Kubernetes 監測：讓容器集羣監測更直觀、更簡單

所以，基於上述洞察考量與大量實踐經驗，阿里雲推出 Kubernetes 監測服務。阿里雲 Kubernetes 監測是一套針對 Kubernetes 集羣開發的一站式可觀測性產品。基於 Kubernetes 集羣下的指標、應用鏈路、日誌和事件，阿里雲 Kubernetes 監測旨在爲 IT 開發運維人員提供總體的可觀測性方案。阿里雲 Kubernetes 監測具有如下六大特性：

• 代碼無侵入：經過旁路技術，無需代碼埋點，便可獲取到網絡性能數據。
• 多語言支持：經過內核層進行網絡協議解析，支持任意語言及框架。
• 低耗高性能：基於 eBPF 技術，以極低消耗獲取網絡性能數據。
• 資源自動拓撲：經過網絡拓撲，資源拓撲展現相關資源的關聯狀況。
• 數據多維展示：支持可觀測的各類類型數據（監測指標、鏈路、日誌和事件）。
• 打造關聯閉環：完整關聯架構層、應用層、容器運行層、容器管控層、基礎資源層相關可觀測數據。

與此同時，相對於與開源容器監測，阿里雲 Kubernetes 監測具有更加貼近業務場景的差別化價值：

• 數據量無上限：指標、鏈路、日誌等數據獨立存儲，藉助雲存儲能力確保低成本大容量存儲。
• 資源高效關聯交互：經過監測網絡請求，完整構建網絡拓撲，便於查看服務依賴狀態，提高運維效率。除了網絡拓撲以外，3D 拓撲功能支持同時查看網絡拓撲和資源拓撲，提高問題定位速度。
• 多樣化數據組合：指標、鏈路、日誌等數據可視化展現並自由組合，挖掘運維優化點。
• 構建完整監測體系：與應用實時監測服務的其餘子產品，共同構建完整監測體系。應用監測關注應用語言運行時、應用框架與業務代碼；Kubernetes 監測關注容器化應用的容器運行時、容器管控層與系統調用，兩個監測均服務於應用，關注應用的不一樣層次，兩個產品互爲補充。Prometheus 是指標採集，存儲，查詢的基礎設施，應用監測與 Kubernetes 監測的指標類數據均依賴 Prometheus。

​

基於以上產品特性與差別化價值，咱們應用在如下場景：

• 經過 Kubernetes 監測的系統默認或者自定義巡檢規則，發現節點，服務與工做負載的異常。Kubernetes 監測從性能、資源、管控三個維度對節點、服務與工做負載進行異常巡檢，將分析結果直觀地經過正常、警告、嚴重等狀態配合特定顏色進行展現，幫助運維人員直觀感知用戶節點，服務與工做負載運行狀態。

​

• 使用 Kubernetes 監測定位服務與工做負載響應失敗根因，Kubernetes 監測經過分析網絡協議對失敗請求進行明細存儲，利用失敗請求指標關聯的失敗請求明細定位失敗緣由。
• 使用 Kubernetes 監測定位服務與工做負載響應慢根因，Kubernetes 監測經過抓取網絡鏈路關鍵路徑的指標，查看 DNS 解析性能，TCP 重傳率，網絡包 rtt 等指標。利用網絡鏈路關鍵路徑的指標定位響應慢的緣由，進而優化相關服務。

​

• 使用 Kubernetes 監測探索應用架構，發現預期外的網絡流量。Kubernetes 監測支持查看全局流量構建起來的拓撲大圖，支持配置靜態端口標識特定服務。利用拓撲圖直觀強大的交互進行應用架構探索，驗證流量是否符合預期，架構形態是否合理。

​

​

• 使用 Kubernetes 監測發現節點資源使用不均勻的問題，提早進行節點資源調配，下降業務運行風險。

​

目前，Kubernetes 監測已經開啓全面公測，公測期間無償使用。讓 Kubernetes 監測幫你擺脫機械重複的運維工做～

原文連接
本文爲阿里雲原創內容，未經容許不得轉載。

​