基于異常檢測Docker容器的監(jiān)控系統(tǒng)研究

謝兆賢，倪冰雪，王若冰

(曲阜師范大學 網(wǎng)絡空間安全學院，山東 曲阜 273165)

0 引 言

Docker是一個重要的輕量級虛擬化技術(shù)，改變了傳統(tǒng)開發(fā)、測試和部署應用的模式。由于容器技術(shù)的主機內(nèi)核呈現(xiàn)“曝光式”，導致攻擊者可以直接對主機內(nèi)核發(fā)動惡意的攻擊[1]。所以，Docker所在宿主機以及容器本身安全性的問題，更顯得重要。在運維體系中，監(jiān)控是不可或缺的組成部分[2]。它不只是系統(tǒng)可靠性的基礎，也是系統(tǒng)穩(wěn)定運行和故障排除的關(guān)鍵[3]。在監(jiān)控的過程中，常見的四種監(jiān)控指標為CPU使用率、內(nèi)存使用率、磁盤讀寫速率和網(wǎng)絡速度。在現(xiàn)有的監(jiān)控系統(tǒng)中，主要通過檢測異常數(shù)據(jù)來保護容器的安全，異常檢測是指在數(shù)據(jù)中發(fā)現(xiàn)與預期行為不符的問題模式，這種不合格的模式包含所有不同應用領域中的異常情況。

目前，已知的三大類異常檢測的方法有無監(jiān)督異常監(jiān)測方法[4]、監(jiān)督式異常檢測方法和半監(jiān)督式異常檢測方法。監(jiān)控系統(tǒng)的異常檢測方法，在實際檢測的研究領域仍然存在不足。這是因為監(jiān)控系統(tǒng)的誤檢率和漏檢率，降低了異常檢測的精確度。所以，只要能夠降低誤檢率和漏檢率，便能夠保障容器的安全。

盡管現(xiàn)有的Docker容器可以使用的監(jiān)控工具種類繁多，仍然存在部署過程復雜、穩(wěn)定性差、資源消耗量大、管理過程繁瑣和只能監(jiān)控單一容器等問題。所以，監(jiān)控系統(tǒng)若是不能進行綜合監(jiān)控，則不能對Docker容器的所有節(jié)點實施監(jiān)控，更不能對系統(tǒng)中出現(xiàn)的故障進行提前預警。所以，針對以上存在的各項問題，該文開發(fā)了一個框架，對Prometheus+、Sysdig和Weave scope等方式進行組合，實現(xiàn)對Docker容器的全面監(jiān)控。

該文有以下三點貢獻：(1)進行Docker容器面臨的安全風險研究，發(fā)展監(jiān)控系統(tǒng)在運維層面保障容器安全的系統(tǒng)。(2)設置四個監(jiān)控指標，即可掌握系統(tǒng)的精確度。使用Prometheus+、Sysdig和Weave Scope三種監(jiān)控組件，根據(jù)CPU異常、內(nèi)存異常、磁盤異常和網(wǎng)絡異常等指標，監(jiān)控異常情況。(3)進行實驗，提供許多有價值的實驗結(jié)果與分析。

1 背景知識

1.1 Docker容器基礎

開源的Docker容器是一種基于LXC的高級容器引擎[5]，它利用REST技術(shù)管理Docker鏡像啟動的容器，支持新一代的云計算平臺[6]。同時，Docker主要由Docker Client、Docker Daemon和Docker Regeistry三個部分組成[7]。Docker Client是遠程控制器。Docker Daemon是一個后臺處理過程[8]。由計算機系統(tǒng)在Docker Service啟動時自動創(chuàng)建[7]，它會對客戶端的請求進行管理。Docker Regeistry是保存鏡像的倉庫。主要的任務是管理鏡像、處理客戶端請求、進行用戶認證和反饋請求的服務。

1.2 Docker容器安全

