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

容器監測環境有多種形态和大小。有些是開源的，而另一些則是商業性質的。有些可以借助平台一鍵部署（例如在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，敬請保持關注。

版權聲明：原創作品，如需轉載，請注明出處。否則将追究法律責任

本文轉自 RancherLabs 51CTO部落格，原文連結:http://blog.51cto.com/12462495/2071624