Comparing 10 Docker Container Monitoring Solutions for Rancher（第三章）
10個コンテナ監視ソリューション比較（第三章）
今回、最後の第三章では、残りのPrometheus、Heapster / Grafana (deprecated)、ELK stack、
Sensuと１０個以外のその他のモニタリングソリューションについて詳しく見ていきたいと思います。
Prometheus
Prometheus は有名なオープンソースモニタリング、アラーティングツールで、SoundCloudでオリジナルで構築されました。これは現在ではCNCFプロジェクトで、Kubernetesのその次にホストされたプロジェクトです。
Prometheus はツールキットとして、実際は今までご紹介してきたモニタリングソリューションとはまた異なるものです。まず1点目の異なる点としては、クラウドサービスとして扱われているというよりもむしろ、Prometheusはモジュラーで、自分でホストされる(セルフホスティング)です。オンプレミスでも、cloud-residentでも自分のクラスタ上にPrometheusをユーザーがデプロイするという意味です。クラウドサービスにデータをプッシュする代わりに、PrometheusはそれぞれのDockerホスト上でインストールし、HTTPを通してPrometheusへ多種多様なエクスポーターからデータをプルするか、もしくは「スクレープ」します。Prometheus GitHubプロジェクトの一部として公式に保持されているエクスポーターもあります。一方で、他のエクスポーターは外部のcontributionになります。Prometheusメトリックをネイティブにエクスポーズするプロジェクトもあるので、エクスポーターは必要ありません。
Prometheusはとても拡張性が高いものです。ユーザーはエクスポーターの数を管理する必要があり、収集しているデータ量により、適切にポーリング間隔をコンフィギュアしなければいけません。Prometheusサーバーは、時系列データを色々なソースから取得し、内部のデータストアにデータを保存します。
Prometheusはサービスリカバリや特定のタイプのメトリックのための別々のプッシュゲートウェイのような特徴を持っています。そして、クエリをかけている多次元データを得意とするクエリランゲージ（PromQL)を埋め込んでいます。またウェブUI とAPIも持っています。Prometheusの中にあるそのウェブUIの機能は優れていますが、ユーザーのPromQLに関する知識によります。なので、チャートやクラスタ関連のメトリックを参照するためのインターフェイスとしてはGrafanaを好む人もいます。PrometheusはPrometheusの中に保存されたデータと機能する別のUIを持つ別個のアラートマネージャーを持っています。そのほかのアラートマネージャーのように、email, Hipchat, Pagerduty, Slack, OpsGenie, VictorOpsなどの様々な外部のアラートサービスと機能します。
Prometheusは多くのコンポーネントで構成されており、エクスポーターはモニターされているサービスに応じて選ばれたりインストールされたりする必要があるので、インストールするのが少し難しいかもしれません。しかし、無料で提供されているため、価格はとても安価です。DatadogやSysdigなどのツールのように優れたツールではありませんが、Prometheusは同じような機能や、広域のサードパーティのソフトウェア インテグレーションを提供してくれる、そのクラスでは最高のクラウドモニタリングソリューションです。
PrometheusはKubernetesや他のコンテナ管理のフレームワークと相性がよいです。Rancher Catalogの中のエントリーのおかげでPrometheusをより簡単にスタートできます。もう少し上を目指しているアドミニストレーターにとっては、Prometheusはとても優れたモニタリングソリューションの1つであり、選択肢の1つとして入れておくべきツールです。
Heapster (deprecated)
Heapsterはモニタリングコンテナ環境について話をする場合にはよく話題にあがるソリューションの1つです。しかし、この記事が出る頃にはHeapsteは、HeapsteはKubernetesプロジェクトによって廃止されている可能性もあります。.KubernetesはHeapsterに代わるツールとして以下のツールの組み合わせを推奨しています。
- metrics-server:基本的なCPU/メモリHPAメトリックのため
- Prometheus operator: もしくは一般的なモニタリングを行うためのPrometheusでフォーマットされたメトリックを収集するどのパイプラインでもよい
- eventrouter: Kubernetesイベントを移動するため
コンテクストとリファレンスのためにそのままの情報を以下に掲載しておきます。
HeapsterはKubernetes傘下のプロジェクトでした。有効なコンテナクラスタのモニタリングを助けたりパフォーマンス分析を行ったりしていました。Heapsterは特にKubernetesやOpenShiftをサポートしていました。Heapsterをモニタリングソリューションだという人もいますが、より正確に言えば、「クラスタワイドなモニタリングやイベントデータのアグリゲータ」なのです。Heapsterは単独でデプロイされることはありません。むしろ、オープンソースのコンポーネントのスタックの一部なのです。Heapsterのモニタリングスタックは、典型的には以下のもので構成されています。
- A data gathering tier:例えばそれぞれのクラスタホスト上でkubeletにアクセスしたcAdvisor
- Pluggable storage backends: 例えば、ElasticSearch, InfluxDB, Kafka, Graphiteまた 他の数多くのもの
- A data visualization component: Grafana もしくは Google Cloud Monitoring
人気のスタックはHeapster, InfluxDB, Grafanaから成り立っていました。この組み合わせはユーザーがKubernetesをデプロイすることを選択したときから、Rancherでデフォルトでインストールされていたものです。それらのコンポーネントは、Kubernetesへのアドワンとされていました。それで、それらのコンポーネントは自動的に全てのKubernetes distributionを伴ってデプロイされることはありませんでした。
InfluxDBがHeapsterに人気だったその理由の一つには、それがKubernetesのイベントとメトリックの両方をサポートする数少ないデータバックエンドの1つだっただからです。より総括的なKubernetesのモニタリングをしてくれます。HeapsterはネイティブでアラーティングやPrometheus や商業的なクラウドベースのソリューションにあるApplication Performance Management (APM)に関連したサービスをサポートしていませんでした。モニタリングサービスが必要であったユーザーが、Hawkularを使ってHeapsterのインストールをする手助けをすることができました。
ELK Stack
モニタリングコンテナ環境で使用できるその他のオープンソースのソフトウェアスタックとしては、ELKが挙げられます。Elasticによる３つのオープンソースプロジェクトで構成されています。ELKスタックは、多機能で、分析のためのアプリケーションや主要なログファイルモニタリングなどに幅広く使用されます。ELKはその主なコンポーネントから命名されました。
- Elasticsearch: Luceneが基本となっている分配されたサーチエンジン
- Logstash:エータを収集し、そしてそれをElasticsearchへ（もしくは他の「stash」へ）送るデータ加工パイプライン
- Kibana: Elasticsearchのためのビジュアル検索ダッシュボードと分析ツール
Elasticスタックの中でもあまり知られていないのが、Beatsです。「軽量のデータシッパー（送付人）」とプロジェクトの開発者たちに呼ばれています。様々な種類の既製品のBeatsがあり、Filebeat (ログファイルに使われる)、Metricbeat(色々なソースからデータメトリックを収集するためのもの)、シンプルなuptimeモニタリングのための Heartbeatなどを含みます。MetricbeatはDocker-awareです。その制作者はDockerコンテナの中のホストメトリックとモニターサービスを抽出するための使い方を こちらのガイダンスで公開しています。
ELKスタックをデプロイする方法はいくつかあります。KiratechのLorenzo Fontana氏は、ElasticSearchのストレージに対するメトリックを収集するためにcAdvisorを使う方法やKibanaを使って分析する方法をこの記事で説明しています。 他の記事では、Aboullaite Mohammed氏がDockerログファイルを収集することにフォーカスした異なる使用例や、色々なDockerやNginxログファイル(error.log, access.log, and syslog)を分析する使用例を解説しています。商業的なELKスタックを提供するlogz.ioや Elastic のような「サービスとしてのELK」というのを打ち出しているプロバイダーも色々あります。アラーティング機能を伴うスタックの機能を補足するのです。Dockerを伴ったELKの追加情報に関しては、こちらをご覧ください。
Rancherユーザーにとって、関連のあるEFKスタック（Elasticsearch, Fluentd, Kibana）はRancher Catalog entryとして使用可能です。博識なアドミニストレーターはElasticベースのスタックをコンテナモニタリングのために使用しますが、Sysdig, Prometheus, Datadogなど他のソリューションに比べると実行するのがもっと難しいソリューションになります。Sysdig, Prometheus, Datadogなどは全てコンテナモニタリングを直接的な目的としているソリューションです。
Sensu
Sensu は多目的で使用でき、セルフホスティングされているモニタリングソリューションであり、色々なモニタリングアプリケーションをサポートしています。無料のSensu Coreエディションは、MITライセンスにおいて使用可能ですが、機能が追加されたエンタープライズバージョンはそれなりの価格になっています。Sensuはそのモニタリングエージェントを参照するためのタームクライアントを利用します。あなたがモニタリングしているホストの数やアプリケーション環境によっては、エンタープライズバージョンでは料金が高額になることもあります。
Sensuはコンテナマネージメント以外では、すばらしい機能を持っています。しかし、他のプラットフォームと同じように、私たちはSensuをコンテナ環境のモニタリング、またコンテナ化されたアプリケーションという観点で見てきました。Sensuプラグインの数は増加し続けています。そして、Sensuとプラグインをサポートしていたコミュニティが存在し、メトリックが色々なソースから抽出されるようになりました。
2015年のRancherでのSensuの初期の改善ですが、Dockerから情報を抽出するシェルスクリプトを開発する必要がその開発者にはありました。しかし、積極的に開発されたDocker プラグインは今、SensuをRancherと共により簡単に使用できるようにするという目的で利用可能です。プラグインは、Dockerホスト上で走る必要のあるgemベースのインストール スクリプトを伴うRuby で書かれることになっています。ユーザーは自分が選んだ言語で追加するプラグインを開発することができます。Sensuプラグインは、私が今まで説明してきた他のソリューションと同じく、それ自身のコンテナではデプロイされません。（これは、Sensuがモニタリングコンテナから受け継がれてきていないからでしょう）
モニタリングの必要条件によって、プラグインをマッチしたりミックスしたりしたいと思っているユーザーもいます。そして、それぞれのプラグインのために別々のコンテナを持つことは色々と面倒です。しかし、プラグインはChef, Puppet, Ansibleのようなプラットフォームを用いてデプロイ可能です。例えばDockerだけのことを考えれば、 docker stats, container counts, container health, docker psなどを含む色々なソースからDocker関連のデータを収取する 6つの別々のプラグインがあります。
プラグインの数は物凄く多く、ユーザーがコンテナ環境で(ElasticSearch, Solr, Redis, MongoDB, RabbitMQ, Graphite, Logstashなどなど)走らせがちな多くのアプリケーションスタックを含みます。AWSサービス(EC2, RDS, ELB)のようなマネージメントのためのプラグインやオーケストレーションフレームワークもまたSensiが備わっています。
Sensuはエージェント/クライアントとSensuサーバー間のコミュニケーションを円滑にするためにRabbitMQを使って実行されるメッセージ バスを利用します。Sensuはデータを保存するためにRedisを使いますが、外部の時系列データベースへデータを送るためにデザインされたものです。サポートされているデータベースの中にはGraphite, Librato, InfluxDBがあります。Sensuはお話したようにコンテナと相性のよいデプロイメントモデルではありません。
Sensuには数多くの特徴がありあすが、コンテナユーザにとっての欠点は、フレームワークをインストールやコンフィギュアしたり、維持などをするのが難しいという点です。というのもそのコンポーネント自体がDockerに対応していないからです。また、Sensuエンタープライズのライセンスを購入する必要のあるPrometheusのようなオープンソースのソリューション、もしくはクラウドベースのソリューションで利用可能な例えばPagerDuty, Slack, or HipChatのようなアラートをサービスへ送るようなアラーティング機能もたくさんあります。
Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。
