九爺帶你玩轉 docker 五大監控

時間  2021-08-13
標籤 html python ios git github web docker shell 數據庫 json 欄目 Docker 简体版
原文   原文鏈接

輕量級虛擬化容器 Docker，自發布以來便廣受業界關注，在開源界和企業界掀起了一陣風。Docker 容器相對於 VM 有如下幾個優點：啓動速度快；資源利用率高；性能開銷小。html

vm_docker-2-2.png&objectId=1190000004076

從圖中能夠看出 Docker 和 虛擬機的差別，虛擬機的 Guest OS 和 Hypervisor 層在 Docker 中被 Docker Engine 層所替代，Docker 有着比虛擬機更少的抽象層。因爲 Docker 不須要經過 Hypervisor 層實現硬件資源虛擬化，運行在 Docker 容器上的程序直接使用實際物理機的硬件資源。所以在 CPU、內存利用率上 Docker 略勝一籌。Docker利用的是宿主機的內核，而不須要 Guest OS，所以，當新建一個容器時，Docker 不須要和虛擬機同樣從新加載一個操做系統內核，所以新建一個 Docker 容器只須要幾秒鐘。python

既然 Docker 這麼火，那麼問題來了，爲了可以更精確的分配每一個容器能使用的資源，咱們想要實時獲取容器運行時使用資源的狀況，怎樣對 Docker 上的應用進行監控呢？Docker 的結構會不會加大監控難度？ios

咱們都瞭解， container 至關於小型 host，能夠說存在於 hosts 與應用之間的監控盲區，不管是傳統的基礎組件監控仍是應用性能監控的方式，都很難有效地監控 Docker。瞭解了一下現有的 Docker 相關監測 App 和服務，包括簡單的開源工具和複雜的企業總體解決方案，下面列舉幾種Docker 監控工具做爲參考：git

1. cAdvisorgithub

谷歌的 container introspection 解決方案是 cAdvisor，這是一個 Docker 容器內封裝的實用工具，可以蒐集、集料、處理和導出運行中的容器的信息。經過它能夠看到 CPU 的使用率、內存使用率、網絡吞吐量以及磁盤空間利用率。而後，你能夠經過點擊在網頁頂部的 Docker Containers 連接，而後選擇某個容器來詳細瞭解它的使用狀況。cAdvisor 部署和使用簡單，但它只能夠監視在同一個 host 上運行的容器，對多節點部署不是太管用。web

2. Cloud Insightdocker

在咱們列舉的幾個監控 Docker 的服務或平臺中，這是惟一一款國內產品。Cloud Insight 支持多種操做系統、雲主機、數據庫和中間件的監控，原理是在平臺服務儀表盤和自定義儀表盤中，採集並處理 Metric，對數據進行聚合與分組等計算，提供曲線圖、柱狀圖等多樣化的展示形式。優勢是監控的指標很全，簡單易用，但目前正式版還未上線，能夠期待一下。shell

3. Scout數據庫

Scout 是一款監視服務，並非一個獨立的開源項目。它有大量的插件，除了 Docker 信息還能夠吸取其餘有關部署的數據。所以 Scout 算是一站式監控系統，無需對系統的各類資源來安裝各類不一樣的監控系統。 Scout 的一個缺點是，它不顯示有關每一個主機上單獨容器的詳細信息。此外，每一個監控的主機十美圓這樣略微昂貴的價格也是是否選擇 Scout 做爲監控服務的一個考慮因素，若是運行一個有多臺主機的超大部署，成本會比較高。json

4. Sematext

Sematext 也是一款付費監控解決方案，計劃收費方案是3.5美分/小時。一樣也支持 Docker 監控，還包括對容器級事件的監測（中止、開始等等）和管理容器產生的日誌。

時間關係咱們選擇了其中安裝最簡單的 Cloud Insight 來試驗監控基於 Docker 的一個應用——Acme 的運行狀況，後期時間容許會將其餘幾種監控方式都試一遍。

