Docker容器的自動化監控實現

文章摘要

本文介紹了一種針對 Docker容器的自動化監控實現方法，旨在給 Docker運維體系的創建提供相關的解決方案。

2016年對於網易杭州研究院（如下簡稱「杭研」）而言是重要的，成立十週年之際，杭研正式推出了網易雲。「十年•杭研技術秀」系列文章，由杭研研發團隊傾情奉獻，爲您展現杭研那些有用、有趣的技術實踐經驗，涵蓋雲計算、大前端、信息安全、運維、QA、大數據、人工智能等領域，涉及前沿的分佈式、容器、深度學習等技術。正是這些寶貴的實踐經驗，造就了今天高品質的網易雲產品。今天的轉載來自網易杭州研究院運維團隊，提出了一種模型化容器監控方案，並描述了該方案的主要實現方法。
 
近年來容器技術不斷成熟並獲得應用。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容器的監控融入到現有的監控和運維體系中去。   監控系統自己是一個很是複雜的體系。本文描述的方案不少地方細節上尚未充分展開，模型的創建上可能也有一些侷限和考慮不周的地方，須要後續逐步完善。但願本文思路能給讀者在開發監控系統、建設運維體系的過程當中提供一些參考。