溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“Docker容器的自動化監控實現方法”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“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容器進行一些監控。利用這些工具搭建一套監控系統來使用，也是基本能夠解決一些需求的。但是分析這些監控工具，主要存在兩方面的問題。
這些工具基本都是獨立的，很難與運維體系中其他系統整合打通。在運維自動化不斷發展的今天，往往更加注重的是整個體系的集成度。所以需要有一個更好的模型化的思路，便于系統間的數據打通。
這些工具的監控一般都只停留在單個容器的層面，例如對容器的 CPU，磁盤 IO等的監控。而大多數應用設計架構都具備一定的節點容錯能力，單個節點的問題，往往不能夠反映出應用的真實問題。所以監控需要覆蓋到更多的層次。
這里我們從整體上提出一種模型化監控方案。這一方案有利于和運維基礎的 CMDB系統打通，同時能兼顧到更多層次上的監控。
監控系統一般會涉及：數據采集、數據存儲、數據分析和報警、數據展示等幾個部分。本文將講述一種模型化監控方法，主要提出了以下五種模型：
這里我們將使用一種產品樹的結構來建模監控對象。把監控對象分為四類，分別是產品、應用、集群、節點。
○ 產品：一般是一個高層次的概念，一個產品一般可以獨立輸出，對外提供服務。
○ 應用：是產品下的模塊組成，多個應用共同形成一個產品。
○ 集群：是應用的存在形式。同一個應用，一般會根據環境，地域等，部署多個集群。
○ 節點：集群內承載服務的資源，包括前文提到的服務器，虛擬機，容器等。
用來定義監控數據格式，模型包括數據項和指標項。一個數據項一般包含一個或者多個指標項。數據模型中的數據來自于對應的采集器。
這個模型表示 CPU趨勢圖，且根據 usr，sys兩個指標項畫圖。示例如下：
各模塊的基本功能簡要描述如下：
○ agent：節點監控數據采集
○ master：agent的管控中心，負責將監控項配置下發給agent。
○ monitor：接收agent采集的監控數據，并統一存放到Kafka消息隊列中。
○ analyser：訂閱Kafka對列消息，進行數據的分析處理，存儲和報警。（實際實現過程中，可以視情況對該模塊進行適度的功能擴展和模塊拆分）
○ web: 監控模型的各種管理，視圖的展示。
○ kafka: 消息隊列，緩存采集數據，共其他模塊訂閱使用。
○ DB/HBase：存儲模型配置，監控數據等。
這個架構是一個常見的監控模型架構，而且比較容易和運維體系打通。在我們實現容器監控的過程中，就可以采用這個模型。
數據采集是 Docker監控和一般監控系統實現過程中最有差異的地方。因為在 Docker容器內部，沒有數據采集的 agent模塊將不能直接依賴 agent來采集。
在容器宿主機上，我們可以獲取到容器的很多基礎數據。一般有以下幾種方法。
docker stats 這一方法比較簡單，但是數據并不全面，我們可以看到如下效果。
集群的數據，是根據每個節點上的原始數據計算得到。是一種聚合運算，一般會有 sum，avg等運算場景。
同理，應用和產品的數據則可以通過子節點的數據來計算得到。
由于容器的自身特性，容器的銷毀，創建等是一個很常見的場景。一個容器啟動后，監控系統怎么察覺，同時需要對其做哪些數據模型的采集，這些問題就是監控自動化過程需要解決的。
容器新創建，停止，或者銷毀，在宿主機上可以感知到。一般可以從如下目錄獲取。由于 Docker安裝配置不同，或者 Docker采用的文件系統的差異，可能部分目錄會有不一致，但實際獲取策略都類似。
當容器關聯到集群后，則可以自動監控項配置。通過 master將配置下發到容器宿主機上的 agent后，則可以開始對容器進行數據采集和上報，從而對容器進行自動監控。
本文提出了一種模型化容器監控方案。通過對監控對象、監控過程進行建模，基于模型來驅動整個監控場景，同時描述了該方案的主要實現方法。
這套方案相比現有的容器監控實現，具有更好的靈活性和擴展性。通過模型的改進和擴展，能夠方便地將 Docker容器的監控融入到現有的監控和運維體系中去。
監控系統本身是一個非常復雜的體系。本文描述的方案很多地方細節上還沒有充分展開，模型的建立上可能也有一些局限和考慮不周的地方，需要后續逐步完善。希望本文思路能給讀者在開發監控系統、建設運維體系的過程中提供一些參考。
感謝各位的閱讀，以上就是“Docker容器的自動化監控實現方法”的內容了，經過本文的學習后，相信大家對Docker容器的自動化監控實現方法這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
