本文由? 網(wǎng)易云 發(fā)布。

?

近年來容器技術(shù)不斷成熟并得到應(yīng)用。Docker作為容器技術(shù)的一個(gè)代表，目前也在快速發(fā)展中，基于 Docker的各種應(yīng)用也正在普及，與此同時(shí) Docker對(duì)傳統(tǒng)的運(yùn)維體系也帶來了沖擊。我們?cè)诮ㄔO(shè)運(yùn)維平臺(tái)的過程中，也需要去面對(duì)和解決容器相關(guān)的問題。

Docker的運(yùn)維是一個(gè)體系，而監(jiān)控系統(tǒng)作為運(yùn)維體系中重要組成部分，在 Docker運(yùn)維過程中需要重點(diǎn)考慮。本文介紹了一種針對(duì) Docker容器的自動(dòng)化監(jiān)控實(shí)現(xiàn)方法，旨在給 Docker運(yùn)維體系的建立提供相關(guān)的解決方案。

容器

談到容器，有人首先會(huì)想到 LXC（Linux Container）。它是一種內(nèi)核虛擬化技術(shù)，是一種操作系統(tǒng)層次上的資源的虛擬化。在 Docker出現(xiàn)之前，就已經(jīng)有一些公司在使用 LXC技術(shù)。容器技術(shù)的使用，大大提升了資源利用率，降低了成本。

直接使用 LXC稍顯復(fù)雜，企業(yè)擁抱容器技術(shù)具有一定的門檻，可以說 Docker的出現(xiàn)改變了這一局面。Docker對(duì)容器底層的復(fù)雜技術(shù)做了一個(gè)封裝，大大降低了使用復(fù)雜性，從而降低了使用容器技術(shù)的門檻。Docker給出了一些基本的規(guī)范和接口，用戶只要熟悉 Docker的接口，就能夠輕松玩轉(zhuǎn)容器技術(shù)。可以說，Docker大大加快了容器技術(shù)的使用普及度，甚至被看做業(yè)界容器規(guī)范。

容器的監(jiān)控

容器與通常的虛擬機(jī)在虛擬化程度上存在著差異，在監(jiān)控手段上也有不同。一臺(tái)虛擬機(jī)，我們可以當(dāng)做一個(gè)物理機(jī)對(duì)待，而容器雖然也可以當(dāng)做虛擬機(jī)，但這不符合容器的使用理念。在監(jiān)控的實(shí)現(xiàn)過程中，我們更傾向于把容器看做是宿主機(jī)上的一系列進(jìn)程樹。

主流的監(jiān)控系統(tǒng)實(shí)現(xiàn)過程中，一般需要在目標(biāo)機(jī)器上部署 agent模塊，通過 agent模塊來做數(shù)據(jù)采集。而根據(jù)容器的使用理念，一般不建議在容器鏡像里面捆綁 agent。當(dāng)然這并不意味著數(shù)據(jù)沒法采集，針對(duì)容器的虛擬化技術(shù)特點(diǎn)，在容器的宿主機(jī)上對(duì)容器進(jìn)行數(shù)據(jù)采集是完全可行的，而且能夠做到更加高效。

當(dāng)然，如果把容器當(dāng)做虛擬機(jī)對(duì)待，上面部署上 agent模塊來采集監(jiān)控?cái)?shù)據(jù)，也是一種方法，但這不是推薦的做法。我們可以看到業(yè)界已經(jīng)出現(xiàn)的一些 Docker監(jiān)控方案，如 Docker Stats、CAdvisor、Scout等，也都是在宿主機(jī)上對(duì)容器進(jìn)行監(jiān)控的。本文提出的監(jiān)控方案，也將會(huì)從宿主機(jī)上著手。

?

常見容器監(jiān)控存在的問題

隨著 Docker的應(yīng)用，業(yè)界也出現(xiàn)了很多的監(jiān)控工具，這些工具實(shí)際上也都能對(duì) Docker容器進(jìn)行一些監(jiān)控。利用這些工具搭建一套監(jiān)控系統(tǒng)來使用，也是基本能夠解決一些需求的。但是分析這些監(jiān)控工具，主要存在兩方面的問題。

1. 與運(yùn)維體系的結(jié)合度