Docker 監控實戰

單方面監控 Docker 可能並不太適合與業務掛鉤的應用，當業務量上漲，不僅僅是 Docker 的負載上升，其餘 JVM 指標也能也會出現上升的趨勢。

咱們嘗試使用一個支持比較多中間件、數據庫、操做系統、容器的 Cloud Insight 來講明這個實際的場景。

Cloud Insight

Cloud Insight 因爲是一個 SaaS 監控方案，相對來講它的安裝和部署都比較簡單。在此次監控實戰中，咱們以 AcmeAir 爲實驗對象：一個能夠模擬壓力的電子商務類應用。

AcmeAir 是一款由原 IBM 新技術架構部資深工程師 Andrew Spyker，利用 Netflix 開源的 Netflix OSS 打造的開源電子商務應用。此應用具備以下特性：

  1. 模擬提供航班訂票服務。用戶能夠經過移動設備或者 web 瀏覽器，完成新用戶註冊，用戶登陸，航班查詢，訂票等操做。

  2. AcmeAir 融入了 Docker，微服務架構等理念。並採用 Tomcat、Node.js、WebSphere Application Server、WebSphere Extreme Scale、MongoDB、Cassandra 分別打造了不一樣版本的實現。

  3. AcmeAir 利用 JMeter 模擬用戶行爲。可經過動態調整用戶數量，模擬產生各類壓力的事物流量。並可在應用中預先植入錯誤代碼，模擬各類故障場景。該應用可作爲壓力測試，終端用戶體驗異常檢測，故障診斷等各類測試場景的測試用例。

acme-1.png&objectId=1190000004076977&tok

首先，咱們要打開 Cloud Insight 監控，還好 Cloud Insight 安裝簡單，一條命令便可。接着，咱們新建一個用於這次監控的儀表盤，依次將想要獲取的指標通通添加進去。好比，選中 jvm.non_heap_memory 這個指標，選擇按照 instance 分組。

咱們添加如下指標：

  • docker.cpu.user

  • docker.cpu.sysytem

  • docker.containers.running

  • jvm.heap_memory

  • jvm.non_heap_memory

  • jvm.gc.cms.count

  • jvm.heap_memory_max

  • jvm.gc.parnew.time

應用 Acme 部署在四臺 servers 上，咱們開啓四臺 servers, 而後用 JMeter 給應用加壓。隨着時間 JMeter 不斷給應用加壓。

jmeter-1.png&objectId=1190000004076977&t

當 users 人數達到 188 時，咱們再來看一下儀表盤的視圖。

docker_dashboard_jmeter-2.png&objectId=1

從圖中能夠看到，性能數據發生了變化，根據 JMeter 裏的數據，此時 CPU 佔用超過了50%，錯誤率也有所提高；對比來看，根據 Cloud Insight 裏的曲線顯示，藍色的線所表明的 Container CPU 佔用率已經超過50%，逐漸接近75%，系統剩餘的 CPU 資源逐漸降低，該 Container 的系統 CPU 資源消耗也忽然增大。咱們能夠經過這些定位到 CPU 佔用率太高的 Container ，及時而主動地去了解性能瓶頸，從而優化性能，合理分配資源。

Cloud Insight 所抓取的性能指標算是較爲全面，部署和展示方式都是至關簡單易懂的，對這個產品能夠期待一下。

Cloud Insight 集監控、管理、計算、協做、可視化於一身，幫助全部 IT 公司，減小在系統監控上的人力和時間成本投入，讓運維工做更加高效、簡單。想閱讀更多技術文章，請訪問 OneAPM 官方博客。





這篇文章做者是Usman，他是服務器和基礎架構工程師，有很是豐富的分佈式構建經驗。該篇文章主要

分析評估了五種Docker監控工具，包括免費的和不 免費的：Docker Stats、CAdvisor、Scout、Data Dog以及Sensu。不過做者仍是推薦使用Data Dog。另外還有兩個工具：Prometheus與Sysdig Cloud會在下一篇作介紹分析，敬請期待。 