Docker的安全主要依賴namespace、cgroups和capability三種Linux內(nèi)核的安全機制[9]。這三種機制為Docker容器提供一個安全的工作環(huán)境，但是仍不能夠保障Docker容器完全安全。根據(jù)Docker容器三個常見的攻擊面，可以從網(wǎng)絡、容器和鏡像等三個方面討論面臨的安全問題[7]。

● Docker網(wǎng)絡安全風險。在容器輕量級的虛擬化網(wǎng)絡環(huán)境中，網(wǎng)絡面臨的安全問題更加復雜。Docker容器的網(wǎng)絡通信沒有細粒度的控制機制[10]，容器可以不加限制地訪問互聯(lián)網(wǎng)，容器在聯(lián)網(wǎng)時容易受到網(wǎng)絡攻擊[11]。由于沒有辦法對同一個宿主機內(nèi)各容器之間的網(wǎng)絡訪問權(quán)限進行限制，這就使攻擊者可以通過某個容器對宿主機內(nèi)的其他容器進行ARP欺騙、MAC泛洪攻擊等攻擊，進而帶來許多的安全問題。除此之外，Docker容器網(wǎng)絡也容易受到拒絕服務(DoS)的攻擊[12]，這個攻擊能夠降低其他容器的網(wǎng)絡數(shù)據(jù)處理能力，甚至占滿宿主機的網(wǎng)絡帶寬資源。

● Docker容器安全風險。由于Docker容器與宿主機共享操作系統(tǒng)的內(nèi)核[10]，僅靠namespace技術(shù)不能實現(xiàn)對系統(tǒng)資源的絕對隔離，因此存在容器與宿主機、容器與容器之間的進程隔離、文件系統(tǒng)隔離和進程間通信隔離等方面的安全風險。

● Docker容器鏡像風險。Docker Hub中的鏡像可以來自官方鏡像倉庫，也允許第三方組織和個人進行上傳。Docker鏡像的安全風險表現(xiàn)在創(chuàng)建的過程、獲取的來源或獲取的途徑等方面，開發(fā)者在構(gòu)建鏡像時可能會將一些敏感信息添加到鏡像中[8]，有可能導致Docker容器數(shù)據(jù)的信息外漏。

1.3 監(jiān)控組件框架

1.3.1 Prometheus+

Prometheus+的主要模塊有Prometheus Server、Service Discovery、Node_exporter和Grafana等。Prometheus Server主要用于抓取數(shù)據(jù)和存儲時序數(shù)據(jù)，另外還提供查詢和Alert Rule配置管理。Service Discovery自動把節(jié)點發(fā)現(xiàn)到Prometheus，不需要手動配置Prometheus.yml配置文件。Node_exporter用于客戶端數(shù)據(jù)收集，輸出被監(jiān)控組件信息的HTTP接口，主要負責收集數(shù)據(jù)并將信息匯報給Prometheus Server的組件。Grafana是一個跨平臺的度量分析和數(shù)據(jù)可視化工具，用于展示Node_exporter中收集的時序數(shù)據(jù)。在Grafana可視化界面上，明確顯示出被監(jiān)測的各項性能在特定時期的變化[13]。

1.3.2 Sysdig

Sysdig能夠分析Linux系統(tǒng)的“現(xiàn)場”狀態(tài)，將該狀態(tài)保存為轉(zhuǎn)儲文件以供離線分析檢查。通過Sysdig工具，用戶能夠很方便地查看到主機上所有應用程序的CPU、文件I/O、網(wǎng)絡訪問狀況。

1.3.3 Weave Scope

Weave Scope提供自上而下的應用程序視圖以及整個基礎架構(gòu)視圖，可以自動生成應用程序的映像，具有豐富的功能和友好的操作界面，可以實施多主機的監(jiān)控。它通過查看容器的上下文指標、標簽和元數(shù)據(jù)，在容器內(nèi)部的進程之間導航，以托管運行在可擴展、可排序表中的容器。

1.4 符號定義

文中涉及到的符號與意義，如表1所示。

表1 符號意義

