容器監測環境有多種形態和大小，而監控解決方案的數量之多亦令人望而生畏。在這一系列文章中，我將對容器領域的10個監控解決方案進行全面的分析對比。

上篇文章中，我介紹了此次對比測評的方法架構，並分析了五種容器監控解決方案：原生Docker、cAdvisor、Scout、Pingdom和Datadog。本文我們將繼續完成另外五種容器監控解決方案的對比：Sysdig、Prometheus、Heapster / GrafanaPingdom、ELK和Sensu。

SYSDIG

sysdig.com

Sysdig是一家加州公司，為用戶提供基於雲計算的監控解決方案。與前文所描述的幾個基於雲的監控解決方案不同的是，Sysdig更專註於監控容器環境，包括Docker、集群、Mesos和Kubernetes。此外，Sysdig還在開源項目中提供了一些可用功能，並且可以選擇對Sysdig監控服務進行雲部署還是本地部署。在這些方面，Sysdig不同於迄今為止所出現的其他基於雲的解決方案。

Sysdig，與Datadog類似，其目錄可用於Rancher，但Sysdig的本地和雲安裝都有單獨目錄。從Rancher Catalog里自動安裝的Sysdig無法用於對Kubernetes的監控；不過，它也可以不通過Rancher Catalog來安裝到Rancher之上。商用Sysdig監控具有Docker監控、告警和故障排除功能，並且還具有 Kubernetes、Mesos和集群識別的功能。Sysdig能夠自動識別Kubernetes Pod和服務，因此選擇Kubernetes作為Rancher的編排架構將是一個很好的解決方案。

Sysdig和Datadog一樣是按每個主機每月定價。雖然Sysdig入門價格略高，但它每個主機上可以支持更多容器，因此根據用戶的環境，實際定價可能非常相似。 Sysdig還提供了一個全面的CLI——csysdig，將其與一些產品區分開來。

PROMETHEUS

prometheus.io

Prometheus是一個很受歡迎的開源監控和警報工具包，它最初是在SoundCloud進行構建的。現在是CNCF項目，也是該公司在Kubernetes之後的第二個託管項目。作為一個工具包，它與目前為止所描述的其他監視解決方案有很大不同。首先一個主要的區別是，Prometheus，作為一種雲服務，是模塊化的，可以自行託管，這意味著無論是在本地還是在雲端，用戶都可以在他們的集群上部Prometheus。

值得注意的是，Prometheus不是將數據推送到雲服務，而是安裝在每個Docker主機上，並通過HTTP從Prometheus提供的各種輸出口獲取或「抓取」數據。其中，一些輸出口被官方保留為Prometheus GitHub項目的一部分，而另一些則是由外部貢獻。有些項目本身暴露了Prometheus數據，因此不需要輸出口。由於Prometheus可高度擴展，用戶需要考慮輸出方的數量，並根據收集的數據量適當地配置輪詢間隔。

Prometheus的伺服器從各種來源檢索時間序列數據，並將數據存儲在其內部數據存儲區中。此外，Prometheus提供服務發現等功能，這是一種針對特定類型數據的獨立推送網關，並且有一個嵌入的查詢語言(PromQL)，該語言擅長查詢多維數據。同時，它也有一個嵌入式的Web UI和API。雖然Prometheus中的Web UI提供了強大的功能，但用戶必須對PromQL十分了解，因此一些站點更願意使用Grafana作為繪製和查看集群相關指標的介面。

Prometheus有一個獨立的告警管理器，它也具有獨特的UI，並且可以處理存儲在Prometheus中的數據。和其他告警管理器一樣，它可以與各種外部告警服務一起工作，包括電子郵件、Hipchat、Pagerduty、#Slack、OpsGenie、VictorOps等。

由於Prometheus由許多組件組成，輸出方需要根據所監控的服務進行選擇和安裝，所以安裝起來比較困難，但是作為免費產品，在價格上Prometheus具有無可比擬的優勢。

雖然不像 Datadog或 Sysdig這樣精鍊，但是Prometheus提供了類似的功能、廣泛的第三方軟體集成以及一流的雲監控解決方案，並且Prometheus十分了解 Kubernetes和其他容器管理架構。另外，由Infinityworks開發的Rancher Catalog中的條目使得在使用Cattle作為Rancher的編排架構時，Prometheus更容易入門，但由於配置選項的種類繁多，管理員需要花費一些時間才能正確安裝和配置。