wKioL1jk7T7gWJ_rAAGSIgcmn0c095.png-wh_50
隨着Docker被大規模的部署應用，如何經過可視化的方式瞭解Docker環境的狀態以及健康變得愈來愈重要。這篇文章咱們來回顧下監控容器的經常使用工具。我會基於如下標準評估這些工具： 

  1. 易於部署

  2. 信息呈現的詳細度

  3. 整個部署過程當中日誌的彙集程度

  4. 數據報警能力

  5. 是否能夠監控非Docker的資源

  6. 成本


這些評估標準可能並不全面，可是我試圖強調的是最經常使用的工具以及優化此六項評估標準的工具。 

Docker Stats命令

本文中全部使用的命令只在亞馬遜EC2上的RancherOS實例中測試過。可是我想它們應該能夠在任何的Docker容器中運行。 

我將討論的第一個工具是Docker自己。你可能不知道Docker客戶端已經提供了基本的命令行工具來檢查容器的資源消耗。想要查看容器統計信息只需運行docker stats [CONTAINER_NAME]。這樣就能夠查看每一個容器的CPU利用率、內存的使用量以及可用內存總量。請注意，若是你沒有限制容器內存，那麼該命令將顯示您的主機的內存總量。但它並不意味着你的每一個容器都能訪問那麼多的內存。另外，還能夠看啊都容器經過網絡發送和接收的數據總量。 

$ docker stats determined_shockley determined_wozniak prickly_hypatia
CONTAINER             CPU %               MEM USAGE/LIMIT       MEM %               NET I/O
determined_shockley   0.00%               884 KiB/1.961 GiB     0.04%               648 B/648 B
determined_wozniak    0.00%               1.723 MiB/1.961 GiB   0.09%               1.266 KiB/648 B
prickly_hypatia       0.00%               740 KiB/1.961 GiB     0.04%               1.898 KiB/648 B


若是想要看到更爲詳細的容器屬性，還能夠經過netcat，使用Docker遠程API來查看（見下文）。發送一個HTTP GET請求/containers/[CONTAINER_NAME]，其中CONTAINER_NAME是你想要統計的容器名稱。你能夠從 這裏看到一個容器stats請求的完整響應信息。在上述的例子中你會獲得緩存、交換空間以及內存的詳細信息。若是要了解什麼是metrics，那麼你就須要精讀Docker文檔的 Run Metrics部分。 

評分：

1. 易於部署程度：※※※※※ 
2. 信息詳細程度：※※※※※ 
3. 集成度：無 
4. 生成警報的能力：無 
5. 監測非Docker的資源的能力：無 
6. 成本：免費 

CAdvisor

咱們可使用docker stats命令和遠程API來獲取容器的狀態信息。可是，若是你想要在圖形界面中直接查看這些信息，那你就須要諸如 CAdvisor這類的工具。CAdvisor提供了早docker stats命令所顯示的數據的可視化界面。運行如下Docker命令，並在瀏覽器裏訪問http://<your-hostname>:8080/能夠看到CAdvisor的界面。你將看到CPU的使用率、內存使用率、網絡吞吐量以及磁盤空間利用率。而後，你能夠經過點擊在網頁頂部的Docker Containers連接，而後選擇某個容器來詳細瞭解它的使用狀況。 

docker run                                      \
--volume=/:/rootfs:ro                         \
--volume=/var/run:/var/run:rw                 \
--volume=/sys:/sys:ro                         \
--volume=/var/lib/docker/:/var/lib/docker:ro  \
--publish=8080:8080                           \
--detach=true                                 \
--name=cadvisor                               \
google/cadvisor:latest


【實戰】五個Docker監控工具的對比


