容器和實時資源監(jiān)控的必知要素

frank_fun 發(fā)布于2019-06-28 15:52 / 664人閱讀

摘要：將作為最直觀的例子盡管以下大部分適用于其他容器系統(tǒng)，包括，我們可以將實時容器指標(biāo)分為四個基本類別可以監(jiān)視單個容器使用的總內(nèi)存，以及高速緩存和交換內(nèi)存的數(shù)量，以及表示進程使用的且未緩存或存儲在磁盤上的內(nèi)存如匿名內(nèi)存映射的駐留集大小或和棧。

您是否實時監(jiān)控您的容器資源？如果沒有，那意味著您可能沒有對之進行有效監(jiān)控。在快速變化的、動態(tài)的微服務(wù)環(huán)境中，即使是幾秒鐘以前的監(jiān)視數(shù)據(jù)也可能不再可行。為了防止中斷，您需要實時監(jiān)控。

在這篇文章中，我解釋了為什么對容器資源進行實時監(jiān)控是很重要的，以及實時監(jiān)控中您應(yīng)該關(guān)注的容器指標(biāo)。

首先要明確的是，這篇文章并非在為哪個特定的容器監(jiān)控產(chǎn)品站臺。雖然現(xiàn)在有很多可供容器使用的實時監(jiān)控平臺，但我認為最好的做法，還是充分了解容器監(jiān)控的基本要素，而不是只關(guān)注特定產(chǎn)品的某些特性。如果您知道為保證容器基礎(chǔ)設(shè)施正常運行需要實時監(jiān)視什么，那么你一定能選出最佳的、最能滿足你的實時監(jiān)控需求的工具。

實時容器監(jiān)控面臨的挑戰(zhàn)

在討論如何對容器進行實時監(jiān)視之前,有必要指出實時監(jiān)視容器所帶來的特殊挑戰(zhàn)。

最明顯的是，在一個容器化的環(huán)境中，組件總是會消失。在傳統(tǒng)環(huán)境中，您監(jiān)控的大多是相對靜態(tài)的服務(wù)器和應(yīng)用程序。但容器是不斷變化的。

因此，在容器化的環(huán)境中，你需要監(jiān)控更多的東西，甚至?xí)艿礁嗟母蓴_。因此，在混亂繁多的數(shù)據(jù)中甄別有意義的數(shù)據(jù)是比較困難的，特別是當(dāng)你需要實時監(jiān)控的時候，更不應(yīng)把時間浪費在甄別過程上。

由于Docker將容器從主機中抽離的方式，實時監(jiān)控容器化的環(huán)境可能會更加困難。當(dāng)您處理容器時，您是無法簡單地通過在主機上運行諸如top或ps之類的監(jiān)控命令，來準確了解容器內(nèi)發(fā)生的情況的。

大規(guī)模地從容器內(nèi)部進行實時監(jiān)控是幾乎無法實現(xiàn)的，因此，解決這一難題的方法是使用代理或換一種更巧妙的監(jiān)控解決方案，為容器及其支持的服務(wù)提供實時可見性。

你可以監(jiān)控什么？

我們來看看您可以監(jiān)控哪些實時容器指標(biāo)。將Docker作為最直觀的例子（盡管以下大部分適用于其他容器系統(tǒng)，包括Linux-native LXD），我們可以將實時容器指標(biāo)分為四個基本類別：

Memory

Docker可以監(jiān)視單個容器使用的總內(nèi)存，以及高速緩存和交換內(nèi)存的數(shù)量，以及表示進程使用的、且未緩存或存儲在磁盤上的內(nèi)存（如匿名內(nèi)存映射）的駐留集大小或RSS 和棧。

RSS和高速緩存可以分解為活動和非活動內(nèi)存。在Docker的內(nèi)存統(tǒng)計信息中，也包含了次要（復(fù)制或分配）和主要（完全從磁盤讀取）頁面錯誤。

CPU

Docker監(jiān)控用戶CPU時間（進程本身使用的CPU）和系統(tǒng)CPU時間（進程的系統(tǒng)調(diào)用）。如果執(zhí)行CPU節(jié)流(限制給定容器可用的時間)，則還將報告容器的節(jié)流計數(shù)和時間。

I/O

對于I/O，Docker監(jiān)控 I/O的操作數(shù)和I/O的字節(jié)數(shù)。在這兩種情況下，它分別計數(shù)同步/異步和讀寫。Docker還提供讀寫扇區(qū)（512字節(jié)）的計數(shù)（讀寫統(tǒng)計在一起）以及當(dāng)前隊列中的操作數(shù)。

資源

Docker還報告了單個容器的總體網(wǎng)絡(luò)指標(biāo)，包括數(shù)據(jù)包數(shù)、字節(jié)流量、丟棄數(shù)據(jù)包以及發(fā)送和接收錯誤。

更多…

其他需要考慮的指標(biāo)包括存儲（和與存儲相關(guān)的性能指標(biāo)），以及正在使用的容器總數(shù)。除了容器的特定指標(biāo)之外，還需要對諸如整個系統(tǒng)性能、流量、用戶行為模式和應(yīng)用程序性能等傳統(tǒng)因素進行監(jiān)控，所有這些都可能直接或間接地影響容器活動。

最佳監(jiān)控方式

監(jiān)控方法和監(jiān)控服務(wù)當(dāng)然也很重要。Docker的原生監(jiān)控工具有一個簡單的接口，但在這些工具上構(gòu)建或包含的許多服務(wù)具有非常強大的功能，其中可能包括非Docker資源監(jiān)控、儀表板、容器和聚合級別的分析，以及用于警報和其他自動響應(yīng)的API。