Infinityworks提供了一些有用的插件，其中包括prometheus-rancher-exporter，這些插件將Rancher stack和從Rancher API獲得的主機的健康狀況發送給Prometheus兼容端點。因此，Prometheus對於那些願意花更多精力的管理者來說是最強大的監控解決方案之一。

HEAPSTER

github.com/kubernetes/h

Heapster是Kubernetes旗下的一個項目，它有助於實現容器集群監控和性能分析。此外，Heapster對Kubernetes和OpenShift的支持十分良好，也很適用於在Rancher上使用Kuberenetes作為編排工具的用戶。Cattle或者Swarm的用戶則通常不會選擇它。。

人們經常將Heapster定義為一個監控解決方案，但更確切地說，它應該是一個「集群範圍內的監控和事件數據聚合器」。Heapster從來不單獨部署，相反，它是一堆開源組件的一部分。Heapster監控堆棧通常由以下部分組成：

>數據收集層：例如，在每個集群主機上使用kubelet訪問的cAdvisor

>可插入式存儲後端：例如，ElasticSearch、InfluxDB、Kafka、Graphite等

>數據可視化組件：Grafana或Google Cloud Monitoring

Heapster與InfluxDB、Grafana共同組成了一個流行的堆棧，當用戶在Rancher上部署Kubernetes時，此組合便會默認安裝在Rancher上。需要注意的是，這些組件被認為是Kubernetes的附加組件，因此它們可能不會被自動部署到所有Kubernetes發行版中。

InfluxDB受歡迎的其中一個原因是，它是少數幾個支持Kubernetes項目和數據的數據後端之一，並且可以對Kubernetes進行更全面的監控。

值得注意的是，Heapster本身不支持在商用雲的解決方案或Prometheus中發現的與應用程序性能管理（APM）相關的告警或服務。需要監控服務的用戶可以使用Hawkular來彌補這一不足，不過Hawkular並不會自動配置為Rancher部署的一部分，而是需要用戶另行操作。

ELK STACK

elastic.co/

另一個可用於監視容器環境的開源軟體棧是ELK，由Elastic提供的三個開源項目組成。ELK是通用的，廣泛用於各種分析應用程序，日誌文件監控是其中關鍵的一環。ELK以其關鍵組件的首字母命名:

>Elasticsearch：基於Lucene的分散式搜索引擎

>Logstash：一個數據處理管道，用於獲取數據並將其發送到Elastisearch（或其他「托盤」）

>Kibana：Elasticsearch的可視化搜索儀錶板和分析工具

Elastic棧中一個容易被忽視的成員是Beats，項目開發人員將其描述為「輕量級數據託運器」。現在有許多現成的Beats託運器，包括Filebeat（用於日誌文件）、Metricbeat（用於收集各種來源的數據）以及用於簡單的uptime監控等。

ELK棧的部署方式有所不同。Kiratech的Lorenzo Fontana在這篇文章中解釋了如何使用cAdvisor從Docker Swarm主機收集數據以存儲在ElasticSearch中，並使用Kibana進行分析：blog.codeship.com/monit。在另一篇文章中，Aboullaite Mohammed描述了一個不同的用例，其重點是收集Docker日誌文件，分析各種Linux和NGINX日誌文件（error.log、access.log和syslog）：aboullaite.me/docker-mo。有些商用ELK棧提供者，例如logz.io和Elastic Co，向用戶提供「ELK即服務」，在原生ELK之外補充提供了告警功能。有關在Docker上使用ELK的更多信息，請訪問elk-docker.readthedocs.io。

對於希望嘗試使用ELK的Rancher用戶，它在Rancher Catalog中已有條目，《如何在Rancher上運行Elasticsearch》一文介紹了如何在Rancher Catalog中部署ELK。《使用容器和Elasticsearch集群對Twitter進行監控》一文介紹了如何使用ELK監控Twitter數據。儘管博洽多聞的管理員可以使用ELK進行容器監控，但與Sysdig、Prometheus或Datadog等直接針對容器監控的解決方案相比，ELK的上手和使用難度都會更大。

SENSU

sensuapp.org

Sensu是一個通用的自主監控解決方案，支持多種監控應用。用戶可在MIT許可下獲得一個免費的Sensu Core版本，Sensu的企業版則擁有更多的附加功能，價格為每月99美元，可以為50個Sensu客戶端提供服務。Sensu使用術語「客戶端」來指代其監控代理，因此根據您監控的主機和應用程序環境的數量，企業版可能會變得非常昂貴。Sensu在容器管理之外還擁有非常強大的功能，但就監控容器環境和容器化應用程序這方面來看，它與其他平台並無差別。