2 監(jiān)控系統(tǒng)

2.1 監(jiān)控框架

Docker的運維是一個體系，而監(jiān)控在整個系統(tǒng)運維層面中的重要性是不能忽略的，監(jiān)控系統(tǒng)可以對整個系統(tǒng)的運行狀態(tài)進行實時展示，對系統(tǒng)中出現(xiàn)的故障進行提前預警與應急響應[14]，因此需要對Docker容器運行時的各項性能指標進行實時監(jiān)控。在監(jiān)控的實現(xiàn)過程中，一般把容器看作宿主機上的一系列進程樹。容器監(jiān)控系統(tǒng)的數(shù)據(jù)采集并不像主流的監(jiān)控系統(tǒng)的數(shù)據(jù)采集[6]，主流的監(jiān)控系統(tǒng)需要在目標機器上部署agent模塊，通過agent模塊來做數(shù)據(jù)采集，容器的監(jiān)控系統(tǒng)針對容器虛擬化的特點，一般在容器的宿主機上對容器進行數(shù)據(jù)采集。監(jiān)控的目的是監(jiān)測和記錄Docker容器各項性能的變化趨勢，對Docker進行有效的環(huán)境管理。監(jiān)控系統(tǒng)架構(gòu)如圖1所示。

agent用來對節(jié)點監(jiān)控的數(shù)據(jù)進行采集，由管控中心將監(jiān)控項配置下發(fā)給agent。通過web管理各種監(jiān)控模型和視圖的展示。然而，消息隊列是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，主要處理用戶在網(wǎng)站中的所有動作流數(shù)據(jù)，這些數(shù)據(jù)通常是由于吞吐量的要求而通過處理日志和日志聚合來解決。使用消息隊列的目的是通過Hadoop的并行加載機制統(tǒng)一線上和離線的消息處理，為了通過集群提供實時的消息。可以用analyser來訂閱消息隊列，對數(shù)據(jù)進行分析處理、存儲和報警。

圖1 監(jiān)控系統(tǒng)架構(gòu)

監(jiān)控服務器主要用來接收agent采集的監(jiān)控數(shù)據(jù)，并統(tǒng)一存放到消息隊列。主要由監(jiān)控代理、監(jiān)控數(shù)據(jù)存儲、異常檢測和異常分析四個部分組成。監(jiān)控代理模塊采用非侵入式的方式獲取容器的資源利用率，監(jiān)控數(shù)據(jù)存儲模塊負責接收來自各主機的監(jiān)控數(shù)據(jù)，它只能存儲最近一段時間的監(jiān)測數(shù)據(jù)，并將數(shù)據(jù)組織成指定的格式，發(fā)送給異常檢測模塊。異常檢測模塊通過基于iForest-based的異常評估方法檢測從監(jiān)控數(shù)據(jù)存儲模塊接收到的數(shù)據(jù)，并將容器異常信息發(fā)送給異常分析模塊。異常分析模塊首先從每個主機獲取異常容器的日志，然后對日志進行分析并定位異常原因。該監(jiān)控系統(tǒng)主要研究Prometheus+、Sysdig和Weave Scope三種監(jiān)控組件，采用該監(jiān)控系統(tǒng)可對多主機下的Docker容器進行監(jiān)控。

2.2 監(jiān)控組件流程圖

2.2.1 Prometheus+流程

圖2顯示Prometheus+運行序列關(guān)系。首先，應用人員通過流程①啟動虛擬平臺，然后通過流程②向Docker Hub請求分別拉取Prometheus、Node_exporter、Grafana鏡像，通過流程⑩返回拉取結(jié)果，拉取成功后通過流程③啟動Node-exporter，使用流程⑦返回啟動的容器ID；反之，拉取失敗返回錯誤信息。接下來使用流程④在網(wǎng)頁瀏覽器上訪問端口，并且查看該鏡像端口的連接狀態(tài)；若已經(jīng)建立連接，則通過流程⑧返回該鏡像收集到的數(shù)據(jù)；若連接失敗，則返回錯誤信息。

