您是否實時監控您的容器資源？如果沒有，那意味著您可能沒有對之進行有效監控。在快速變化的、動態的微服務環境中，即使是幾秒鐘以前的監視資料也可能不再可行。為了防止中斷，您需要實時監控。

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

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

實時容器監控面臨的挑戰

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

最明顯的是，在一個容器化的環境中，元件總是會消失。在傳統環境中，您監控的大多是相對靜態的伺服器和應用程式。但容器是不斷變化的。

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

由於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模式或網路流量異常，則表示可能存在安全問題。

未滿足的需求

容器的異常行為也可能預示著不那麼嚴峻 (但仍然很重要) 的問題，如使用者活動的異常模式。例如，如果使用者（出於合法原因）以比原來預期的更高級別訪問特定服務，那麼您可能需要檢視整體架構、部署模式、或者新增新服務以滿足當前未滿足的（ 或不滿足）使用者需求。

儘管單個容器更迭速度太快、存續時間可能不長，但關於容器生態系統的一切(基礎設施、儲存資料、使用者互動、資源可用性)卻持續煥發著強大的生命力，這些容易受到容器行為的強烈影響，並可能會對您的應用程式效能和您的整個組織產生重大影響。因此，實時容器監控不僅重要、而且必要。

9月27日，北京海航萬豪酒店，容器技術盛會Rancher Container Day 2017來了！
海航、華為、民生、恆豐、電信…中國典型的容器落地企業案例，都來了！
CIO、首席架構師、IT負責人…一眾真·雲端計算大咖，共奏容器落地最強音！
聚焦容器技術落地經驗，結合實戰場景，雲端計算領域行業領袖將全力助力您洞悉雲端先機！
報名請戳