這些工具基本都是獨(dú)立的，很難與運(yùn)維體系中其他系統(tǒng)整合打通。在運(yùn)維自動(dòng)化不斷發(fā)展的今天，往往更加注重的是整個(gè)體系的集成度。所以需要有一個(gè)更好的模型化的思路，便于系統(tǒng)間的數(shù)據(jù)打通。

2. 監(jiān)控的層次

這些工具的監(jiān)控一般都只停留在單個(gè)容器的層面，例如對(duì)容器的 CPU，磁盤 IO等的監(jiān)控。而大多數(shù)應(yīng)用設(shè)計(jì)架構(gòu)都具備一定的節(jié)點(diǎn)容錯(cuò)能力，單個(gè)節(jié)點(diǎn)的問題，往往不能夠反映出應(yīng)用的真實(shí)問題。所以監(jiān)控需要覆蓋到更多的層次。

模型化容器監(jiān)控方案

這里我們從整體上提出一種模型化監(jiān)控方案。這一方案有利于和運(yùn)維基礎(chǔ)的 CMDB系統(tǒng)打通，同時(shí)能兼顧到更多層次上的監(jiān)控。

監(jiān)控系統(tǒng)一般會(huì)涉及：數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)分析和報(bào)警、數(shù)據(jù)展示等幾個(gè)部分。本文將講述一種模型化監(jiān)控方法，主要提出了以下五種模型：

1 監(jiān)控對(duì)象模型

這里我們將使用一種產(chǎn)品樹的結(jié)構(gòu)來建模監(jiān)控對(duì)象。把監(jiān)控對(duì)象分為四類，分別是產(chǎn)品、應(yīng)用、集群、節(jié)點(diǎn)。

○ 產(chǎn)品：一般是一個(gè)高層次的概念，一個(gè)產(chǎn)品一般可以獨(dú)立輸出，對(duì)外提供服務(wù)。
○ 應(yīng)用：是產(chǎn)品下的模塊組成，多個(gè)應(yīng)用共同形成一個(gè)產(chǎn)品。
○ 集群：是應(yīng)用的存在形式。同一個(gè)應(yīng)用，一般會(huì)根據(jù)環(huán)境，地域等，部署多個(gè)集群。
○ 節(jié)點(diǎn)：集群內(nèi)承載服務(wù)的資源，包括前文提到的服務(wù)器，虛擬機(jī)，容器等。

?

這樣，我們的監(jiān)控?cái)?shù)據(jù)采集，和視圖展示，就可以基于產(chǎn)品樹這個(gè)層次化的監(jiān)控對(duì)象來做。每種監(jiān)控對(duì)象上都可以有自定義的監(jiān)控項(xiàng)，也可以繼承上層的監(jiān)控項(xiàng)。同時(shí)，分層次的監(jiān)控對(duì)象，在很好地組織監(jiān)控結(jié)構(gòu)的時(shí)候，又可以從多種層次角度來反映出系統(tǒng)的運(yùn)行狀態(tài)和問題。

例如我們一個(gè)基于 Docker的應(yīng)用需要監(jiān)控，應(yīng)用名稱為 myDocker。我們可以建立如下監(jiān)控模型：

○ 產(chǎn)品：my_Docker_product
○ 應(yīng)用：my_Docker_app
○ 集群：my_Docker_cluster
○ 節(jié)點(diǎn)：my_Docker_container

2 采集器模型

主要用于采集數(shù)據(jù)的模塊，同時(shí)滿足數(shù)據(jù)輸出規(guī)范，為了便于解析，同時(shí)具備較好的數(shù)據(jù)結(jié)構(gòu)展示，我們可以采用 Json格式作為數(shù)據(jù)規(guī)范。在數(shù)據(jù)的語義上需要匹配對(duì)應(yīng)的數(shù)據(jù)模型。例如針對(duì)節(jié)點(diǎn)模型的采集器，可以是一個(gè)腳本，通過捕獲腳本執(zhí)行輸出來獲取相應(yīng)數(shù)據(jù)模型的數(shù)據(jù)。而上層節(jié)點(diǎn)的采集器，則一般是基于節(jié)點(diǎn)數(shù)據(jù)模型的一些計(jì)算，這些計(jì)算一般包括 sum，avg，max，min等，一般反映的是整個(gè)集群下節(jié)點(diǎn)的一些聚合數(shù)據(jù)。

例如，一個(gè)簡單的采集器模型如下：