其次，執(zhí)行流程②創(chuàng)建prometheus的目錄和文件，創(chuàng)建成功后編輯配置文件，執(zhí)行流程⑤docker run命令啟動該鏡像，啟動成功后查看端口的連接狀態(tài)；若可以返回該鏡像的詳細信息，則證明已經(jīng)成功建立連接。若連接失敗則返回錯誤信息。

第三，通過流程②新建一個空文件夾grafana-storage，用來存儲數(shù)據(jù)和編輯該鏡像的配置文件。執(zhí)行流程⑥啟動該鏡像并設置它的端口，通過流程④使用瀏覽器添加數(shù)據(jù)源到訪問節(jié)點的端口，進行保存。保存成功后，通過流程⑨收集監(jiān)控數(shù)據(jù)，從流程返回收集到的信息。數(shù)據(jù)源配置成功后，物理機通過流程可查看Docker中容器資源的使用情況和性能特征。綜合以上，Prometheus+運行序列如圖2所示。

圖2 Prometheus+運行序列

根據(jù)Prometheus+運行序列，發(fā)展ProOPTime算法。經(jīng)由此算法，有效得出拉取全部鏡像的時間、監(jiān)控異常的全部時間、Prometheus+的運行時間以及監(jiān)控組件操作的總時間。

算法1：ProOPTime。

輸入：n,m

輸出：T

1.Tbegin=clock();

2.for i=1; i

3.Tpull+=Pi; //拉取全部鏡像時間

4.end for

5.Tprometheus=average(Tcpu)+average(Tnetwork)+ average(Tmemory)+average(Tdisk);

6.Trun=Tprometheus+Tweb;

7.send web to user;

8.Tfinish=clock();

9.T=Tpull+Trun; //全部時間

10.return T

11.end

2.2.2 Sysdig流程

圖3顯示Sysdig運行序列關(guān)系。首先，應用人員通過流程①啟動虛擬平臺，然后通過流程②向Docker Hub請求分別拉取sysdig鏡像，拉取成功后通過流程③中的docker run命令運行該鏡像，并設置privileged參數(shù)為true，該參數(shù)使容器內(nèi)部的root可以完全掌握操作系統(tǒng)所有的權(quán)限。參數(shù)設置完成后，容器執(zhí)行流程④掛載/var/run/docker.sock文件，該文件是Docker守護進程(Docker daemon)默認監(jiān)聽的Unix域套接字(Unix domain socket)，容器中的進程可以通過流程⑧與Docker守護進程進行通信。

然后，使用流程⑤分別在/dev、/proc、/boot、/usr和/lib/modules目錄下創(chuàng)建dev文件、proc:ro可讀文件、boot:ro可讀文件、usr:ro可讀文件和modules:ro可讀文件。文件創(chuàng)建成功后通過流程⑨返回創(chuàng)建信息，并通過流程⑥收集監(jiān)控數(shù)據(jù)，收集到的數(shù)據(jù)通過流程傳送給虛擬平臺。最后，在流程⑦中運行csysdig命令，啟動該監(jiān)控工具的可視化界面，查看各項監(jiān)控數(shù)據(jù)。Sysdig運行序列如圖3所示。

圖3 Sysdig運行序列

從Sysdig的序列圖，發(fā)展SysOPTime算法。由該算法，得到掛載和創(chuàng)建文件的總時間、監(jiān)控異常情況的全部時間、sysdig監(jiān)控異常的時間與生成可視化數(shù)據(jù)時間等。

算法2：SysOPTime。

輸入：n

輸出：T

1.Tbegin=clock();

2.Tpull=pull image in Docker Hub;

3.Tfile=Tmfile+Tcfile; //掛載文件和創(chuàng)建文件的總時間

4.Tsysdig=average(Tcpu)+average(Tnetwork) +average(Tmemory)+average(Tdisk) ; //監(jiān)控異常情況需要的總時間