CAdvisor是一個易於設置而且很是有用的工具，咱們不用非要SSH到服務器才能查看資源消耗，並且它還給咱們生成了圖表。此外，當集羣須要額外的資 源時，壓力錶（pressure gauges ）提供了快速預覽。並且，與本文中的其餘的工具不同的是CAdvisor是免費的，而且還開源。另外，它的資源消耗也比較低。可是，它有它的侷限性，它 只能監控一個Docker主機。所以，若是你是多節點的話，那就比較麻煩了，你得在全部的主機上都安裝一個CAdvisor，者確定特別不方便。值得注意 的是，若是你使用的是Kubernetes，你可使用 heapster來 監控多節點集羣。另外，在圖表中的數據僅僅是時長一分鐘的移動窗口，並無方法來查看長期趨勢。若是資源使用率在危險水平，它卻沒有生成警告的機制。若是 在Docker節點的資源消耗方面，你沒有任何可視化界面，那麼CAdvisor是一個不錯的開端來帶你步入容器監控，然而若是你打算在你的容器中運行任 何關鍵任務，那你就須要一個更強大的工具或者方法。 

評分：（忽略了heapster，由於它僅支持Kubernetes）

1. 易於部署程度：※※※※※ 
2. 信息詳細程度：※※ 
3. 集成度：※ 
4. 生成警報的能力：無 
5. 監測非Docker的資源的能力：無 
6. 成本：免費 

Scout

下一個Docker監控的方法是Scout，它解決了CAdvisor的侷限性。 Scout是一個應用監控服務，它可以從不少主機和容器中得到各項監測數據，並將數據呈如今有更長時間尺度的圖標中。它也能夠基於這些指標生成警報。要獲取Scout並運行，第一步，在 scoutapp.com註冊一個Scout賬戶，免費的試用帳號足以用來集成測試。一旦你建立了本身的賬戶並登陸，點擊右上角的賬戶名稱，而後點擊Account Basics來查看你的Account Key，你須要這個Key從Docker服務器來發送指標。 

【實戰】五個Docker監控工具的對比


【實戰】五個Docker監控工具的對比


如今在你的主機上，建立一個名爲scouts.yml的文件並將下面的文字複製到該文件中，用上邊獲得的Key替換到account_key。您能夠對主 機指定任何有意義的變量：display_name、environment與roles等屬性。當他們在scout界面上呈現時，這些將用於分離各類指 標。我假設有一組網站服務器列表正在運行Docker，它們都將採用以下圖所示的變量。 

# account_key is the only required value
account_key: YOUR_ACCOUNT_KEY
hostname: web01-host
display_name: web01
environment: production
roles: web


如今，你可使用scout配置文件經過Docker-scout插件來運行scout。 

docker run -d  --name scout-agent                              \
-v /proc:/host/proc:ro                                               \
-v /etc/mtab:/host/etc/mtab:ro                                   \
-v /var/run/docker.sock:/host/var/run/docker.sock:ro    \
-v `pwd`/scoutd.yml:/etc/scout/scoutd.yml                     \
-v /sys/fs/cgroup/:/host/sys/fs/cgroup/                           \
--net=host --privileged                                                   \
soutapp/docker-scout


這樣你查看Scout網頁就能看到一個條目，其中display_name參數（web01）就是你在scoutd.yml裏面指定的。 

【實戰】五個Docker監控工具的對比


若是你點擊它（web01）就會顯示主機的詳細信息。其中包括任何運行在你主機上的進程計數、cpu使用率以及內存利用率，值得注意的是在docker內部並無進程的限制。 

【實戰】五個Docker監控工具的對比


若是要添加Docker監控服務，須要單擊Roles選項卡，而後選擇全部服務。如今點擊+插件模板按鈕，接下來的Docker監視器會加載詳細信息視 圖。一旦詳細信息呈現出來，選擇安裝插件來添加到您的主機。接着會給你提供一個已安裝插件的名稱以及需指定要監視的容器。若是該字段是空的，插件將監控主 機上全部的容器。點擊完成按鈕，一分鐘左右你就能夠在[Server Name] > Plugins中看到從Docker監控插件中獲取的詳細信息。該插件爲每一個主機顯示CPU使用率、內存使用率、網絡吞吐量以及容器的數量。 

