監視システムの比較：Shinken対Sensu対Icinga 2対Zabbix

しんけん

公式ウェブサイトによると、Shinkenは監視フレームワークです。 Nagios CoreによりPythonでゼロから書き直され、大規模環境のサポートが改善され、柔軟性が向上しました。

拡張性

ドキュメントによると、使用されるプロセスの各タイプは、別々のホストで実行できます。 これは非常に便利な機能です。最も安価な場所にデータベースを配置し、各データセンターで情報収集プロセスを行い、物理的な場所により近い通知プロセスを使用することができます。 図のユーザーShinkenは幸せです。これは間違いなく良い兆候です。

このシステムには、 Realmsと呼ばれる地域間監視用の既成の構成もあります。

ここで、驚くべきことに気付くことができます。情報は、1つのマスターデータベースではなく、地域のデータベースで収集されます。 また、小規模な分散構成用のスフィアを備えた小規模バージョンの構成もあります。インストールには、1つのデータベースと複数のホストのみが必要です。

スケーラビリティの評価におけるもう1つの問題点は、フォールトトレランスです。 ドキュメントからこの情報を引用します。

誰も完璧ではありません。 サーバーはアプリケーションと同じようにクラッシュする可能性があるため、管理者はなりすましをします。落ちたアイテムの構成を取得して、それらを再度持ち上げることができます。 現時点では、代替のない唯一のプロセスは仲裁人ですが、将来的には最終決定されます。 armiberは、他のすべてのプロセスが使用可能かどうかを定期的にチェックし、スケジューラーまたは別のプロセスが停止している場合、管理者が定義した別のノードに構成を送信します。 すべてのプロセスにこの変更が通知されるため、新しいノードを使用してプロセスにアクセスでき、クラッシュしたノードを使用しようとしません。 ネットワークの問題が原因でノードが失われ、運用に戻った場合、レフリーはこれに気付き、交換ノードに一時的な役割をリセットするように依頼します。

構成管理システムとの統合

ホストとサービスの自動検出はドキュメントで十分にカバーされており、構成はファイルに保存されているため、構成システム（PuppetDBなど）で既に利用可能な情報に基づいて、Chef \ Puppetを使用して簡単に生成できます。

アクションロギング

構成はファイルに保存されるため、バージョン管理システム（Git、Mercurial）などの既存のツールを使用して、変更とその所有者を追跡できます。 ドキュメントには、ShinkenがWebインターフェイスのどこかにユーザーアクションを記録するという証拠は見つかりませんでした。

UI

それを使用している人々の保証によると、 Shinken WebUIは、数千のマシンと数十のグループで作業するとき、それ自身をよく見せました。

短所

ドキュメントを完成させた後、目に見える欠陥は見つかりませんでした。 私を悩ませている唯一のことは、過去の急速な開発と現在のコミットの非常に遅いペースです ：今年の約40、それらのほとんどはバグ修正を伴うプルリクエストの注入です。 システムは、さらなる開発にはあまりにも優れている（自然界では発生せず、vimやemacsのような高齢者でも新しいリリースを取得する）か、これは十分な大規模コミュニティやメンテナーの問題を抱えた別のオープンプロジェクトです-これは私が望む情報ですこのような複雑なものを監視システムとして使用する前に知っておいてください。

かつてShinken開発チームのメンバーだったFrédéricMohierは、この問題に関する情報を親切に提供してくれました。 （1.0）は2016年12月に予定されています。

参照資料

• 状態フラッピングの検出と処理-進研マニュアル

センス

Sensuは監視フレームワーク（または彼ら自身が言うところのプラットフォーム）ですが、既製の監視システムではありません。

彼女の強みは次のとおりです。

• Puppet \ Chefとの統合-確認する内容と、構成管理システムに直接通知を送信する場所を決定します
• 可能であれば、自転車を発明する代わりに既存の技術的ソリューションを使用する（Redis、RabbitMQ）

Sensuはキューからイベントをプルし、それらのハンドラーを実行します。それだけです。 ハンドラーは、メッセージを送信したり、サーバー上で何かをしたり、ユーザーが教える他のことを行うことができます。

拡張性

Sensuには柔軟なアーキテクチャがあり、各コンポーネントは複数の方法で複製および交換できます。 単純なフェールセーフシステムの例を、 次のプレゼンテーションで説明します 。 一般的な概要は次のとおりです。

HAProxyとRedis-sentinelを使用すると、各タイプ（Sensu API、Sensu Dashboard、RabbitMQ、Redis）の少なくとも1つのライブマシンで監視を手動で操作しなくても動作し続けるシステムを構築できます。

構成管理システムとの統合

ビルトイン（Puppet、Chef、EC2？！）が有料版のみです。これは、特に数千台のサーバーがあり、無料の類似品を購入したくない場合に悪いです。

アクションロギング

組み込み 、ただし有料版のみ。

UI

Sensuのデフォルトのインターフェース、Uchiwaには多くの制限があります。 幅広い役割を持つ数千のホストがある環境では、あまりにも単純に見えます。 有料版には独自のダッシュボードがありますが、無料版と大差はなく、オープンバージョンのすぐに使用できる機能がいくつか追加されています。

短所