5.Trun=Tsysdig+Tcsysdig; //監(jiān)控異常的時間與生成可視化數(shù)據(jù)時間之和

6.send csysdig to user;

7.Tfinish=clock();

8.T=Tpull+Tfile+Trun; //全部時間

9.return T

10.end

2.2.3 Weave Scope流程

圖4顯示W(wǎng)eave Scope運行序列關(guān)系。顯示應用人員通過流程①啟動虛擬平臺，然后通過流程②向Docker Hub請求拉取scope鏡像，結(jié)果由流程⑩反饋給虛擬平臺。拉取失敗則返回錯誤信息；拉取成功則通過流程③啟動該容器，同時流程⑨返回該容器ID。容器啟動成功后，由流程④通過curl -L https://github.com/weaveworks/scope/releases/download/late-st_release/scope -o /usr/local/bin/scope命令，通過流程⑤跟隨web服務器重定向，完成后使用流程⑦在命令行輸出服務器返回的內(nèi)容。所以，curl請求web服務器成功后，使用chmod a+x命令對所有用戶開啟執(zhí)行/usr/local/bin/scope文件的權(quán)限。最后，重新啟動scope容器，將流程⑥收集到的監(jiān)控數(shù)據(jù)，通過流程返回給虛擬平臺。然后，通過流程查看監(jiān)控的結(jié)果。

圖4 Weave Scope運行序列

根據(jù)Weave Scope的運行序列，發(fā)展WScopeOPTime算法。此算法可以得到監(jiān)控異常情況的全部時間、Weave scope運行時間與構(gòu)建網(wǎng)頁時間之和以及該監(jiān)控組件操作總時間。

算法3：WScopeOPTime。

輸入：n

輸出：T

1.Tbegin=clock();

2.Tpull=pull image in Docker Hub;

3.Tweave scope=average(Tcpu)+average(Tnetwork)+

average(Tmemory)+average(Tdisk) ; //監(jiān)控異常情況需要的總時間

4.Trun=Tweave scope+Tweb; //運行時間

5.send web to user;

6.Tfinish=clock();

7.T=Tpull+Trun; //總時間

8.return T

9.end

3 實驗結(jié)果與分析

本次實驗在Linux環(huán)境下搭建部署Docker，并且安裝和部署Prometheus+、Sysdig、Weave Scope三種監(jiān)控組件。在三種監(jiān)控組件監(jiān)控Docker容器的過程中使用cAdvisor進行測試，測試三種監(jiān)控組件在監(jiān)控Docker容器各項性能時，它們的CPU占有情況、內(nèi)存使用情況以及網(wǎng)絡吞吐量的差別，分析其在監(jiān)控Docker容器各項性能指標時監(jiān)控組件對資源的使用情況，得出其在工作過程中各自的優(yōu)勢和差別。并對三種監(jiān)控組件的監(jiān)控功能的完善性度量進行性能分析。其次，通過給容器設置異常，來進行對比實驗。由于沒有容器異常注入的標準，將異常分為CPU、內(nèi)存、磁盤和網(wǎng)絡四個涉及不同資源度量的常見類別。異常主要表現(xiàn)為CPU無限循環(huán)使用、內(nèi)存泄漏和內(nèi)存溢出、磁盤調(diào)度不當和網(wǎng)絡攻擊等現(xiàn)象。

3.1 實驗環(huán)境

實驗環(huán)境分成物理機和虛擬機兩類，各自包含硬件與軟件的配置。物理機硬件的配置為處理器Intel(R) Core(TM)i7-9750H CPU @ 2.60 GHz 2.59 GHz，內(nèi)存為8.00 GB；軟件的配置為Windows 10，64-bit X86系統(tǒng)，VMware Workstation Pro的12.5版本。虛擬機內(nèi)的硬件配置為2個處理器，硬盤為20 GB，網(wǎng)絡適配器為橋接模式，存在USB控制器；軟件配置為Ubuntu16.04 內(nèi)存為1 GB，Docker為20.10版本。

