Docker容器的自動化監控實現

近年來容器技術不斷成熟並得到應用。Docker作為容器技術的一個代表，目前也在快速發展中，基於 Docker的各種應用也正在普及，與此同時 Docker對傳統的運維體系也帶來了衝擊。我們在建設運維平台的過程中，也需要去面對和解決容器相關的問題。

Docker的運維是一個體系，而監控系統作為運維體系中重要組成部分，在 Docker運維過程中需要重點考慮。本文介紹了一種針對 Docker容器的自動化監控實現方法，旨在給 Docker運維體系的建立提供相關的解決方案。

容器

談到容器，有人首先會想到 LXC（Linux Container）。它是一種內核虛擬化技術，是一種操作系統層次上的資源的虛擬化。在 Docker出現之前，就已經有一些公司在使用 LXC技術。容器技術的使用，大大提升了資源利用率，降低了成本。

直接使用 LXC稍顯複雜，企業擁抱容器技術具有一定的門檻，可以說 Docker的出現改變了這一局面。Docker對容器底層的複雜技術做了一個封裝，大大降低了使用複雜性，從而降低了使用容器技術的門檻。Docker給出了一些基本的規範和介面，用戶只要熟悉 Docker的介面，就能夠輕鬆玩轉容器技術。可以說，Docker大大加快了容器技術的使用普及度，甚至被看做業界容器規範。

容器的監控

容器與通常的虛擬機在虛擬化程度上存在著差異，在監控手段上也有不同。一台虛擬機，我們可以當做一個物理機對待，而容器雖然也可以當做虛擬機，但這不符合容器的使用理念。在監控的實現過程中，我們更傾向於把容器看做是宿主機上的一系列進程樹。

主流的監控系統實現過程中，一般需要在目標機器上部署 agent模塊，通過 agent模塊來做數據採集。而根據容器的使用理念，一般不建議在容器鏡像裡面捆綁 agent。當然這並不意味著數據沒法採集，針對容器的虛擬化技術特點，在容器的宿主機上對容器進行數據採集是完全可行的，而且能夠做到更加高效。

當然，如果把容器當做虛擬機對待，上面部署上 agent模塊來採集監控數據，也是一種方法，但這不是推薦的做法。我們可以看到業界已經出現的一些 Docker監控方案，如 Docker Stats、CAdvisor、Scout等，也都是在宿主機上對容器進行監控的。本文提出的監控方案，也將會從宿主機上著手。

常見容器監控存在的問題

隨著 Docker的應用，業界也出現了很多的監控工具，這些工具實際上也都能對 Docker容器進行一些監控。利用這些工具搭建一套監控系統來使用，也是基本能夠解決一些需求的。但是分析這些監控工具，主要存在兩方面的問題。

1. 與運維體系的結合度

這些工具基本都是獨立的，很難與運維體系中其他系統整合打通。在運維自動化不斷發展的今天，往往更加註重的是整個體系的集成度。所以需要有一個更好的模型化的思路，便於系統間的數據打通。

2. 監控的層次

這些工具的監控一般都只停留在單個容器的層面，例如對容器的 CPU，磁碟 IO等的監控。而大多數應用設計架構都具備一定的節點容錯能力，單個節點的問題，往往不能夠反映出應用的真實問題。所以監控需要覆蓋到更多的層次。

模型化容器監控方案

這裡我們從整體上提出一種模型化監控方案。這一方案有利於和運維基礎的 CMDB系統打通，同時能兼顧到更多層次上的監控。

監控系統一般會涉及：數據採集、數據存儲、數據分析和報警、數據展示等幾個部分。本文將講述一種模型化監控方法，主要提出了以下五種模型：

1 監控對象模型

這裡我們將使用一種產品樹的結構來建模監控對象。把監控對象分為四類，分別是產品、應用、集群、節點。

○ 產品：一般是一個高層次的概念，一個產品一般可以獨立輸出，對外提供服務。

○ 應用：是產品下的模塊組成，多個應用共同形成一個產品。

○ 集群：是應用的存在形式。同一個應用，一般會根據環境，地域等，部署多個集群。

○ 節點：集群內承載服務的資源，包括前文提到的伺服器，虛擬機，容器等。

這樣，我們的監控數據採集，和視圖展示，就可以基於產品樹這個層次化的監控對象來做。每種監控對象上都可以有自定義的監控項，也可以繼承上層的監控項。同時，分層次的監控對象，在很好地組織監控結構的時候，又可以從多種層次角度來反映出系統的運行狀態和問題。

例如我們一個基於 Docker的應用需要監控，應用名稱為 myDocker。我們可以建立如下監控模型：

○ 產品：my_Docker_product

○ 應用：my_Docker_app

○ 集群：my_Docker_cluster

○ 節點：my_Docker_container

2 採集器模型

主要用於採集數據的模塊，同時滿足數據輸出規範，為了便於解析，同時具備較好的數據結構展示，我們可以採用 Json格式作為數據規範。在數據的語義上需要匹配對應的數據模型。例如針對節點模型的採集器，可以是一個腳本，通過捕獲腳本執行輸出來獲取相應數據模型的數據。而上層節點的採集器，則一般是基於節點數據模型的一些計算，這些計算一般包括 sum，avg，max，min等，一般反映的是整個集群下節點的一些聚合數據。