【實戰】五個Docker監控工具的對比


你點擊任何一個圖表，均可以拉取該指標的詳細視圖，該視圖可讓你看到時間跨度更長的趨勢。 

【實戰】五個Docker監控工具的對比


該視圖還支持過濾基於環境和服務器角色的指標。此外，你能夠建立「Triggers」或警報，若是指標高於或低於配置的閾值它就給你發送電子郵件。這就允 許您設置自動警報來通知您，好比，若是你的一些容器異常關閉以及容器計數低於必定數量。您還能夠設置對平均CPU利用率的警報，舉例來講，若是你正在運行 的容器超過CPU利用率而發熱，你會獲得一個警告，固然你能夠開啓更多的主機到你的Docker集羣。 

要建立觸發器，請選擇頂部菜單的Roles>All Servers，而後選擇plugins部分的Docker monitor。而後在屏幕的右側的Plugin template Administration菜單裏選擇triggers。您如今應該看到一個選項「Add a Trigger」，它將應用到整個部署。 

【實戰】五個Docker監控工具的對比


下面是一個觸發器的例子，若是部署的容器數量低於3就會發出警報。 

【實戰】五個Docker監控工具的對比


它的建立是爲「全部的服務器」，固然你也能夠用不一樣的角色標記你的主機使用服務器上建立的scoutd.yml文件。使用角色。你能夠經過使用不一樣角色來 應用觸發器到部署的服務器的一個子集上。例如，你能夠設置一個當在你的網絡的節點的容器數量低於必定數量時的警報。即便是基於角色的觸發器我仍然以爲 Scout的警報系統可能作的更好。這是由於許多Docker部署具備相同主機上的多種多樣的容器。在這種狀況下爲特定類型的容器設置觸發器將是不可能的 因爲角色被應用到主機上的全部容器。 

比起CAdvisor，使用Scout的另外一個優勢是，它有 大量的插件，除了Docker信息他們能夠吸取其餘有關你的部署的數據。這使得Scout是你的一站式監控系統，而無需對系統的各類資源來安裝各類不一樣的監控系統。 

Scout的一個缺點是，它不顯示有關每一個主機上像CAdvisor的單獨容器的詳細信息。這是個問題，若是你在同一臺服務器上運行大量的容器。 例如，若是你想有一個觸發器來提醒您的Web容器的警報，但不是Jenkins容器，這時Scout就沒法支持該狀況。儘管有這個缺點，Scout仍是一 個至關有用的工具來監控你的Docker部署。固然這要付出一些代價，每一個監控的主機十美圓。若是你要運行一個有多臺主機的超大部署，這個代價會是個考慮 因素。 

評分：

1. 易於部署程度：※※※※ 
2. 信息詳細程度：※※ 
3. 集成度：※※※ 
4. 生成警報的能力：※※※ 
5. 監測非Docker的資源的能力：支持 
6. 成本：每一個主機$10 

Data Dog

從Scout移步到另外一個監控服務——DataDog，它既解決幾個Scout的缺點又解除了CAdvisor的侷限性。要使用DataDog，先在 https://www.datadoghq.com/注 冊一個DataDog帳戶。一旦你登陸到您的賬戶，您將看到支持集成的每種類型的指令列表。從列表中選擇Docker，你會獲得一個Docker run命令（以下），將其複製到你的主機。該命令須要你的預先設置的API密鑰，而後你能夠運行該命令。大約45秒鐘後您的代理將開始向DataDog系 統報告。 

docker run -d --privileged --name dd-agent             \
-h `hostname`                                      \
-v /var/run/docker.sock:/var/run/docker.sock       \
-v /proc/mounts:/host/proc/mounts:ro               \
-v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro          \
-e API_KEY=YOUR_API_KEY datadog/docker-dd-agent    \