3.2 實驗結(jié)果

3.2.1 CPU測試

圖5(a)、(b)和(c)分別顯示Prometheus+、Sysdig和Weave Scope運行過程的CPU使用量。這三種監(jiān)控組件在監(jiān)控Docker容器時，CPU的使用量波動幅度都比較大。其中，Prometheus+的波動最大，介于0.1核心與0.7核心之間，Sysdig的CPU使用量波動比較小，介于0.1核心與0.3核心之間。依據(jù)式(1)得出，Prometheus+、Sysdig、Weave Scope三種監(jiān)控組件的平均CPU使用率分別為20.9%、8.25%和15.1%。Prometheus+不僅波動幅度較大，而且CPU使用率最高，資源消耗最多。內(nèi)核數(shù)(cores)顯示為使用的CPU總核數(shù)，在本次實驗中虛擬機使用的CPU總核數(shù)為2核心。監(jiān)控組件在監(jiān)控Docker容器的過程，CPU性能測試的結(jié)果，如圖5所示。

圖5 監(jiān)控組件的CPU使用情況

3.2.2 內(nèi)存測試

圖6顯示內(nèi)存測試的結(jié)果，觀察各種監(jiān)控組件的內(nèi)存使用量。圖6(a)、(b)和(c)分別顯示Prometheus+、Sysdig和Weave Scope運行過程的內(nèi)存使用量。在監(jiān)控Docker容器時Prometheus+和Sysdig波動較小，幾乎不變。Weave Scope與它們相比較波動較大，波動范圍在140 Mb與185 Mb之間。依據(jù)式(2)得出，Prometheus+、Sysdig、Weave Scope三種監(jiān)控組件的平均內(nèi)存使用量分別為168.4 Mb、90 Mb和164.7 Mb。由此可知，Prometheus+與Weave Scope兩者內(nèi)存的使用量大致相等，Sysdig的內(nèi)存使用量最少，比Prometheus+少使用78.1 Mb的內(nèi)存，比Weave Scope少使用74.4 Mb的內(nèi)存。

(2)

圖6 監(jiān)控組件的內(nèi)存使用情況

3.2.3 網(wǎng)絡吞吐量測試

圖7為吞吐量的測試分析圖，顯示各種監(jiān)控組件的網(wǎng)絡吞吐量。圖7(a)、(b)和(c)分別顯示Prometheus+、Sysdig和Weave Scope運行過程的網(wǎng)絡吞吐量。由此可知，三種監(jiān)控組件在監(jiān)控Docker容器時，網(wǎng)絡吞吐量波動幅度都比較大，其中Prometheus+波動較大，波動幅度介于3.2 Mbps與9.2 Mbps之間，Sysdig與Weave Scope波動幅度大致相等。依據(jù)式(3)可得出，Prometheus+、Sysdig、Weave Scope三種監(jiān)控組件的平均網(wǎng)絡吞吐量分別為7.05 Mbps、5.1 Mbps和5.3 Mbps。Prometheus+網(wǎng)絡吞吐量最大，數(shù)據(jù)傳輸效率最快，而Sysdig網(wǎng)絡吞吐量最少。

(3)

圖7 監(jiān)控組件的網(wǎng)絡吞吐量

3.3 實驗分析

3.3.1 檢測異常分析

四種模擬Docker容器面臨的異常情況，說明如下:

● CPU無限循環(huán)使用。通過插入額外的代碼來調(diào)用壓力工具[11]，在應用程序中注入這個錯誤代碼，程序由于異常進入無限循環(huán)模式，這可以模擬CPU中的無限循環(huán)，并占用100%的CPU利用率。

●內(nèi)存泄漏。注入的代碼在不釋放對象的情況下分配堆內(nèi)存，這會逐漸占用100%的內(nèi)存利用率。

●磁盤輸入/輸出故障。使用可以產(chǎn)生很多線程或進程并執(zhí)行用戶指定的特定類型I/O操作的FIO，注入額外的磁盤讀寫操作，模擬磁盤I/O故障[15]。