例如，一個簡單的採集器模型如下：

3 數據模型

用來定義監控數據格式，模型包括數據項和指標項。一個數據項一般包含一個或者多個指標項。數據模型中的數據來自於對應的採集器。

例如，針對 CPU可以監控如下模型：

數據項：cpu

指標項：usr,sys,idle

4 報警規則模型

在數據模型的基礎上，針對每個數據指標項目，可以設置報警模型。例如，空閑 CPU少於 50%的時候觸發報警，則可以建立如下規則：cpu.idle < 50

5 視圖模型

這個模型將數據模型和視圖關聯起來了。包含數據展示方式定義，例如可以是趨勢圖，表格等。可以結合數據模型中的數據項與指標項，描述具體數據指標的視圖展示方式。不同監控對象上的視圖，一般都能從不同層次體現出監控。

用 XML格式描述視圖模型如下：

這個模型表示 CPU趨勢圖，且根據 usr，sys兩個指標項畫圖。示例如下：

6 監控項模型

監控項模型，包含了採集器模型，數據模型，報警規則模型，視圖模型等的組合。通過將監控項運用於監控對象上。從而可以對監控對象進行自定義模型化的監控。

容器監控整體架構

在模型完備後，整個監控項需要解決監控項下發，數據採集，數據分析報警，存儲等問題。這裡我們介紹一種分散式監控框架來將整個模型串通起來。

框架圖示如下：

各模塊的基本功能簡要描述如下：

○ agent：節點監控數據採集

○ master：agent的管控中心，負責將監控項配置下發給agent。

○ monitor：接收agent採集的監控數據，並統一存放到Kafka消息隊列中。

○ analyser：訂閱Kafka對列消息，進行數據的分析處理，存儲和報警。（實際實現過程中，可以視情況對該模塊進行適度的功能擴展和模塊拆分）

○ web: 監控模型的各種管理，視圖的展示。

○ kafka: 消息隊列，緩存採集數據，共其他模塊訂閱使用。

○ DB/HBase：存儲模型配置，監控數據等。

這個架構是一個常見的監控模型架構，而且比較容易和運維體系打通。在我們實現容器監控的過程中，就可以採用這個模型。

容器監控數據採集

數據採集是 Docker監控和一般監控系統實現過程中最有差異的地方。因為在 Docker容器內部，沒有數據採集的 agent模塊將不能直接依賴 agent來採集。

1. 節點數據

在容器宿主機上，我們可以獲取到容器的很多基礎數據。一般有以下幾種方法。

通過 Docker命令

docker stats 這一方法比較簡單，但是數據並不全面，我們可以看到如下效果。

基於 Linux文件系統

這個是比較推薦，且性能較好的數據採集方法。Linux的 /proc，/sys等系統目錄下，記錄了非常有用的監控數據。在這裡，我們可以拿到大多數系統級，進程級別的運行數據，包括 CPU、磁碟 IO等。

例如我們要獲取某個進程的 CPU佔用，則可以採用以下方式計算出來。

2. 數據採集

集群的數據，是根據每個節點上的原始數據計算得到。是一種聚合運算，一般會有 sum，avg等運算場景。

3. 應用和產品數據

同理，應用和產品的數據則可以通過子節點的數據來計算得到。

監控的自動化

由於容器的自身特性，容器的銷毀，創建等是一個很常見的場景。一個容器啟動後，監控系統怎麼察覺，同時需要對其做哪些數據模型的採集，這些問題就是監控自動化過程需要解決的。

1. 容器的自發現

容器新創建，停止，或者銷毀，在宿主機上可以感知到。一般可以從如下目錄獲取。由於 Docker安裝配置不同，或者 Docker採用的文件系統的差異，可能部分目錄會有不一致，但實際獲取策略都類似。

2. 容器與監控對象的自動關聯

容器作為節點，是需要關聯到集群下面才能融入監控系統。這裡我們可以採用鏡像名稱與集群名稱的映射匹配來自動關聯容器到集群。

通過如下容器目錄下的配置文件，我們可以獲取到容器的詳情，其中包含的 Image即為容器所採用的鏡像名稱。

當容器關聯到集群後，則可以自動監控項配置。通過 master將配置下發到容器宿主機上的 agent後，則可以開始對容器進行數據採集和上報，從而對容器進行自動監控。

總結

本文提出了一種模型化容器監控方案。通過對監控對象、監控過程進行建模，基於模型來驅動整個監控場景，同時描述了該方案的主要實現方法。

這套方案相比現有的容器監控實現，具有更好的靈活性和擴展性。通過模型的改進和擴展，能夠方便地將 Docker容器的監控融入到現有的監控和運維體系中去。

監控系統本身是一個非常複雜的體系。本文描述的方案很多地方細節上還沒有充分展開，模型的建立上可能也有一些局限和考慮不周的地方，需要後續逐步完善。希望本文思路能給讀者在開發監控系統、建設運維體系的過程中提供一些參考。

推薦閱讀：