選擇完一系列監(jiān)控工具之后，若想讓今后的工作更簡便、更易操作，可以選擇一個可以快速方便地與這些工具完成集成的容器管理平臺，如開源的容器管理平臺Rancher。這些工具很多都可以輕易與Rancher進行集成，并且可以用于監(jiān)控（和分析）一般容器中的常見資源以及Rancher特定的資源。

容器監(jiān)控為何重要？

為什么監(jiān)控諸如此類的指標(biāo)很重要？這毫不奇怪，監(jiān)控容器的主要原因與監(jiān)控其他應(yīng)用程序的主要原因密切相關(guān)：性能、錯誤檢測和異常行為的檢測。對于容器，監(jiān)控可以幫助您檢測系統(tǒng)、容器和應(yīng)用程序級別的問題。

順便說一下，這并不意味著您對容器監(jiān)控的方法與您在傳統(tǒng)環(huán)境中使用的方法相同。如上所述，容器監(jiān)控帶來了特殊的挑戰(zhàn)。但是，無論在哪種情況下，容器監(jiān)控的好處其實都一樣。

實時容器監(jiān)控和性能優(yōu)化

監(jiān)控容器性能最明顯的指標(biāo)也許是那些涉及CPU和內(nèi)存使用的指標(biāo)。某個特定的容器（或者更典型的，組成特定微服務(wù)器的容器的多個或大多數(shù)實例）占用過多的CPU時間？或過多內(nèi)存？如果是這樣，那么您就有機會通過查找和修復(fù)問題來優(yōu)化性能。

以下是一些可以通過實時監(jiān)控來解決性能問題的具體策略。

CPU節(jié)流

僅僅通過執(zhí)行CPU節(jié)流，就可以解決一些CPU過度使用的問題。然而，在其他情況下，此類性能問題可能表明設(shè)計中存在問題(在整體應(yīng)用或微服務(wù)級別)，或編碼錯誤。這些與性能相關(guān)的問題也可能出現(xiàn)在I/O甚網(wǎng)絡(luò)指標(biāo)中。

節(jié)流可以起到類似于傳統(tǒng)負載均衡功能的作用，但當(dāng)遇到與CPU相關(guān)的性能問題時，不要簡單地限制并假設(shè)能夠解決問題，這一點很重要。如果某個關(guān)鍵服務(wù)使用過多的CPU時間，則扼制它可能會以其他方式降低性能。

當(dāng)CPU或內(nèi)存問題或類似的性能問題頻發(fā)時，在設(shè)計級別上查找瓶頸和應(yīng)用程序錯誤尤為重要，因為這些問題可能會導(dǎo)致內(nèi)存、CPU服務(wù)或其他資源使用不正確或效率低下。

資源調(diào)配

性能問題也可能源于系統(tǒng)級資源配置不足。您可能需要提供更多的內(nèi)存，更多的存儲空間，更多的CPU訪問權(quán)限或切換到云服務(wù)協(xié)定，從而使您在訪問資源時獲得更高的優(yōu)先級。

資源調(diào)配并不是靈丹妙藥

與節(jié)流一樣，重要的是不要簡單地認為應(yīng)該提供更多的資源，并希望借助它解決性能問題。您應(yīng)該首先查看應(yīng)用程序體系結(jié)構(gòu)、微服務(wù)設(shè)計以及在編碼級別可能出現(xiàn)的功能問題。您不能通過簡單粗暴地提供更多資源，來解決設(shè)計問題或bug。以這種方式，也許您能夠克服明顯且直接的效率低下方面的問題，但問題的其它方面可能會繼續(xù)隱匿乃至升級，在某一時刻造成更大的麻煩。

容器監(jiān)控：錯誤和異常行為

性能問題并不是實時監(jiān)控能夠幫助您找到和解決的唯一問題。以下是其他類型的問題（與成本優(yōu)化安全性和用戶體驗相關(guān)），在執(zhí)行實時容器監(jiān)控時也應(yīng)該牢記。

未充分利用的資源

容器在低于預(yù)期水平的情況下使用資源，可能會被視為濫用資源。例如，信用卡授權(quán)微服務(wù)導(dǎo)致I/O或網(wǎng)絡(luò)資源幾乎被閑置，這可能是重大問題的征兆——無論是授權(quán)微服務(wù)本身，還是使用一個或多個的微服務(wù)，或可能僅間接涉及信用授權(quán)的應(yīng)用程序的其他部分。

可疑流量

容器監(jiān)控還可能發(fā)現(xiàn)其他形式的異常行為。如果容器正在訪問（或只是請求）通常不會使用的資源，或顯示I/O模式或網(wǎng)絡(luò)流量異常，則表示可能存在安全問題。

未滿足的需求

容器的異常行為也可能預(yù)示著不那么嚴峻 (但仍然很重要) 的問題，如用戶活動的異常模式。例如，如果用戶（出于合法原因）以比原來預(yù)期的更高級別訪問特定服務(wù)，那么您可能需要查看整體架構(gòu)、部署模式、或者添加新服務(wù)以滿足當(dāng)前未滿足的（或不滿足）用戶需求。

盡管單個容器更迭速度太快、存續(xù)時間可能不長，但關(guān)于容器生態(tài)系統(tǒng)的一切(基礎(chǔ)設(shè)施、存儲數(shù)據(jù)、用戶交互、資源可用性)卻持續(xù)煥發(fā)著強大的生命力，這些容易受到容器行為的強烈影響，并可能會對您的應(yīng)用程序性能和您的整個組織產(chǎn)生重大影響。因此，實時容器監(jiān)控不僅重要、而且必要。