●網(wǎng)絡擁塞。通過使用wondershaper來限制指定網(wǎng)絡接口的帶寬，從而模擬網(wǎng)絡擁塞。

該文以檢出率和誤檢率評價異常檢測的結(jié)果。TP為被正確分類的異常數(shù)量，F(xiàn)N為未經(jīng)識別的異常數(shù)量，F(xiàn)P為將正常判斷為異常的數(shù)量。

(4)

(5)

設計四種異常實驗，明確監(jiān)控組件對異常的檢測精確度，并且使用各種監(jiān)控組件對上述四種典型的異常進行測試。通過實驗可知，Sysdig在異常檢測方面誤檢率低于其他監(jiān)控組件，這是因為它的資源度量在正常負載下非常穩(wěn)定。當出現(xiàn)異常時，監(jiān)測數(shù)據(jù)的異常值變化很大，因此它可以更加準確地檢測異常，具有較高的檢測精確度。Prometheus+的資源度量在正常負載下波動不小，有時連續(xù)波動會導致異常值上升超過異常檢測閾值，導致錯誤檢出。在磁盤輸入輸出故障注入的情況下，Weave Scope的檢測率明顯低于Prometheus+，這是因為異常磁盤讀寫速率與波動較小的正常磁盤讀寫速率相差不大。因此，監(jiān)測數(shù)據(jù)的局部密度變化很小，Weave Scope的異常檢出率很低。

3.3.2 監(jiān)控系統(tǒng)分析

綜上所述，在運行Prometheus+時，CPU的利用率、內(nèi)存的使用量和網(wǎng)絡的吞吐量，都要高于Sysdig和Weave Scope。相較于Prometheus+和Weave Scope，Sysdig安裝步驟較為簡便，安裝一次即可永久部署監(jiān)控系統(tǒng)。此外，在監(jiān)控的過程中，Sysdig的CPU使用量、內(nèi)存使用量和網(wǎng)絡吞吐量的使用量都是最少的。由于此工具在可視化界面上顯示的是實時數(shù)據(jù)，缺點是無法查看容器各項性能指標的變化和趨勢。同時，只能以命令行進行操作，相比于Prometheus+增加用戶操作的復雜性。

對比于Prometheus+和Sysdig，Weave Scope能夠?qū)Χ鄠€容器或主機進行監(jiān)控，通過生成容器地圖看到各個容器之間的關(guān)系和顯示請求公網(wǎng)的行為。同時，能夠分別根據(jù)Docker容器中各個進程和鏡像的各項性能指標，查看當前時刻的CPU使用量、內(nèi)存使用率、網(wǎng)絡吞吐量以及文件使用情況等各項性能指標，缺點是無法知道Docker容器在不同時間各項性能指標的變化情況。

4 結(jié)束語

將Prometheus+、Sysdig和Weave Scope組件構(gòu)成監(jiān)控系統(tǒng)，并對其進行性能測試，得出各項資源隨時間變化的關(guān)系曲線。其次，根據(jù)監(jiān)控數(shù)據(jù)的特點，構(gòu)建四種容器異常，包含CPU異常、內(nèi)存異常、磁盤異常以及網(wǎng)絡異常等，對監(jiān)控系統(tǒng)的異常檢測精確度進行驗證。實驗結(jié)果發(fā)現(xiàn)，Weave Scope可以監(jiān)控多個容器。Prometheus+對資源需求的依賴比較高，優(yōu)點是它可以長期存儲監(jiān)測的數(shù)據(jù)，并且生成警告機制。Weave Scope和Sysdig一樣，對資源的需求比較少，缺點是只能顯示實時數(shù)據(jù)。未來的監(jiān)控系統(tǒng)應該朝向部署容易，同時對多個主機和容器進行監(jiān)控。當受到外界攻擊或自身發(fā)生錯誤時，能夠自動生成警報機制。