?

3 數(shù)據(jù)模型

用來定義監(jiān)控?cái)?shù)據(jù)格式，模型包括數(shù)據(jù)項(xiàng)和指標(biāo)項(xiàng)。一個(gè)數(shù)據(jù)項(xiàng)一般包含一個(gè)或者多個(gè)指標(biāo)項(xiàng)。數(shù)據(jù)模型中的數(shù)據(jù)來自于對(duì)應(yīng)的采集器。

?

例如，針對(duì) CPU可以監(jiān)控如下模型：
數(shù)據(jù)項(xiàng)：cpu
指標(biāo)項(xiàng)：usr,sys,idle

4 報(bào)警規(guī)則模型

在數(shù)據(jù)模型的基礎(chǔ)上，針對(duì)每個(gè)數(shù)據(jù)指標(biāo)項(xiàng)目，可以設(shè)置報(bào)警模型。例如，空閑 CPU少于 50%的時(shí)候觸發(fā)報(bào)警，則可以建立如下規(guī)則：cpu.idle < 50?

5 視圖模型

這個(gè)模型將數(shù)據(jù)模型和視圖關(guān)聯(lián)起來了。包含數(shù)據(jù)展示方式定義，例如可以是趨勢(shì)圖，表格等。可以結(jié)合數(shù)據(jù)模型中的數(shù)據(jù)項(xiàng)與指標(biāo)項(xiàng)，描述具體數(shù)據(jù)指標(biāo)的視圖展示方式。不同監(jiān)控對(duì)象上的視圖，一般都能從不同層次體現(xiàn)出監(jiān)控。

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

這個(gè)模型表示 CPU趨勢(shì)圖，且根據(jù) usr，sys兩個(gè)指標(biāo)項(xiàng)畫圖。示例如下：

?

6 監(jiān)控項(xiàng)模型

監(jiān)控項(xiàng)模型，包含了采集器模型，數(shù)據(jù)模型，報(bào)警規(guī)則模型，視圖模型等的組合。通過將監(jiān)控項(xiàng)運(yùn)用于監(jiān)控對(duì)象上。從而可以對(duì)監(jiān)控對(duì)象進(jìn)行自定義模型化的監(jiān)控。

容器監(jiān)控整體架構(gòu)

在模型完備后，整個(gè)監(jiān)控項(xiàng)需要解決監(jiān)控項(xiàng)下發(fā)，數(shù)據(jù)采集，數(shù)據(jù)分析報(bào)警，存儲(chǔ)等問題。這里我們介紹一種分布式監(jiān)控框架來將整個(gè)模型串通起來。

框架圖示如下：

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

○ agent：節(jié)點(diǎn)監(jiān)控?cái)?shù)據(jù)采集
○ master：agent的管控中心，負(fù)責(zé)將監(jiān)控項(xiàng)配置下發(fā)給agent。
○ monitor：接收agent采集的監(jiān)控?cái)?shù)據(jù)，并統(tǒng)一存放到Kafka消息隊(duì)列中。
○ analyser：訂閱Kafka對(duì)列消息，進(jìn)行數(shù)據(jù)的分析處理，存儲(chǔ)和報(bào)警。（實(shí)際實(shí)現(xiàn)過程中，可以視情況對(duì)該模塊進(jìn)行適度的功能擴(kuò)展和模塊拆分）
○ web: 監(jiān)控模型的各種管理，視圖的展示。
○ kafka: 消息隊(duì)列，緩存采集數(shù)據(jù)，共其他模塊訂閱使用。
○ DB/HBase：存儲(chǔ)模型配置，監(jiān)控?cái)?shù)據(jù)等。

這個(gè)架構(gòu)是一個(gè)常見的監(jiān)控模型架構(gòu)，而且比較容易和運(yùn)維體系打通。在我們實(shí)現(xiàn)容器監(jiān)控的過程中，就可以采用這個(gè)模型。

容器監(jiān)控?cái)?shù)據(jù)采集

數(shù)據(jù)采集是 Docker監(jiān)控和一般監(jiān)控系統(tǒng)實(shí)現(xiàn)過程中最有差異的地方。因?yàn)樵?Docker容器內(nèi)部，沒有數(shù)據(jù)采集的 agent模塊將不能直接依賴 agent來采集。

1. 節(jié)點(diǎn)數(shù)據(jù)

