容器領域的十大監控系統對比（下）

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

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

SYSDIG

http://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

http://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

https://github.com/kubernetes/heapster

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

https://www.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進行分析：https://blog.codeship.com/monitoring-docker-containers-with-elasticsearch-and-cadvisor/。 在另外一篇文章中，Aboullaite Mohammed描述了一個不一樣的用例，其重點是收集Docker日誌文件，分析各類Linux和NGINX日誌文件（error.log、access.log和syslog）：https://aboullaite.me/docker-monitoring-with-the-elk-stack/。 有些商用ELK棧提供者，例如logz.io和Elastic Co，向用戶提供「ELK即服務」，在原生ELK以外補充提供了告警功能。有關在Docker上使用ELK的更多信息，請訪問https://elk-docker.readthedocs.io/。

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

SENSU

http://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服務（EC二、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的對比方法，但願能夠幫助您 「縮小列表」，針對自身需求進行更認真的評估，從而選出最適合的解決方案。