• 履歴情報がなく、それに基づいてチェックを作成する能力が非常に限られている。
• 日曜大工アプローチ-インストール直後にシステムで有効にできる既製の監視はありません。
• イベントの集約は重要です。
• 恐ろしいメッセージの送信が難しい -真実ではありません。 ドキュメントの印象が間違っていました。説明をありがとうx70b1 。
• 「車輪の再発明を望まない」方法には制限があり、そのようなシステムを使用したことがある人なら馴染みがあるかもしれません（私の場合、承認/認証などの多くの機能をユーザーに残したのはプロメテウス監視システムでした\識別）。

参照資料

• Sensu-私が学んだこと

  
  
• MOTD統合

イシンガ2

IcingaはNagiosのフォークで、2番目のバージョンでゼロから書き直されました。 Shinkenとは異なり、この活発で頻繁に更新されるプロジェクト。

拡張性

一般的なアーキテクチャ：

Icinga 2には、適切に設計された分散監視スキームがあります。 テストクラスタを上げるときに見つけた唯一の欠点は、最も単純な分散回路でさえ難しい初期設定でした。

構成管理システムとの統合

統合は非常に良好です。トピックに関する2つのプレゼンテーションがあります。Tomde VylderのIcinga 2とPuppetによる遅延監視への道と 、Walter HeckのIcinga 2とPuppet：自動監視です。 Icingaの重要な機能は、構成をファイルに保存することです。これにより、Puppetを使用して構成を簡単に生成できます。私の場合、 PuppetDBをすべてのホストおよびサービスに関する情報ソースとして使用します。

アクションロギング

私が発見したように、アクションロギングはdirectorモジュールに表示されます。 現在、IcingaWeb2には組み込みの監査サポートはありません。

UI

IcingaWeb2は、さまざまなニーズに対応する多くのアドオンを備えた優れたUIのように見えます。 私が見たところ、最も柔軟で拡張性があり、同時に、あなたが期待できるすべての機能をすぐに使えるように見えます。

短所

私が出会った唯一の欠点は、初期セットアップの複雑さです。 私の場合、Zabbixのように以前とまったく異なるものを使用した場合、Icingaの監視の見方を理解することは容易ではありません。

ザビックス

Zabbixは、安定した開発率を備えた安定した信頼できる監視システムです。 ユーザーの巨大なコミュニティがあり、あなたが尋ねる質問のほとんどはすでにどこかで答えられているので、Zabbixで可能かどうかを心配する必要はありません。

拡張性

サーバーは単一のデータベースで動作し、アクションに関係なく、手元の他のリソース（メモリ、ネットワーク、CPU）で、ある時点でデータベースが使用するディスクのIO制限に遭遇します。 Amazonで 6000 IOPSを使用すると、1秒あたり約2,000 nvpsの新しい値をサポートします。これは悪くはありませんが、まだ多くの要望が残っています。 データベースのプロキシとパーティション化によりパフォーマンスが向上しますが、フォールトトレランスの観点から、データベースは1つだけであり、これがシステム全体の障害点となります。

構成管理システムとの統合

Zabbixは、構成管理システムによって管理される多様な環境に対して十分に準備されていません。 ホストおよびサービスを低レベルで検出するための機能が組み込まれていますが、制限があり、構成システムに関連付けられていません。 このような統合の唯一の可能性は、APIを使用した独自のソリューションです。

アクションロギング

Zabbixは、1つの盲点を除いて、ユーザーアクションを適切にログに記録します。APIを介して行われた変更は、 ほとんどログに記録されません。 私が言及したいもう一つのことは、Zabbixのすべての問題がバグトラッカーのどこかに記録されており、彼らがコミュニティから十分な注目を集めれば、遅かれ早かれ修正されることです。

UI

ZabbixのUIは便利で、多くの機能が含まれています。 反対に、実際には拡張可能ではありません。標準のダッシュボードが提供するという事実を受け入れるか、独自のダッシュボードを作成します。 標準UIの洗練は、その複雑さのために非常に簡単な作業です。

短所

• 現時点で何が起こっているかについての基本的な分析のみ（現在の問題ではなく、発信元からの頻度および同様の情報）。 3.0の「トップ100の射撃トリガー」の登場により、状況は劇的に改善されました。
• Nagiosベースのシステムとは異なり、メンテナンス作業のセットアップはトリガーレベルで設定できず、最近3.2を再設計するまで非常に複雑でした。
• 箱から出してアラートを生成することは、多くの要望が残っています（ただし、これはすべての統合された監視システムにとって問題です）。 私たちの場合、アラートを集約する外部システムを開発する必要がありました（おそらくいつかはオープンソースで公開されるでしょう）。
• 適切な専門知識がなくてもパフォーマンスの問題を調査することは、診断する必要がある1つの分割できないサーバーがあるため、混乱になります。

免責事項

これは多くの写真とさらに多くのテキストを含む長い記録です。 ここでは、「どちらが優れている」などの単純な質問に対する明確な答えではなく、あなたの経験と欲求に基づいてこれらの質問に答える情報を見つけます。 Linuxの労働条件を検討し、Linuxホストを追跡しているため、異なるプラットフォームのシステムサポートは考慮されていません。 また、この条件は、数千台の車と数千台のサービスを監視できる要件として採用されました。

私の意見では、ZabbixとIcinga 2だけが企業で使用するのに十分成熟しており、システムを選択する人が自問すべき主な質問は、どちらの監視哲学が彼に近いかです。まったく異なるアプローチ。