容器和實時資源監控的必知要素

您是否實時監控您的容器資源？若是沒有，那意味着您可能沒有對之進行有效監控。在快速變化的、動態的微服務環境中，即便是幾秒鐘之前的監視數據也可能再也不可行。爲了防止中斷，您須要實時監控。

在這篇文章中，我解釋了爲何對容器資源進行實時監控是很重要的，以及實時監控中您應該關注的容器指標。

首先要明確的是，這篇文章並不是在爲哪一個特定的容器監控產品站臺。雖然如今有不少可供容器使用的實時監控平臺，但我認爲最好的作法，仍是充分了解容器監控的基本要素，而不是隻關注特定產品的某些特性。若是您知道爲保證容器基礎設施正常運行須要實時監視什麼，那麼你必定能選出最佳的、最能知足你的實時監控需求的工具。

實時容器監控面臨的挑戰

在討論如何對容器進行實時監視以前,有必要指出實時監視容器所帶來的特殊挑戰。

最明顯的是，在一個容器化的環境中，組件老是會消失。在傳統環境中，您監控的大可能是相對靜態的服務器和應用程序。但容器是不斷變化的。

所以，在容器化的環境中，你須要監控更多的東西，甚至會受到更多的干擾。所以，在混亂繁多的數據中甄別有意義的數據是比較困難的，特別是當你須要實時監控的時候，更不該把時間浪費在甄別過程上。

因爲Docker將容器從主機中抽離的方式，實時監控容器化的環境可能會更加困難。當您處理容器時，您是沒法簡單地經過在主機上運行諸如top或ps之類的監控命令，來準確瞭解容器內發生的狀況的。

大規模地從容器內部進行實時監控是幾乎沒法實現的，所以，解決這一難題的方法是使用代理或換一種更巧妙的監控解決方案，爲容器及其支持的服務提供實時可見性。

你能夠監控什麼？

咱們來看看您能夠監控哪些實時容器指標。將Docker做爲最直觀的例子（儘管如下大部分適用於其餘容器系統，包括Linux-native LXD），咱們能夠將實時容器指標分爲四個基本類別：

Memory

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

RSS和高速緩存能夠分解爲活動和非活動內存。在Docker的內存統計信息中，也包含了次要（複製或分配）和主要（徹底從磁盤讀取）頁面錯誤。

CPU

Docker監控用戶CPU時間（進程自己使用的CPU）和系統CPU時間（進程的系統調用）。若是執行CPU節流(限制給定容器可用的時間)，則還將報告容器的節流計數和時間。

I/O

對於I/O，Docker監控 I/O的操做數和I/O的字節數。在這兩種狀況下，它分別計數同步/異步和讀寫。Docker還提供讀寫扇區（512字節）的計數（讀寫統計在一塊兒）以及當前隊列中的操做數。

網絡資源

Docker還報告了單個容器的整體網絡指標，包括數據包數、字節流量、丟棄數據包以及發送和接收錯誤。

更多…

其餘須要考慮的指標包括存儲（和與存儲相關的性能指標），以及正在使用的容器總數。除了容器的特定指標以外，還須要對諸如整個系統性能、流量、用戶行爲模式和應用程序性能等傳統因素進行監控，全部這些均可能直接或間接地影響容器活動。

最佳監控方式

監控方法和監控服務固然也很重要。Docker的原生監控工具備一個簡單的接口，但在這些工具上構建或包含的許多服務具備很是強大的功能，其中可能包括非Docker資源監控、儀表板、容器和聚合級別的分析，以及用於警報和其餘自動響應的API。

選擇完一系列監控工具以後，若想讓從此的工做更簡便、更易操做，能夠選擇一個能夠快速方便地與這些工具完成集成的容器管理平臺，如開源的容器管理平臺Rancher。這些工具不少均可以輕易與Rancher進行集成，而且能夠用於監控（和分析）通常容器中的常見資源以及Rancher特定的資源。

容器監控爲什麼重要？

