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

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

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/。

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服務（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的對比方法，希望可以幫助您 “縮小清單”，針對自身需求進行更認真的評估，進而選出最适合的解決方案。

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