Sensu插件的數量持續增長，現在已有數十個Sensu和社區支持的插件可以從各種來源提取數據。2015年Rancher對Sensu進行早期評估時，那時Sensu用戶要從Docker中提取信息，需要開發shell腳本。但是現在，Sensu已經有了一個不錯的Docker插件，這使得Sensu更易於使用了。

插件往往是用Ruby編寫的，使用基於gem的安裝腳本，這些腳本需要在Docker主機上運行。用戶可以在他們選擇的語言中開發額外的插件。與我們討論過的其他監控解決方案相同的是，Sensu插件不是部署在自身容器中。(這一點毫無疑問，因為Sensu並非在監控容器的基礎上構建的。)

由於不同的用戶希望根據自己的監控要求混合和匹配插件，因此為每個插件設置單獨的容器將會非常棘手，這可能是為什麼不使用容器進行部署的原因。不過，插件可以使用Chef、Puppet和Ansible等平台進行部署。例如，對於Docker來說，有6個獨立的插件可以從各種來源收集與Docker相關的數據，包括Docker統計信息、容器數量、容器運行狀況、Docker ps等等。Sensu插件的數量非常多，包括許多用戶可能在容器環境（ElasticSearch、Solr、Redis、MongoDB、RabbitMQ、Graphite和Logstash等）中運行的應用程序棧。此外，Sensu還提供用於管理和編排架構的插件，如AWS服務（EC2、RDS、ELB）。但是在插件列表中，Kubernetes似乎消失了。但是Sensu提供對OpenStack和Mesos的支持。

Sensu通過RabbitMQ使用消息匯流排，以協助代理/客戶端與Sensu伺服器之間的通信。Sensu用 Redis存儲數據，但它的設計目的是將數據路由到外部的時間序列資料庫。支持的資料庫包括Graphite、Librato和InfluxDB。

安裝和配置Sensu需要花點功夫。安裝Sensu前必須先安裝Redis和RabbitMQ。 Sensu伺服器、Sensu客戶端和Sensu儀錶板需要單獨安裝，並且根據部署的是Sensu內核還是企業版本，流程也會有所不同。如前所述，Sensu不提供容器友好的部署模型。為了方便起見，可以使用Docker鏡像(hiroakis／Docker-sensu-server)運行redis、rabbitmq-server、uchiwa(開源web層)和Sensu伺服器組件，但在評估上，這個軟體包比生產部署更有用。

Sensu的特性非常多，但對容器用戶而言，它的缺點是架構很難安裝、配置和維護，因為這些組件本身沒有被Docker化。此外，許多告警功能（例如發送警報給諸如PagerDuty，Slack或HipChat等服務）可以在基於雲的解決方案或像Prometheus這樣的開源代碼解決方案中使用，因此需要購買Sensu企業版許可。特別是若你使用Kubernetes，可能Sensu不是最好的選擇。

我們忽略的監控解決方案

Graylog是另一個監控Docker的開源解決方案。和ELK一樣，Graylog也適用於Docker日誌文件分析。它可以接受和解析來自多個數據源的日誌和事件數據，並支持像Beats、Fluentd和NXLog這樣的第三方收集器。

Nagios通常被認為更適合於監控集群主機而不是容器，但對於那些在監控集群環境中浸淫已久的人來說，Nagios最受歡迎。

Netsil是一家矽谷初創公司，作為一個監控應用程序，它為Docker、Kubernetes、Mesos以及各種應用程序和雲提供商提供插件。Netsil的應用運營中心（AOC）與我們討論的其它監控架構一樣，以雲/SaaS或自主託管的形式為雲應用服務提供架構感知監控。

結語

容器監控解決方案很多，新的解決方案不斷湧現，同時現有的解決方案不斷發展。此次我們採取了high-level的對比方法，希望可以幫助您 「縮小列表」，針對自身需求進行更認真的評估，從而選出最適合的解決方案。

【作者簡介】

Gord Sissons，加拿大多倫多諮詢公司StoryTek的首席顧問。Gord在HPC、大數據和集群管理等領域擁有超過25年的IT行業經驗。他畢業於安大略省渥太華的卡爾頓大學，擁有系統和計算機工程學位。

關注公眾號RancherLabs，了解更多信息噢～


推薦閱讀：
相关文章