在容器宿主機(jī)上，我們可以獲取到容器的很多基礎(chǔ)數(shù)據(jù)。一般有以下幾種方法。

通過 Docker命令

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

?

基于 Linux文件系統(tǒng)

這個(gè)是比較推薦，且性能較好的數(shù)據(jù)采集方法。Linux的 /proc，/sys等系統(tǒng)目錄下，記錄了非常有用的監(jiān)控?cái)?shù)據(jù)。在這里，我們可以拿到大多數(shù)系統(tǒng)級(jí)，進(jìn)程級(jí)別的運(yùn)行數(shù)據(jù)，包括 CPU、磁盤 IO等。

例如我們要獲取某個(gè)進(jìn)程的 CPU占用，則可以采用以下方式計(jì)算出來。

?

2. 數(shù)據(jù)采集

集群的數(shù)據(jù)，是根據(jù)每個(gè)節(jié)點(diǎn)上的原始數(shù)據(jù)計(jì)算得到。是一種聚合運(yùn)算，一般會(huì)有 sum，avg等運(yùn)算場景。

3. 應(yīng)用和產(chǎn)品數(shù)據(jù)

同理，應(yīng)用和產(chǎn)品的數(shù)據(jù)則可以通過子節(jié)點(diǎn)的數(shù)據(jù)來計(jì)算得到。

監(jiān)控的自動(dòng)化

由于容器的自身特性，容器的銷毀，創(chuàng)建等是一個(gè)很常見的場景。一個(gè)容器啟動(dòng)后，監(jiān)控系統(tǒng)怎么察覺，同時(shí)需要對(duì)其做哪些數(shù)據(jù)模型的采集，這些問題就是監(jiān)控自動(dòng)化過程需要解決的。

1. 容器的自發(fā)現(xiàn)

容器新創(chuàng)建，停止，或者銷毀，在宿主機(jī)上可以感知到。一般可以從如下目錄獲取。由于 Docker安裝配置不同，或者 Docker采用的文件系統(tǒng)的差異，可能部分目錄會(huì)有不一致，但實(shí)際獲取策略都類似。

?

2. 容器與監(jiān)控對(duì)象的自動(dòng)關(guān)聯(lián)

容器作為節(jié)點(diǎn)，是需要關(guān)聯(lián)到集群下面才能融入監(jiān)控系統(tǒng)。這里我們可以采用鏡像名稱與集群名稱的映射匹配來自動(dòng)關(guān)聯(lián)容器到集群。

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

當(dāng)容器關(guān)聯(lián)到集群后，則可以自動(dòng)監(jiān)控項(xiàng)配置。通過 master將配置下發(fā)到容器宿主機(jī)上的 agent后，則可以開始對(duì)容器進(jìn)行數(shù)據(jù)采集和上報(bào)，從而對(duì)容器進(jìn)行自動(dòng)監(jiān)控。

總結(jié)

本文提出了一種模型化容器監(jiān)控方案。通過對(duì)監(jiān)控對(duì)象、監(jiān)控過程進(jìn)行建模，基于模型來驅(qū)動(dòng)整個(gè)監(jiān)控場景，同時(shí)描述了該方案的主要實(shí)現(xiàn)方法。

這套方案相比現(xiàn)有的容器監(jiān)控實(shí)現(xiàn)，具有更好的靈活性和擴(kuò)展性。通過模型的改進(jìn)和擴(kuò)展，能夠方便地將 Docker容器的監(jiān)控融入到現(xiàn)有的監(jiān)控和運(yùn)維體系中去。

監(jiān)控系統(tǒng)本身是一個(gè)非常復(fù)雜的體系。本文描述的方案很多地方細(xì)節(jié)上還沒有充分展開，模型的建立上可能也有一些局限和考慮不周的地方，需要后續(xù)逐步完善。希望本文思路能給讀者在開發(fā)監(jiān)控系統(tǒng)、建設(shè)運(yùn)維體系的過程中提供一些參考。

?

?

了解 網(wǎng)易云 ：
網(wǎng)易云官網(wǎng)：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網(wǎng)易云社區(qū)：https://sq.163yun.com/

?

轉(zhuǎn)載于:https://www.cnblogs.com/163yun/p/8890981.html

總結(jié)

以上是生活随笔為你收集整理的Docker容器的自动化监控实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。