基于異常檢測Docker容器的監控系統研究

謝兆賢，倪冰雪，王若冰

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

0 引 言

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

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

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

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

1 背景知識

1.1 Docker容器基礎

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

1.2 Docker容器安全

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

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

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

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

1.3 監控組件框架

1.3.1 Prometheus+

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

1.3.2 Sysdig

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

1.3.3 Weave Scope

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

1.4 符號定義

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

表1 符號意義

2 監控系統

2.1 監控框架

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

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

圖1 監控系統架構

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

2.2 監控組件流程圖

2.2.1 Prometheus+流程

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

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

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

圖2 Prometheus+運行序列

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

算法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運行序列關系。首先，應用人員通過流程①啟動虛擬平臺，然后通過流程②向Docker Hub請求分別拉取sysdig鏡像，拉取成功后通過流程③中的docker run命令運行該鏡像，并設置privileged參數為true，該參數使容器內部的root可以完全掌握操作系統所有的權限。參數設置完成后，容器執行流程④掛載/var/run/docker.sock文件，該文件是Docker守護進程(Docker daemon)默認監聽的Unix域套接字(Unix domain socket)，容器中的進程可以通過流程⑧與Docker守護進程進行通信。

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

圖3 Sysdig運行序列

從Sysdig的序列圖，發展SysOPTime算法。由該算法，得到掛載和創建文件的總時間、監控異常情況的全部時間、sysdig監控異常的時間與生成可視化數據時間等。

算法2：SysOPTime。

輸入：n

輸出：T

1.Tbegin=clock();

2.Tpull=pull image in Docker Hub;

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

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

5.Trun=Tsysdig+Tcsysdig; //監控異常的時間與生成可視化數據時間之和

6.send csysdig to user;

7.Tfinish=clock();

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

9.return T

10.end

2.2.3 Weave Scope流程

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

圖4 Weave Scope運行序列

根據Weave Scope的運行序列，發展WScopeOPTime算法。此算法可以得到監控異常情況的全部時間、Weave scope運行時間與構建網頁時間之和以及該監控組件操作總時間。

算法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) ; //監控異常情況需要的總時間

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

5.send web to user;

6.Tfinish=clock();

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

8.return T

9.end

3 實驗結果與分析

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

3.1 實驗環境

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

3.2 實驗結果

3.2.1 CPU測試

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

圖5 監控組件的CPU使用情況

3.2.2 內存測試

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

(2)

圖6 監控組件的內存使用情況

3.2.3 網絡吞吐量測試

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

(3)

圖7 監控組件的網絡吞吐量

3.3 實驗分析

3.3.1 檢測異常分析

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

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

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

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

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

該文以檢出率和誤檢率評價異常檢測的結果。TP為被正確分類的異常數量，FN為未經識別的異常數量，FP為將正常判斷為異常的數量。

(4)

(5)

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

3.3.2 監控系統分析

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

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

4 結束語

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