五個Docker監控工具的對比
阿新 • • 發佈：2019-02-01
【編者的話】這篇文章作者是Usman，他是伺服器和基礎架構工程師，有非常豐富的分散式構建經驗。該篇文章主要分析評估了五種Docker監控工具，包括免費的和不免費的：Docker Stats、CAdvisor、Scout、Data Dog以及Sensu。不過作者還是推薦使用Data Dog。另外還有兩個工具：Prometheus與Sysdig Cloud會在下一篇做介紹分析，敬請期待。
隨著Docker被大規模的部署應用，如何通過視覺化的方式瞭解Docker環境的狀態以及健康變得越來越重要。這篇文章我們來回顧下監控容器的常用工具。我會基於以下標準評估這些工具：
這些評估標準可能並不全面，但是我試圖強調的是最常用的工具以及優化此六項評估標準的工具。
我將討論的第一個工具是Docker本身。你可能不知道Docker客戶端已經提供了基本的命令列工具來檢查容器的資源消耗。想要檢視容器統計資訊只需執行
如果想要看到更為詳細的容器屬性，還可以通過netcat，使用Docker遠端API來檢視（見下文）。傳送一個HTTP GET請求
2. 資訊詳細程度：※※※※※
3. 整合度：無
4. 生成警報的能力：無
5. 監測非Docker的資源的能力：無
6. 成本：免費
CAdvisor是一個易於設定並且非常有用的工具，我們不用非要SSH到伺服器才能檢視資源消耗，而且它還給我們生成了圖表。此外，當叢集需要額外的資源時，壓力錶（pressure gauges ）提供了快速預覽。而且，與本文中的其他的工具不一樣的是CAdvisor是免費的，並且還開源。另外，它的資源消耗也比較低。但是，它有它的侷限性，它只能監控一個Docker主機。因此，如果你是多節點的話，那就比較麻煩了，你得在所有的主機上都安裝一個CAdvisor，者肯定特別不方便。值得注意的是，如果你使用的是Kubernetes，你可以使用heapster來監控多節點叢集。另外，在圖表中的資料僅僅是時長一分鐘的移動視窗，並沒有方法來檢視長期趨勢。如果資源使用率在危險水平，它卻沒有生成警告的機制。如果在Docker節點的資源消耗方面，你沒有任何視覺化介面，那麼CAdvisor是一個不錯的開端來帶你步入容器監控，然而如果你打算在你的容器中執行任何關鍵任務，那你就需要一個更強大的工具或者方法。
2. 資訊詳細程度：※※
3. 整合度：※
4. 生成警報的能力：無
5. 監測非Docker的資源的能力：無
6. 成本：免費
現在在你的主機上，建立一個名為scouts.yml的檔案並將下面的文字複製到該檔案中，用上邊得到的Key替換到account_key。您可以對主機指定任何有意義的變數：display_name、environment與roles等屬性。當他們在scout介面上呈現時，這些將用於分離各種指標。我假設有一組網站伺服器列表正在執行Docker，它們都將採用如下圖所示的變數。
現在，你可以使用scout配置檔案通過Docker-scout外掛來執行scout。
這樣你檢視Scout網頁就能看到一個條目，其中display_name引數（web01）就是你在scoutd.yml裡面指定的。
如果你點選它（web01）就會顯示主機的詳細資訊。其中包括任何執行在你主機上的程序計數、cpu使用率以及記憶體利用率，值得注意的是在docker內部並沒有程序的限制。
如果要新增Docker監控服務，需要單擊Roles選項卡，然後選擇所有服務。現在點選+外掛模板按鈕，接下來的Docker監視器會載入詳細資訊檢視。一旦詳細資訊呈現出來，選擇安裝外掛來新增到您的主機。接著會給你提供一個已安裝外掛的名稱以及需指定要監視的容器。如果該欄位是空的，外掛將監控主機上所有的容器。點選完成按鈕，一分鐘左右你就可以在[Server Name] > Plugins中看到從Docker監控外掛中獲取的詳細資訊。該外掛為每個主機顯示CPU使用率、記憶體使用率、網路吞吐量以及容器的數量。
你點選任何一個圖表，都可以拉取該指標的詳細檢視，該檢視可以讓你看到時間跨度更長的趨勢。
該檢視還支援過濾基於環境和伺服器角色的指標。此外，你可以建立“Triggers”或警報，如果指標高於或低於配置的閾值它就給你傳送電子郵件。這就允許您設定自動警報來通知您，比如，如果你的一些容器異常關閉以及容器計數低於一定數量。您還可以設定對平均CPU利用率的警報，舉例來說，如果你正在執行的容器超過CPU利用率而發熱，你會得到一個警告，當然你可以開啟更多的主機到你的Docker叢集。
要建立觸發器，請選擇頂部選單的Roles>All Servers，然後選擇plugins部分的Docker monitor。然後在螢幕的右側的Plugin template Administration選單裡選擇triggers。您現在應該看到一個選項“Add a Trigger”，它將應用到整個部署。
下面是一個觸發器的例子，如果部署的容器數量低於3就會發出警報。
它的建立是為“所有的伺服器”，當然你也可以用不同的角色標記你的主機使用伺服器上建立的scoutd.yml檔案。使用角色。你可以通過使用不同角色來應用觸發器到部署的伺服器的一個子集上。例如，你可以設定一個當在你的網路的節點的容器數量低於一定數量時的警報。即使是基於角色的觸發器我仍然覺得Scout的警報系統可能做的更好。這是因為許多Docker部署具有相同主機上的多種多樣的容器。在這種情況下為特定型別的容器設定觸發器將是不可能的由於角色被應用到主機上的所有容器。
比起CAdvisor，使用Scout的另一個優點是，它有大量的外掛，除了Docker資訊他們可以吸收其他有關你的部署的資料。這使得Scout是你的一站式監控系統，而無需對系統的各種資源來安裝各種不同的監控系統。
Scout的一個缺點是，它不顯示有關每個主機上像CAdvisor的單獨容器的詳細資訊。這是個問題，如果你在同一臺伺服器上執行大量的容器。例如，如果你想有一個觸發器來提醒您的Web容器的警報，但不是Jenkins容器，這時Scout就無法支援該情況。儘管有這個缺點，Scout還是一個相當有用的工具來監控你的Docker部署。當然這要付出一些代價，每個監控的主機十美元。如果你要執行一個有多臺主機的超大部署，這個代價會是個考慮因素。
2. 資訊詳細程度：※※
3. 整合度：※※※
4. 生成警報的能力：※※※
5. 監測非Docker的資源的能力：支援
6. 成本：每個主機$10
此時，容器提示你可以在DataDog Web的Events tab上處理和檢視有關叢集的所有動態。所有容器的啟動和終止都是事件流的一部分。
您也可以點選Dashboards標籤並點選建立儀表板以合計您整個群集的指標。 Datadog收集在系統中執行的所有容器的CPU使用率、記憶體以及I/O的指標。此外，也可以獲得容器執行和停止次數以及Docker的映象數量。Dashboard檢視可以建立任何資料的圖示，或者設定整個部署、主機群、容器映象指標的圖表。例如下圖顯示了執行容器的數量並加以映象型別分類，此刻在我的叢集運行了9個Ubuntu:14.04的容器。
您還可以通過主機分類同樣的資料，如下圖所示，7個容器在我的Rancher主機上執行，其餘的在我的本地的膝上型電腦。
DataDog還支援一種稱為Monitors的警報功能。DataDog的一個monitor相當於Scout的一個觸發器，並允許您定義各種指標的閾值。 比起Scout，DataDog的警報系統相當靈活與詳細。下面的例子說明如何指定您監視的Ubuntu容器的終止，因此你會監視從Ubuntu:14.04的Docker鏡象所建立容器的docker.containers.running資訊。
然後，特定的警報情況是，如果在我們的部署中最後5分鐘有（平均）少於十個Ubuntu容器，你就會被警報。儘管這裡沒有顯示，你會被要求填寫傳送出去時的指定訊息在這個警報被觸發後，而且還有受到此警報的目標。在當前的例子中，我用一個簡單的絕對閾值。您也可以指定一個基於增量的警報，比如是在最後五分鐘裡停止的容器的平均計數是四的警報。
最後，使用Metrics Explorer選項卡可以臨時聚集你的指標來幫助除錯問題或者提取具體的資料資訊。該檢視允許您基於對容器映象或主機繪製任何指標的圖表。您可以將輸出的資料組合成一個單一的圖形或者通過映象或主機的分組來生成一組圖形。
DataDog相比scout在某些功能上做了顯著地改善，方便使用以及使用者友好的設計。然而這一級別伴隨著額外的成本，因為每個DataDog agent價格為$15。
2. 資訊詳細程度：※※※※※
3. 整合度：※※※※※
4. 生成警報的能力：支援
5. 監測非Docker的資源的能力：※※※※※
6. 成本：每個主機$15
在開啟sensu服務容器之前，你必須定義一個可以載入到伺服器中檢查。建立一個名為check-docker.json的檔案並新增以下內容到此檔案。這個檔案告訴Sensu伺服器在所有有docker標籤的客戶端上每十秒執行一個名為load-docker-metrics.sh的指令碼。
現在，您可以使用下面的命令通過我們的檢查配置檔案來執行Sensu伺服器Docker容器。一旦你執行該命令，你就可以在瀏覽器輸入
這樣Sensu伺服器就開啟了，你就可以對每個執行有我們的Docker容器的主機上開啟sensu客戶端。你告訴容器將有一個名為load-docker-metrics.sh的指令碼，所以讓我們建立指令碼，並將其放到我們的客戶端容器內。建立該檔案並新增如下所示的文字，將HOST_NAME替換為您的主機的邏輯名稱。下面的指令碼是為執行容器、所有容器以及映象而使用Docker遠端API來拉取元資料。然後它打印出來sensu的鍵值標示的值。該sensu伺服器將讀取標準輸出並收集這些指標。這個例子只拉取這三個值，但根據需要，你可以使指令碼儘可能詳細。請注意，你也可以新增多個檢查指令碼，如thos，只要早前在服務配置檔案中你引用過它們。你也可以定義你想要檢查執行Docker容器數量降至三個以下的失敗。你還可以使檢查通過從檢查指令碼返回一個非零值失敗。
現在你已經定義了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。
執行完此命令，一會兒你應該看到客戶端計數增加1在uchiwa介面。如果您點選客戶端圖示，你應該看到，包括你剛才新增的客戶端的客戶端名單。我的客戶端1是client-1以及指定的主機IP為192.168.1.1。
如果你點選客戶端名稱你應該得到檢查的進一步細節。你可以看到load_docker_metrics檢查在3月28日的10:22執行過。
如果你點選檢查名稱就可以看到檢查執行的進一步細節。零表明沒有錯誤，如果指令碼失敗（例如，如果您的Docker守護程序死掉），你會看到一個錯誤程式碼（非零）值。雖然在目前的文章中沒有涉及這個，你也還可以使用Handlers在sensu設定這些檢查失敗處理程式來提醒您。此外，uchiwa只顯示檢查的值，而不是收集的指標。需要注意的是sensu不儲存所收集的指標，它們必須被轉發到一個時間序列的資料庫如InfluxDB或Graphite。這也是通過Handlers做到的。如何配置指標轉發到graphite可以參考這裡。
Sensu支援我們所有的評價標準，你可以對我們Docker容器和主機收集儘可能多的細節。此外，你能夠聚合所有主機的值到一個地方，並對這些檢查發出警報。這些警報並沒有DataDog或Scout的先進，因為你僅能夠提醒單獨的主機上檢查失敗。然而，Sensu的大缺點是部署的難度。雖然我已經使用Docker容器自動部署許多步驟，Sensu仍然是一個需要我們安裝，啟動和分開維護Redis、RabitMQ、Sensu API、uchiwa與Sensu Core的複雜系統。此外，你將需要更多的工具，如Graphite來呈現指標值以及生產部署需要定製容器，今天我已經使用了一個容器為了密碼的安全以及自定義的SSL證書。除了您重啟容器後才能新增更多的檢查，你將不得不重新啟動Sensu服務，因為這是它開始收集新的標準的唯一途徑。由於這些原因，我對Sensu的在易於部署的評價相當的低。
2. 資訊詳細程度：※※※※
3. 整合度：※※※※
4. 生成警報的能力：支援但有限
5. 監測非Docker的資源的能力：※※※※※
6. 成本：免費
但願今天這篇文章會給你一些想法對於監視容器的選擇。我會繼續調查其他選項，包括使用CollectD、Graphite或InfluxDB與Grafana的更精簡的自我管理的容器監控系統。敬請關注更多的細節。
其他資訊：釋出本文後，我有一些建議去評估Prometheus和Sysdig雲，兩個非常好的監控Docker的選擇。我在這兩個服務上花了一些時間，並添加了第二部分到這個文章中。你可以在這裡（譯註：過後會翻譯這篇）找到它。
想要了解更多關於監控和管理Docker，請參加我們的下一個Rancher線上meetup。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
譯者介紹
田浩浩，USYD研究生，目前在珠海從事手機應用開發工作。業餘時間專注Docker的學習與研究，希望通過DockOne把最新最優秀的譯文貢獻給大家，與讀者一起暢遊Docker的海洋。
隨著Docker被大規模的部署應用，如何通過視覺化的方式瞭解Docker環境的狀態以及健康變得越來越重要。這篇文章我們來回顧下監控容器的常用工具。我會基於以下標準評估這些工具：
- 易於部署
- 資訊呈現的詳細度
- 整個部署過程中日誌的聚集程度
- 資料報警能力
- 是否可以監控非Docker的資源
- 成本
這些評估標準可能並不全面，但是我試圖強調的是最常用的工具以及優化此六項評估標準的工具。
Docker Stats命令
本文中所有使用的命令只在亞馬遜EC2上的RancherOS例項中測試過。但是我想它們應該可以在任何的Docker容器中執行。我將討論的第一個工具是Docker本身。你可能不知道Docker客戶端已經提供了基本的命令列工具來檢查容器的資源消耗。想要檢視容器統計資訊只需執行
docker stats [CONTAINER_NAME]$ 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
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伺服器來發送指標。
現在在你的主機上，建立一個名為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裡面指定的。
如果你點選它（web01）就會顯示主機的詳細資訊。其中包括任何執行在你主機上的程序計數、cpu使用率以及記憶體利用率，值得注意的是在docker內部並沒有程序的限制。
如果要新增Docker監控服務，需要單擊Roles選項卡，然後選擇所有服務。現在點選+外掛模板按鈕，接下來的Docker監視器會載入詳細資訊檢視。一旦詳細資訊呈現出來，選擇安裝外掛來新增到您的主機。接著會給你提供一個已安裝外掛的名稱以及需指定要監視的容器。如果該欄位是空的，外掛將監控主機上所有的容器。點選完成按鈕，一分鐘左右你就可以在[Server Name] > Plugins中看到從Docker監控外掛中獲取的詳細資訊。該外掛為每個主機顯示CPU使用率、記憶體使用率、網路吞吐量以及容器的數量。
你點選任何一個圖表，都可以拉取該指標的詳細檢視，該檢視可以讓你看到時間跨度更長的趨勢。
該檢視還支援過濾基於環境和伺服器角色的指標。此外，你可以建立“Triggers”或警報，如果指標高於或低於配置的閾值它就給你傳送電子郵件。這就允許您設定自動警報來通知您，比如，如果你的一些容器異常關閉以及容器計數低於一定數量。您還可以設定對平均CPU利用率的警報，舉例來說，如果你正在執行的容器超過CPU利用率而發熱，你會得到一個警告，當然你可以開啟更多的主機到你的Docker叢集。
要建立觸發器，請選擇頂部選單的Roles>All Servers，然後選擇plugins部分的Docker monitor。然後在螢幕的右側的Plugin template Administration選單裡選擇triggers。您現在應該看到一個選項“Add a Trigger”，它將應用到整個部署。
下面是一個觸發器的例子，如果部署的容器數量低於3就會發出警報。
它的建立是為“所有的伺服器”，當然你也可以用不同的角色標記你的主機使用伺服器上建立的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上處理和檢視有關叢集的所有動態。所有容器的啟動和終止都是事件流的一部分。
您也可以點選Dashboards標籤並點選建立儀表板以合計您整個群集的指標。 Datadog收集在系統中執行的所有容器的CPU使用率、記憶體以及I/O的指標。此外，也可以獲得容器執行和停止次數以及Docker的映象數量。Dashboard檢視可以建立任何資料的圖示，或者設定整個部署、主機群、容器映象指標的圖表。例如下圖顯示了執行容器的數量並加以映象型別分類，此刻在我的叢集運行了9個Ubuntu:14.04的容器。
您還可以通過主機分類同樣的資料，如下圖所示，7個容器在我的Rancher主機上執行，其餘的在我的本地的膝上型電腦。
DataDog還支援一種稱為Monitors的警報功能。DataDog的一個monitor相當於Scout的一個觸發器，並允許您定義各種指標的閾值。 比起Scout，DataDog的警報系統相當靈活與詳細。下面的例子說明如何指定您監視的Ubuntu容器的終止，因此你會監視從Ubuntu:14.04的Docker鏡象所建立容器的docker.containers.running資訊。
然後，特定的警報情況是，如果在我們的部署中最後5分鐘有（平均）少於十個Ubuntu容器，你就會被警報。儘管這裡沒有顯示，你會被要求填寫傳送出去時的指定訊息在這個警報被觸發後，而且還有受到此警報的目標。在當前的例子中，我用一個簡單的絕對閾值。您也可以指定一個基於增量的警報，比如是在最後五分鐘裡停止的容器的平均計數是四的警報。
最後，使用Metrics Explorer選項卡可以臨時聚集你的指標來幫助除錯問題或者提取具體的資料資訊。該檢視允許您基於對容器映象或主機繪製任何指標的圖表。您可以將輸出的資料組合成一個單一的圖形或者通過映象或主機的分組來生成一組圖形。
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 images
total_images=$(echo -e "GET /images/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_images ${total_images}"
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
執行完此命令，一會兒你應該看到客戶端計數增加1在uchiwa介面。如果您點選客戶端圖示，你應該看到，包括你剛才新增的客戶端的客戶端名單。我的客戶端1是client-1以及指定的主機IP為192.168.1.1。
如果你點選客戶端名稱你應該得到檢查的進一步細節。你可以看到load_docker_metrics檢查在3月28日的10:22執行過。
如果你點選檢查名稱就可以看到檢查執行的進一步細節。零表明沒有錯誤，如果指令碼失敗（例如，如果您的Docker守護程序死掉），你會看到一個錯誤程式碼（非零）值。雖然在目前的文章中沒有涉及這個，你也還可以使用Handlers在sensu設定這些檢查失敗處理程式來提醒您。此外，uchiwa只顯示檢查的值，而不是收集的指標。需要注意的是sensu不儲存所收集的指標，它們必須被轉發到一個時間序列的資料庫如InfluxDB或Graphite。這也是通過Handlers做到的。如何配置指標轉發到graphite可以參考這裡。
Sensu支援我們所有的評價標準，你可以對我們Docker容器和主機收集儘可能多的細節。此外，你能夠聚合所有主機的值到一個地方，並對這些檢查發出警報。這些警報並沒有DataDog或Scout的先進，因為你僅能夠提醒單獨的主機上檢查失敗。然而，Sensu的大缺點是部署的難度。雖然我已經使用Docker容器自動部署許多步驟，Sensu仍然是一個需要我們安裝，啟動和分開維護Redis、RabitMQ、Sensu API、uchiwa與Sensu Core的複雜系統。此外，你將需要更多的工具，如Graphite來呈現指標值以及生產部署需要定製容器，今天我已經使用了一個容器為了密碼的安全以及自定義的SSL證書。除了您重啟容器後才能新增更多的檢查，你將不得不重新啟動Sensu服務，因為這是它開始收集新的標準的唯一途徑。由於這些原因，我對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。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
譯者介紹
田浩浩，USYD研究生，目前在珠海從事手機應用開發工作。業餘時間專注Docker的學習與研究，希望通過DockOne把最新最優秀的譯文貢獻給大家，與讀者一起暢遊Docker的海洋。