此時，容器提示你能夠在DataDog Web的Events tab上處理和查看有關集羣的全部動態。全部容器的啓動和終止都是事件流的一部分。

【實戰】五個Docker監控工具的對比


您也能夠點擊Dashboards標籤並點擊建立儀表板以合計您整個羣集的指標。 Datadog收集在系統中運行的全部容器的CPU使用率、內存以及I/O的指標。此外，也能夠得到容器運行和中止次數以及Docker的鏡像數量。 Dashboard視圖能夠建立任何數據的圖標，或者設置整個部署、主機羣、容器鏡像指標的圖表。例以下圖顯示了運行容器的數量並加以鏡像類型分類，此刻 在個人集羣運行了9個Ubuntu:14.04的容器。 

【實戰】五個Docker監控工具的對比


您還能夠經過主機分類一樣的數據，以下圖所示，7個容器在個人Rancher主機上運行，其他的在個人本地的筆記本電腦。 

【實戰】五個Docker監控工具的對比


DataDog還支持一種稱爲Monitors的警報功能。DataDog的一個monitor至關於Scout的一個觸發器，並容許您定義各類指標的閾 值。 比起Scout，DataDog的警報系統至關靈活與詳細。下面的例子說明如何指定您監視的Ubuntu容器的終止，所以你會監視從 Ubuntu:14.04的Docker鏡象所建立容器的docker.containers.running信息。 

【實戰】五個Docker監控工具的對比


而後，特定的警報狀況是，若是在咱們的部署中最後5分鐘有（平均）少於十個Ubuntu容器，你就會被警報。儘管這裏沒有顯示，你會被要求填寫發送出去時 的指定消息在這個警報被觸發後，並且還有受到此警報的目標。在當前的例子中，我用一個簡單的絕對閾值。您也能夠指定一個基於增量的警報，好比是在最後五分 鍾裏中止的容器的平均計數是四的警報。 

【實戰】五個Docker監控工具的對比


最後，使用Metrics Explorer選項卡能夠臨時彙集你的指標來幫助調試問題或者提取具體的數據信息。該視圖容許您基於對容器鏡像或主機繪製任何指標的圖表。您能夠將輸出的數據組合成一個單一的圖形或者經過鏡像或主機的分組來生成一組圖形。 

【實戰】五個Docker監控工具的對比


DataDog相比scout在某些功能上作了顯著地改善，方便使用以及用戶友好的設計。然而這一級別伴隨着額外的成本，由於每一個DataDog agent價格爲$15。 

評分：

1. 易於部署程度：※※※※※ 
2. 信息詳細程度：※※※※※ 
3. 集成度：※※※※※ 
4. 生成警報的能力：支持 
5. 監測非Docker的資源的能力：※※※※※ 
6. 成本：每一個主機$15 

Sensu Monitoring Framework

Scout和Datadog提供集中監控和報警系統，然而他們都是被託管的服務，大規模部署的話成本會很突出。若是你須要一個自託管、集中指標的服務，你能夠考慮 sensu open source monitoring framework。要運行Sensu服務器可使用 hiroakis/docker-sensu-server容器。這個容器會安裝sensu-server、uchiwa Web界面、Redis、rabbitmq-server以及sensu-api。不幸的是sensu不支持Docker。可是，使用插件系統，您能夠配置支持容器指標以及狀態檢查。 

在開啓sensu服務容器以前，你必須定義一個能夠加載到服務器中檢查。建立一個名爲check-docker.json的文件並添加如下內容到 此文件。這個文件告訴Sensu服務器在全部有docker標籤的客戶端上每十秒運行一個名爲load-docker-metrics.sh的腳本。 

{
"checks": {
"load_docker_metrics": {
  "type": "metric",
  "command": "load-docker-metrics.sh",
  "subscribers": [
    "docker"
  ],
  "interval": 10
}
}
}


