作者 | 白玙

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

為什么我們需要容器監測

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

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

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

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

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

1、排障時間拖長，SLA 無法滿足。

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

2、可擴展性被拖累，無法實現彈性。

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

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

比如短暫存在特性帶來的跟蹤困難，由于容器自身存在著復雜性，容器不僅包含底層代碼，還包含應用程序運行所需的所有底層服務。隨著新部署投入生產，并更改代碼和底層服務，容器化應用程序會頻繁更新，這就增加了出錯的可能。快速創建、快速銷毀的特性，使得在大規模復雜系統中跟蹤變化變得異常困難。

又比如，由于共享資源帶來的監控困難，由于容器使用的內存和 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 監測幫你擺脫機械重復的運維工作～

總結

以上是生活随笔為你收集整理的当容器应用越发广泛，我们又该如何监测容器？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。