容器領域的十大監控系統對比(上）

容器監測環境有多種形態和大小。有些是開源的，而另外一些則是商業性質的。有些能夠藉助平臺一鍵部署（例如在Rancher容器管理平臺的應用目錄中一鍵部署這些監控應用），而另外一些則須要手動配置。有些是通用的，有些是專門針對容器環境的。有些託管在公有云中，而另外一些則須要在本身的集羣主機上安裝。

在本文中，我將對容器領域的10個監控解決方案進行全面的分析對比。監控解決方案的數量之多使人望而生畏。新的解決方案不斷涌現，同時現有的解決方案不斷髮展。我沒有深刻研究每一個解決方案，而是採起了high-level的對比方法。經過這種方法，讀者能夠「縮小列表」，並能針對自身需求進行更認真的評估，從而選出最適合的解決方案。

本文將介紹並對比的監控解決方案包括：

● 原生Docker

● cAdvisor

● Scout

● Pingdom

● Datadog

● Sysdig

● Prometheus

● Heapster / GrafanaPingdom

● ELK

● Sensu

在本篇中將介紹前5個解決方案。

在如下章節中，我提出了一個對比監控解決方案的架構，並對每一個解決方案進行了高級對比，而後經過討論每一個解決方案將如何與Rancher協同工做，從而更詳細地討論每一個解決方案的細節。我還會在最後談談一些其它的監控解決方案，這些方案未被歸入本文的「十大」中，但你也可能遇到過。

對比架構

客觀地對比監控解決方案面臨的一個挑戰是，解決方案的架構、功能、部署模型和成本可能會有很大的差別。一個解決方案能夠從單個主機提取和繪製docker相關的數據，而另外一個解決方案則能夠從許多主機收集數據，測量應用程序響應時間，並在特定條件下發送自動警報。

在對比解決方案時，先肯定一個對比架構，將會爲後期的對比工做帶來很大幫助。我有些武斷地提出了以下圖的對比架構，以大多數監控解決方案都具備的功能層,來做爲我對比的基礎。這個對比架構能夠分爲7層：

主機代理——主機代理表明監控解決方案的「肢體」，它會從各類來源（如API和日誌文件）提取時間序列數據。主機代理一般安裝在每一個集羣主機上（不管是本地仍是雲端），而且它們一般被打包成Docker容器，以便部署和管理。

數據收集架構——雖然單主機數據有時頗有用，但管理員可能須要全部主機和應用程序的統一視圖。監控解決方案一般具有一些機制來收集每一個主機的數據，並將其保存在共享數據存儲區中。

數據存儲——數據存儲多是傳統的數據庫，但更常見的一種形式是可伸縮的分佈式數據庫，由鍵值對組成的時間序列數據進行了優化。有些解決方案具備原生數據存儲，而其餘解決方案則使用的是開源的數據存儲插件。

聚合引擎——要存儲來自數十個主機的原始數據，可能碰見的一大問題是數據量會變得過大。監控架構一般提供數據聚合功能，按期將原始數據轉換爲統一的度量標準(好比每小時或每日進行彙總)，清除再也不須要的舊數據，或以某種方式從新分解數據，以支持預期的查詢和分析。

過濾和分析——一個監控解決方案就像是你從數據中得到的洞察力。不一樣的監控解決方案之間，篩選和分析的能力經常差異很大。有些解決方案僅支持以簡單的時間序列圖表的形式來進行一些預先打包的查詢, 而另外一些則具備可自定義的儀表板、嵌入式查詢語言和複雜的分析功能。

可視化層——監控工具一般具備可視化層，用戶能夠在其中與 web 界面進行交互以生成圖表、制定查詢以及在某些狀況下定義警報條件。可視化層可能與篩選和分析功能緊密耦合, 也可能根據解決方案而與其分開。

告警和通知——不多管理員有時間成天坐着、時刻關注監控圖表。監控系統的另外一個常見特性是告警子系統，若是達到或超過了預約義的閾值，能夠向管理員發出通知。

除了解每一個監控解決方案如何實現上述基本功能以外，以下方面也是用戶在選擇監控解決方案時應該注意與考量的：

›解決方案的完整性

›是否易於安裝和配置

›關於web用戶界面的詳細信息

›是否可以將警報轉發至外部服務

›社區支持和參與程度（若該方案爲開源項目）

›Rancher應用程序目錄中的可用性

›支持監控非容器環境和應用程序

›原生Kubernetes支持（Pods、Services、Namespaces等）

›可擴展性（API，其餘接口）

›部署模式（自主託管、雲上託管）

›成本

10大監控解決方案的對比

下圖以high-level的形式展現了咱們提出的的10個監控解決方案如何對應咱們在上文提出的七層對比模型，哪些組件實現了每層功能，以及組件的所在位置。每一個框架都是極其複雜的，下圖的對比方式毋庸置疑是一種簡化，不過它也會給你們提供一個有用的視角來了解各個組件的功能。 下圖的摘要介紹了每一個監控解決方案的附加屬性。其中某些解決方案有多個部署選項，因此它們之間的對比就變得更加細微。

每一個解決方案的深刻研究

DOCKER STATS

https://www.docker.com/docker-community

Docker經過docker stats命令爲Docker主機提供了內置命令監控功能。管理員能夠查詢Docker守護進程，並獲取有關容器資源消耗數據的詳細實時信息，包括CPU和內存使用、磁盤和網絡I/O以及正在運行的進程數。Docker stats利用Docker引擎API來檢索這些信息。Docker統計信息沒有歷史概念，它只能監控單個主機，但聰明的管理員能夠編寫腳本從多個主機收集數據。

Docker stats自己用處有限，但Docker統計數據能夠與其餘數據源（如Docker日誌文件和Docker事件）結合使用，以知足更高級別的監控服務。Docker只能獲得單個主機報告的數據，因此Docker stats對於使用多主機應用程序服務的Kubernetes或對Swarm集羣進行監控的能力有限。因爲沒有可視化界面，沒有聚合，沒有數據存儲，也沒法從多個主機收集數據，因此Docker的統計數據對咱們的七層模型來講並不太適用。因爲Rancher在Docker上運行，Rancher用戶能夠自動使用基本的docker stats功能。

CADVISOR

https://github.com/google/cadvisor

cAdvisor是一個開源項目，比如 Docker stats向用戶提供關於運行容器的資源使用信息。cAdvisor最初是由谷歌開發的，用於管理其lmctfy容器，但它如今也支持Docker。做爲守護進程，它收集、彙集、處理和導出關於運行容器的信息。

cAdvisor有一個web界面，能夠生成多個圖表，可是像Docker stats同樣，它只監控一個Docker主機。它能夠做爲容器安裝在Docker machine上，也能夠在Docker主機自己上安裝。

cAdvisor自己只保留60秒的信息。須要將cAdvisor設置爲將數據記錄到外部數據存儲庫中。經常使用於cAdvisor數據的數據存儲庫包括Prometheus和InfluxDB。雖然cAdvisor自己並非一個完整的監控解決方案，但它一般是其餘監控解決方案的組成部分。在Rancher版本1.2前，Rancher在Rancher agent中嵌入了cAdvisor(用於Rancher的內部使用)，但如今已經不是這樣了。最新版本的Rancher使用Docker統計來收集經過Rancher UI公開的信息，由於它們能夠減小開銷。

管理員能夠輕鬆地在Rancher上部署cAdvisor，它是幾個綜合監控堆棧的一部分，可是cAdvisor再也不是Rancher自己的一部分。

SCOUT

http://scoutapp.com

Scout是一家總部位於科羅拉多州的公司，它提供基於雲的應用程序和數據庫監控服務，主要針對Ruby和Elixir環境。其現有的監控和警報架構使其可以監控Docker容器。

咱們提到Scout，由於以前在比較監控Docker的解決方案時就提到了它。經過靈活的告警和與第三方告警服務的集成，Scout提供全面的數據收集、過濾和監控功能。

Scout的團隊提供瞭如何使用Ruby和StatsD編寫腳本的指導，以利用Docker Stats API、Docker Event API和傳遞數據來監控這些腳本。他們還打包了一個Docker - scout容器，能夠在Docker Hub(scoutapp / Docker - scout)上使用，這就使安裝和配置scout代理變得更簡單。易用性取決於用戶是自行配置StatsD代理，仍是使用打包的docker-scout容器。

做爲一種託管雲服務，ScoutApp能夠在快速啓動並運行容器監控解決方案時省去許多麻煩。若是您正在部署Ruby應用程序或運行Scout支持的數據庫環境，使用Scout解決方案，能夠幫助您很好地整合您的Docker、應用程序和數據庫級別的監控。

可是，用戶可能須要注意一些事項。在大多數服務級別上，該平臺只容許保留30天的數據，而不是每一個被監控的主機。至於價格，每個月訂價的標準套餐價格從99美圓到299美圓不等。這一開箱即用的解決方案只能提取和傳遞有限的指標，也不太適用於Kubernetes相關的監控。此外，雖然docker-scout在Docker Hub上可用，但開發是由Pingdom完成的，在過去的兩年中，Scout的代理組件只有很小的更新。

Rancher自身並不默認原生支持Scout，但因爲Scout是雲服務，因此它在Rancher中很容易部署和使用，特別是當使用基於容器的代理時。目前，docker-scout代理不在Rancher應用程序目錄中。

PINGDOM

http://pingdom.com

上文中咱們提到Scout做爲雲託管的應用程序，所以還須要提到一個相似的解決方案，稱爲Pingdom。Pingdom是由德克薩斯州奧斯汀市的SolarWinds公司運營的託管雲服務，它是一家專一於監控IT基礎架構的公司。Pingdom的主要用例是網站監控，做爲服務器監控平臺的一部分，Pingdom提供了大約90個插件。事實上，Pingdom維護docker-scout，一樣地，Scout也使用 StatsD代理。

Pingdom值得關注的緣由在於，它靈活的訂價方案彷佛更適合監控Docker環境。用戶能夠根據計劃收集到的StatsD數據數（每10個數據每個月要價1美圓）在基於每一個服務器的計劃之間進行選擇。Pingdom易於設置和管理，對於須要一個完整的監視解決方案的用戶以及但願監控容器管理平臺以外的其餘服務的用戶而言，Pingdom很是合適。像Scout同樣，Pingdom是一種雲服務，而且易於同Rancher結合使用。

DATADOG

https://www.datadoghq.com/

Datadog是另外一個相似於Scout和Pingdom的商業託管雲監控服務。 Datadog還提供了一個Dockerized agent，用於在每一個Docker主機上進行安裝；然而，Datadog並無像前面提到的雲監控解決方案那樣使用StatsD，而是開發了一種加強的StatsD，稱爲DogStatsD。Datadog代理收集並傳遞Docker API提供的完整數據，從而進行更詳實、細緻的監控。

雖然Datadog不能原生支持Rancher，可是Rancher UI中有Datadog目錄，用戶能夠在Rancher上輕鬆地安裝和配置Datadog agent。用戶還可使用Rancher 標籤，Datadog中的報告反映了您在Rancher中用於主機和應用程序的標籤。與前面提到的雲服務相比，Datadog可以提供更好的數據訪問權限和更精細的定義警報條件。與其餘服務同樣，Datadog也可用於監視其餘服務和應用程序，並擁有超過200個集成的庫。Datadog還能保留18個月的全分辨率數據，這比雲服務要更長。

與其餘雲服務相比，Datadog的優點在於它具備超越Docker的集成功能，而且能夠從Kubernetes、Mesos、etcd和其餘在您的Rancher環境中運行的服務中收集數據。對於在Rancher上運行Kubernetes的用戶來講，這種多功能性是很重要的，由於他們但願可以監控諸如Kubernetes pods、服務、名稱空間和kubelet health之類的數據。Datadog-Kubernetes監控解決方案經過Kubernetes中的DaemonSets，可以自動將數據收集代理部署到每一個集羣節點。

Datadog的訂價爲每臺主機每個月約15美圓，總價會根據用戶須要的服務和每一個主機監控的容器數量相應增長。

結語

在下篇文章中，咱們將繼續對比另外五大監控方案：Sysdig、Prometheus、Heapster/GrafanaPingdom、ELK和Sensu，敬請保持關注。