如今，您可使用下面的命令經過咱們的檢查配置文件來運行Sensu服務器Docker容器。一旦你運行該命令，你就能夠在瀏覽器輸入http://YOUR_SERVER_IP:3000來訪問uchiwa界面。 

docker run -d --name sensu-server                                           \
-p 3000:3000                                                            \
-p 4567:4567                                                            \
-p 5671:5671                                                            \
-p 15672:15672                                                          \
-v $PWD/check-docker.json:/etc/sensu/conf.d/check-docker.json           \
hiroakis/docker-sensu-server


這樣Sensu服務器就開啓了，你就能夠對每一個運行有咱們的Docker容器的主機上開啓sensu客戶端。你告訴容器將有一個名爲load- docker-metrics.sh的腳本，因此讓咱們建立腳本，並將其放到咱們的客戶端容器內。建立該文件並添加以下所示的文本，將HOST_NAME 替換爲您的主機的邏輯名稱。下面的腳本是爲運行容器、全部容器以及鏡像而使用Docker遠程API來拉取元數據。而後它打印出來sensu的鍵值標示的 值。該sensu服務器將讀取標準輸出並收集這些指標。這個例子只拉取這三個值，但根據須要，你可使腳本儘量詳細。請注意，你也能夠添加多個檢查腳 本，如thos，只要早前在服務配置文件中你引用過它們。你也能夠定義你想要檢查運行Docker容器數量降至三個如下的失敗。你還可使檢查經過從檢查 腳本返回一個非零值失敗。 

#!/bin/bash
set -e