爲何監控諸如此類的指標很重要？這絕不奇怪，監控容器的主要緣由與監控其餘應用程序的主要緣由密切相關：性能、錯誤檢測和異常行爲的檢測。對於容器，監控能夠幫助您檢測系統、容器和應用程序級別的問題。

順便說一下，這並不意味着您對容器監控的方法與您在傳統環境中使用的方法相同。如上所述，容器監控帶來了特殊的挑戰。可是，不管在哪一種狀況下，容器監控的好處其實都同樣。

實時容器監控和性能優化

監控容器性能最明顯的指標也許是那些涉及CPU和內存使用的指標。某個特定的容器（或者更典型的，組成特定微服務器的容器的多個或大多數實例）佔用過多的CPU時間？或過多內存？若是是這樣，那麼您就有機會經過查找和修復問題來優化性能。

如下是一些能夠經過實時監控來解決性能問題的具體策略。

CPU節流

僅僅經過執行CPU節流，就能夠解決一些CPU過分使用的問題。然而，在其餘狀況下，此類性能問題可能代表設計中存在問題(在總體應用或微服務級別)，或編碼錯誤。這些與性能相關的問題也可能出如今I/O甚至網絡指標中。

節流能夠起到相似於傳統負載均衡功能的做用，但當遇到與CPU相關的性能問題時，不要簡單地限制並假設可以解決問題，這一點很重要。若是某個關鍵服務使用過多的CPU時間，則扼制它可能會以其餘方式下降性能。

當CPU或內存問題或相似的性能問題頻發時，在設計級別上查找瓶頸和應用程序錯誤尤其重要，由於這些問題可能會致使內存、CPU服務或其餘資源使用不正確或效率低下。

資源調配

性能問題也可能源於系統級資源配置不足。您可能須要提供更多的內存，更多的存儲空間，更多的CPU訪問權限或切換到雲服務協定，從而使您在訪問資源時得到更高的優先級。

資源調配並非靈丹妙藥

與節流同樣，重要的是不要簡單地認爲應該提供更多的資源，並但願藉助它解決性能問題。您應該首先查看應用程序體系結構、微服務設計以及在編碼級別可能出現的功能問題。您不能經過簡單粗暴地提供更多資源，來解決設計問題或bug。以這種方式，也許您可以克服明顯且直接的效率低下方面的問題，但問題的其它方面可能會繼續隱匿乃至升級，在某一時刻形成更大的麻煩。

容器監控：錯誤和異常行爲

性能問題並非實時監控可以幫助您找到和解決的惟一問題。如下是其餘類型的問題（與成本優化\安全性和用戶體驗相關），在執行實時容器監控時也應該牢記。

未充分利用的資源

容器在低於預期水平的狀況下使用資源，可能會被視爲濫用資源。例如，信用卡受權微服務致使I/O或網絡資源幾乎被閒置，這多是重大問題的徵兆——不管是受權微服務自己，仍是使用一個或多個的微服務，或可能僅間接涉及信用受權的應用程序的其餘部分。

可疑流量

容器監控還可能發現其餘形式的異常行爲。若是容器正在訪問（或只是請求）一般不會使用的資源，或顯示I/O模式或網絡流量異常，則表示可能存在安全問題。

未知足的需求

容器的異常行爲也可能預示着不那麼嚴峻 (但仍然很重要) 的問題，如用戶活動的異常模式。例如，若是用戶（出於合法緣由）以比原來預期的更高級別訪問特定服務，那麼您可能須要查看總體架構、部署模式、或者添加新服務以知足當前未知足的（ 或不知足）用戶需求。

儘管單個容器更迭速度太快、存續時間可能不長，但關於容器生態系統的一切(基礎設施、存儲數據、用戶交互、資源可用性)卻持續煥發着強大的生命力，這些容易受到容器行爲的強烈影響，並可能會對您的應用程序性能和您的整個組織產生重大影響。所以，實時容器監控不只重要、並且必要。