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

為什么我們需要容器監(jiān)測

在大規(guī)模使用容器過程中，面對高動態(tài)且需要持續(xù)監(jiān)測的容器化環(huán)境，建立監(jiān)測體系對于維持運行環(huán)境穩(wěn)定、優(yōu)化資源成本具有巨大意義。每個容器鏡像可能有大量運行實例，由于新鏡像和新版本的引入速度很快，故障很容易通過容器、應(yīng)用程序和架構(gòu)擴(kuò)散。這使得在問題發(fā)生后，為了防止異常擴(kuò)散，立即進(jìn)行問題根因定位變得至關(guān)重要。經(jīng)過大量實踐，我們認(rèn)為在容器使用過程中，以下組件的監(jiān)測至關(guān)重要：

主機(jī)服務(wù)器；
容器運行時；
Orchestrator 控制平面；
中間件依賴；
在容器內(nèi)運行的應(yīng)用程序。
在完整的監(jiān)測體系下，通過深入了解指標(biāo)、日志和鏈路，團(tuán)隊不僅可以了解在集群以及在容器運行時和應(yīng)用程序中發(fā)生的事情，也可以為團(tuán)隊進(jìn)行業(yè)務(wù)決策時提供數(shù)據(jù)支持，比如何時擴(kuò)展/縮減實例/任務(wù)/Pod、更改實例類型。DevOps 工程師還可以通過添加自動化告警以及相關(guān)配置，來提高故障排除以及資源管理效率，比如通過主動監(jiān)測內(nèi)存利用率，當(dāng)資源消耗接近所設(shè)定的閾值時通知運維團(tuán)隊對可用 CPU 、內(nèi)存資源耗盡之前添加額外節(jié)點。這其中的價值包括：

及早發(fā)現(xiàn)問題，以避免系統(tǒng)中斷；
跨云環(huán)境分析容器健康狀況；
識別分配過多/不足的可用資源的集群，調(diào)整應(yīng)用程序以獲得更好性能；
創(chuàng)建智能警報，提高報警精準(zhǔn)率，避免誤報；
借助監(jiān)測數(shù)據(jù)進(jìn)行優(yōu)化，獲得最佳系統(tǒng)性能，降低運營成本。
但在實際落地過程中，運維團(tuán)隊會覺得以上價值相對淺顯，似乎現(xiàn)有運維工具都能達(dá)到上述目的。但針對容器相關(guān)場景，如果無法構(gòu)建相應(yīng)監(jiān)測體系，隨著業(yè)務(wù)不斷擴(kuò)張，就不得不面臨以下兩個非常棘手的針對性問題：

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

開發(fā)團(tuán)隊與運維團(tuán)隊很難了解正在運行的內(nèi)容及其執(zhí)行情況。維護(hù)應(yīng)用程序、滿足 SLA 和故障排除異常困難。

2、可擴(kuò)展性被拖累，無法實現(xiàn)彈性。

按需快速擴(kuò)展應(yīng)用程序或微服務(wù)實例的能力是容器化環(huán)境的重要要求。監(jiān)測體系是衡量需求和用戶體驗的唯一可視化方法。擴(kuò)展太晚，導(dǎo)致性能與用戶體驗的下降；過晚縮小規(guī)模，又會導(dǎo)致資源以及成本的浪費。

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

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

又比如，由于共享資源帶來的監(jiān)控困難，由于容器使用的內(nèi)存和 CPU 等資源在一臺或多臺主機(jī)之間共享，因此很難監(jiān)控物理主機(jī)上資源消耗情況，也導(dǎo)致很難獲得容器性能或應(yīng)用程序健康狀況的良好指示。

最后，就是傳統(tǒng)工具難以滿足容器監(jiān)測需求。傳統(tǒng)的監(jiān)測解決方案通常缺乏虛擬化環(huán)境所需的指標(biāo)、跟蹤和日志所需的工具，容器的健康和性能指標(biāo)及工具更是如此。

因此，結(jié)合以上的價值、問題、難點，我們在建立容器監(jiān)測體系時，需要從以下幾個維度進(jìn)行考量與設(shè)計：

無侵入性：監(jiān)測SDK或者探針集成到業(yè)務(wù)代碼是否存在侵入性，影響業(yè)務(wù)穩(wěn)定下；
整體性：是否可以觀測整個應(yīng)用程序在業(yè)務(wù)和技術(shù)平臺方面的表現(xiàn)；
多源性：是否可以從不同數(shù)據(jù)源獲取相關(guān)指標(biāo)和日志集進(jìn)行匯總顯示、分析和警報；
便捷性：是否可以關(guān)聯(lián)事件和日志，發(fā)現(xiàn)異常并主被動地排除故障并降低損失，相關(guān)告警策略配置是否便捷。
在明確業(yè)務(wù)需求以及設(shè)計監(jiān)測體系過程中，有非常多開源工具供運維團(tuán)隊選擇，但運維團(tuán)隊還需要評估可能存在的業(yè)務(wù)與項目風(fēng)險。這其中包括：

存在影響業(yè)務(wù)穩(wěn)定性的未知風(fēng)險，監(jiān)測服務(wù)是否可以做到“無痕”。監(jiān)測過程本身是否影響系統(tǒng)正常運作。
開源或自研的人力/時間投入難以預(yù)計，關(guān)聯(lián)組件或資源需要自行配置或搭建，缺乏相應(yīng)支持與服務(wù)，隨著業(yè)務(wù)不斷變化，是否可能耗費更多人力及時間成本。且面對大規(guī)模場景下性能問題，開源或企業(yè)自有團(tuán)隊是否可以快速應(yīng)對。

阿里云 Kubernetes 監(jiān)測：讓容器集群監(jiān)測更直觀、更簡單

因此，基于上述洞察考量與大量實踐經(jīng)驗，阿里云推出 Kubernetes 監(jiān)測服務(wù)。阿里云 Kubernetes 監(jiān)測是一套針對 Kubernetes 集群開發(fā)的一站式可觀測性產(chǎn)品。基于 Kubernetes 集群下的指標(biāo)、應(yīng)用鏈路、日志和事件，阿里云 Kubernetes 監(jiān)測旨在為 IT 開發(fā)運維人員提供整體的可觀測性方案。阿里云 Kubernetes 監(jiān)測具備以下六大特性：

代碼無侵入：通過旁路技術(shù)，無需代碼埋點，即可獲取到網(wǎng)絡(luò)性能數(shù)據(jù)。
多語言支持：通過內(nèi)核層進(jìn)行網(wǎng)絡(luò)協(xié)議解析，支持任意語言及框架。
低耗高性能：基于 eBPF 技術(shù)，以極低消耗獲取網(wǎng)絡(luò)性能數(shù)據(jù)。
資源自動拓?fù)洌?/strong>通過網(wǎng)絡(luò)拓?fù)洌Y源拓?fù)湔故鞠嚓P(guān)資源的關(guān)聯(lián)情況。
數(shù)據(jù)多維展現(xiàn)：支持可觀測的各種類型數(shù)據(jù)（監(jiān)測指標(biāo)、鏈路、日志和事件）。
打造關(guān)聯(lián)閉環(huán)：完整關(guān)聯(lián)架構(gòu)層、應(yīng)用層、容器運行層、容器管控層、基礎(chǔ)資源層相關(guān)可觀測數(shù)據(jù)。
與此同時，相對于與開源容器監(jiān)測，阿里云 Kubernetes 監(jiān)測具備更加貼近業(yè)務(wù)場景的差異化價值：