概要
運用監視ツールの比較検討をして、ZABBIXからPrometheusへ移行することにしました。
その経緯を書きます。
現状
弊社ではAWSやさくらのクラウド、ConoHaのクラウドなど様々なIaaS/VPSを使って暮らしニスタやMillyなどのサービスを展開しています。 監視対象VM数は170台程度です。
抱えていた課題
重い
- 監視対象が増えるにつれて重くなってきて、素早く情報を見たい時にストレスになっていました。
- ZABBIXのDBはMySQLを使っていましたがパラメータチューニングが必要で、運用に手間がかかっていました。
サポート切れ
- ZABBIXサーバのバージョンが2.2で、サポート期限の終了が2019年8月と近づいてきていました。 （詳細は公式情報をご覧になってください）
スクリーン作成の難しさ
- ZABBIXはグラフをまとめたものをスクリーンと呼んでいるのですが、スクリーン作成のGUIの癖が強く、学習コストがかかっていました。
候補の紹介
OSSで無償利用できる監視ツールの中から、以下の3つが候補に挙がりました。
ZABBIX 4.0
統合監視ツールの決定版！ZABBIXです。
基本的には監視対象にエージェントと呼ばれるアプリケーションを入れて、ZABBIXサーバ側で監視項目を設定してエージェントにデータを集めてもらいます。
非常に多機能で、運用監視ツールに必要な大抵のことは出来ます。５~6年ZABBIXを使った個人的経験で言うと、ZABBIXで出来なかったことはありません。
候補に選んだのは執筆時点で最新版のZABBIX4.0です。痒い所に手が届くたくさんの新機能があり、中でも以下の新機能はよいと感じました。詳細は公式情報 Zabbix 4.0の新機能
をご覧になってください。
- ZABBIXプロキシとの通信量を圧縮
- エージェントの自動登録機能を改善し、ホストメタデータが変更された場合は自動登録処理を再度実行するようになった。
- ヒストリデータをElasticsearchへ保存することができるようになった。
- アイテムとローレベルディスカバリルールの監視データ取得を今すぐ実行するボタンを追加。
また、2.2からの4.0から直接アップグレードが可能なため、移行コストが他の2つより圧倒的に低いのも魅力でした。
Prometheus
OSSの管理ツールで、もともとはSoundcloud社が社内向けに開発したものです。（公式サイト）
以下のような特徴があります。
- メトリック名とkey/valueの組み合わせによる多次元な時系列データモデル
- PromQLという、柔軟なクエリ
- 分散ストレージを使わず、それぞれのノードが自律的に動いている
- 監視対象にexporterというエージェントを入れて、そこに対してHTTPでpullして時系列データを収集
- 間にゲートウェイを置いた状態での、時系列データのプッシュもサポート
- 監視対象は静的なconfigか、サービスディスカバリで発見
- 様々なグラフやダッシュボードをサポート
Prometheus Server単体では障害発生時にメールを送る機能もなく、それはAlertmanagerという別コンポーネントを使うことになります。 ユーザ認証機能もないので、必要な場合はRプロキシを前段においてBasic/LDAP認証させるような仕組みも別途必要になります。
All in One なZABBIXとは違った思想で作られているようです。構成図は以下のようになります。
Prometheus Server 単体だけだと味気のないグラフのみなので、Grafanaと組み合わせて使うことが推奨されています。 監視データを貯めるハコと割り切って使った方がよさそうです。
Grafanaと組み合わせることで以下のように奇麗なダッシュボードを作ることができます。
Sensu
「Sensu」は、Sensu,Inc が開発している、「Ruby」製のオープンソース監視プラットフォームです。
以下のような特徴があります。
- Ruby ＋ RabbitMQ ＋ Redis で構成される
- クライアントを追加する際は、サーバ側での設定は不要です。
- エージェントが送ってきたデータはRedisに格納されます。
- 下の図の通り、サーバ-クライアント間に、RabbitMQを介してやり取りすします。
いざ比較（予選）
VM上に各環境を作成しながら検証を進めていたのですが、Sensuに新たな事実が発覚しました。
Sensu 2.0 がベータ版まで出ていて、構成が大きく変わる可能性があるということです。（参考： Sensuの“これまで”と“これから”：Sensuで始めるクラウド時代のシステム監視（10） - ＠IT）
せっかく移行しても、すぐに1系⇒2系への移行になるかもしれず、導入は断念しました。
エージェントの設定さえしてしまえば、サーバ側での登録作業が不要なところは非常に魅力的でした。
プロダクトの優劣ではなく、タイミングが合わなかったです。残念。
いざ比較（決勝）
ZABBIXとPrometheusの比較となりました。
独自の観点で比較し、結果を表にまとめると以下のようになりました。
| 観点 | ZABBIX | Prometheus |
|---|---|---|
| 性能 | 〇 | ◎ |
| 拡張性 | △ | 〇 |
| 保守性 | △ | △ |
| 移行性 | 〇 | △ |
| セキュリティ | 〇 | △ |
| 環境変更への追従性 | △ | 〇 |
| APIなどのエンドポイント監視 | 〇 | ◎ |
詳細を以下に記載します。
性能
- ZABBIX
- RDBMSにデータを格納しているため、重くなることがある
- 画面表示が遅い
- Prometheus
- 時系列DBにデータを格納し、I/Oが速い
- Grafana経由になるが、画面表示は軽快
【ZABBIXについて追記】
- Zabbix plugin for Grafana | Grafana Labsを使うことでZABBIXのデータをGrafanaで軽快に見ることができます。
- ZABBIX 4.2ではTimescaleDBという、PostgreSQLの時系列データ向け拡張機能をサポートする予定です。
拡張性
保守性
- ZABBIX
- 監視対象の増加に伴い、DBが重くなることがある
- スクリーンやグラフの作成がやりにくい
- 性能維持のため、RDBの監視やチューニングが必要
- Prometheus
- データの長期保存を前提としていないので、別途長期保存用のサーバが必要
- Grafanaの機能で、グラフやダッシュボードの作成が容易
移行性
- ZABBIX
- 公式に移行手順を公開している
- 後方互換性も高い
- Prometheus
- ZABBIXに比べて歴史が浅いので単純比較出来ないが、1.x⇒2.xへの公式手順を公開している
セキュリティ
- ZABBIX
- ID/PASSがないとログインできず、データもRDBに入っているので容易にアクセスできない
- Prometheus
- ID/PASS無しのWEBアクセスでデータの閲覧や監視の無効化ができてしまうので、接続制限やBasic認証などの仕組みが必要
監視ツールとして
環境変更への追従性
- ZABBIX
- ホスト自動登録の仕組みはあるが、エージェントにZABBIXサーバの所在地を仕込んでおく必要がある
- APIを使った作りこみをすれば、ホストの自動削除が可能
- Prometheus
APIなどのエンドポイントのHTTP監視
- ZABBIX
- WEBという機能で、監視対象ホストのエンドポイントのHTTP監視ができる
- Prometheus
比較した結果
最終的にPrometheusを採用しました。操作の軽快さと環境変更への追従性、エンドポイント監視の柔軟性がポイントになりました。
また、新しい技術にチャレンジしたいというのも動機としては大きいです。
決してZABBIXが劣っているわけではありません。日本での導入事例も豊富ですし、通常の運用監視においてZABBIXに出来ない事はありません。PrometheusにできてZABBIXにできないこともありません。
PrometheusはZABBIXに比べて日本語情報が乏しいため導入や運用はZABBIXに比べて障壁が高く、今回とは違い検証や移行にコストをかけられないのであれば、迷わずZABBIXを選んでいたと思います。
今後
移行ツールも機能もないので、新規にPrometheusサーバを構築し、監視対象を登録していく作業をしています。
何か皆さんにお知らせできることがあれば、随時公開していきます。
※ご指摘を頂き、公開時から一部加筆修正を行いました。ご指摘頂きありがとうございました。