# Count all running containers
running_containers=$(echo -e "GET /containers/json HTTP/1.0\r\n" | nc -U /var/run/docker.sock \
| tail -n +5                                                           \
| python -m json.tool                                                  \
| grep \"Id\"                                                          \
| wc -l)
# Count all containers
total_containers=$(echo -e "GET /containers/json?all=1 HTTP/1.0\r\n" | nc -U /var/run/docker.sock \
| tail -n +5 \
| python -m json.tool \
| grep \"Id\" \
| wc -l)

# Count all p_w_picpaths
total_p_w_picpaths=$(echo -e "GET /p_w_picpaths/json HTTP/1.0\r\n" | nc -U /var/run/docker.sock \
| tail -n +5 \
| python -m json.tool \
| grep \"Id\" \
| wc -l)

echo "docker.HOST_NAME.running_containers ${running_containers}"
echo "docker.HOST_NAME.total_containers ${total_containers}"
echo "docker.HOST_NAME.total_p_w_picpaths ${total_p_w_picpaths}"

if [ ${running_containers} -lt 3 ]; then
exit 1;
fi


如今你已經定義了Docker載入指標檢查，那就須要使用 usman/sensu-client容 器來啓動sensu客戶端。您可使用以下所示的命令啓動sensu客戶端。須要注意的是，容器必須以privileged來運行以便可以訪問Unix sockets，它必須有Docker socket掛載以及你上面定義的load-docker-metrics.sh腳本。確保load-docker-metrics.sh腳本在你的主機 的權限標記爲可執行。容器也須要將SENSU_SERVER_IP、RABIT_MQ_USER、RABIT_MQ_PASSWORD、 CLIENT_NAME以及CLIENT_IP做爲參數，請指定這些參數到您設置的值。其中RABIT_MQ_USER與 RABIT_MQ_PASSWORD默認值是sensu和password。 

docker run -d --name sensu-client --privileged                                \
-v $PWD/load-docker-metrics.sh:/etc/sensu/plugins/load-docker-metrics.sh  \
-v /var/run/docker.sock:/var/run/docker.sock                              \
usman/sensu-client SENSU_SERVER_IP RABIT_MQ_USER RABIT_MQ_PASSWORD CLIENT_NAME CLIENT_IP


【實戰】五個Docker監控工具的對比


運行完此命令，一下子你應該看到客戶端計數增長1在uchiwa界面。若是您點擊客戶端圖標，你應該看到，包括你剛纔添加的客戶端的客戶端名單。個人客戶端1是client-1以及指定的主機IP爲192.168.1.1。 

【實戰】五個Docker監控工具的對比


若是你點擊客戶端名稱你應該獲得檢查的進一步細節。你能夠看到load_docker_metrics檢查在3月28日的10:22運行過。 

【實戰】五個Docker監控工具的對比


若是你點擊檢查名稱就能夠看到檢查運行的進一步細節。零代表沒有錯誤，若是腳本失敗（例如，若是您的Docker守護進程死掉），你會看到一個錯誤代碼（非零）值。雖然在目前的文章中沒有涉及這個，你也還可使用 Handlers在 sensu設置這些檢查失敗處理程序來提醒您。此外，uchiwa只顯示檢查的值，而不是收集的指標。須要注意的是sensu不存儲所收集的指標，它們必 須被轉發到一個時間序列的數據庫如InfluxDB或Graphite。這也是經過Handlers作到的。如何配置指標轉發到graphite能夠參考這裏。 

【實戰】五個Docker監控工具的對比


Sensu支持咱們全部的評價標準，你能夠對咱們Docker容器和主機收集儘量多的細節。此外，你可以聚合全部主機的值到一個地方，並對這些檢查發出 警報。這些警報並無DataDog或Scout的先進，由於你僅可以提醒單獨的主機上檢查失敗。然而，Sensu的大缺點是部署的難度。雖然我 已經使用Docker容器自動部署許多步驟，Sensu仍然是一個須要咱們安裝，啓動和分開維護Redis、RabitMQ、Sensu API、uchiwa與Sensu Core的複雜系統。此外，你將須要更多的工具，如Graphite來呈現指標值以及生產部署須要定製容器，今天我已經使用了一個容器爲了密碼的安全以及 自定義的SSL證書。除了您重?羧萜骱蟛拍芴砑癰嗟募觳椋憬壞貌恢匭縷舳瘲ensu服務，由於這是它開始收集新的標準的惟一途徑。因爲這些緣由，我 對Sensu的在易於部署的評價至關的低。 

評分：

1. 易於部署程度：※ 
2. 信息詳細程度：※※※※ 
3. 集成度：※※※※ 
4. 生成警報的能力：支持但有限 
5. 監測非Docker的資源的能力：※※※※※ 
6. 成本：免費 

總結

今天的文章涵蓋了多種選項用於監控Docker容器，從免費的選擇， 如Docker stats、CAdvisor或Sensu，到有償服務，如Scout和DataDog。個人研究到目前爲止DataDog彷佛是用於監控Docker部 署的最好的系統。只需幾秒的安裝以及單行命令，全部主機都在同一個地方報告指標，在UI方面，歷史趨勢是顯而易見的，而且Datadog支持更深層次的指 標以及報警。然而，$15一個主機系統對於大型部署是昂貴的。對於較大規模，自託管部署，Sensu是可以知足大多數的要求，不過在創建和管理一個 Sensu集羣的複雜性可能讓人望而卻步。很顯然，有不少其餘的自託管的選項，如Nagios或Icinga，他們都相似Sensu。 

希望今天這篇文章會給你一些想法對於監視容器的選擇。我會繼續調查其餘選項，包括使用CollectD、Graphite或InfluxDB與Grafana的更精簡的自我管理的容器監控系統。敬請關注更多的細節。 

其餘信息：發佈本文後，我有一些建議去評估Prometheus和Sysdig雲，兩個很是好的監控Docker的選擇。我在這兩個服務上花了一些時間，並添加了第二部分到這個文章中。你能夠在 這裏（譯註：事後會翻譯這篇）找到它。 

想要了解更多關於監控和管理Docker，請參加咱們的下一個Rancher在線meetup。 

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程