Sensu-監視フレームワーク

ちょっとした歴史

2011年に、ハッシュタグ#monitoringsucksの下で団結し、柔軟性の欠如について既存の監視システムを批判するDevOps環境に動きが現れました。 彼らにぴったり合わなかったことは、 このプレゼンテーションで完全に説明されています。
手短に言えば、人々は、コンポーネントからの柔軟でスマートな監視を構築するために、監視コンポーネント間の相互作用、およびこれらのコンポーネント自体の外観のための特定のAPI標準を望んでいます。

この不満の波の結果は、問題の大規模な議論であり、 SensuやRiemannなどの興味深いユーティリティに注目を集めました。

2013年に、コミュニティのハッシュタグが変更されました-現在は#monitoringloveです。 これは、オープンソース監視ユーティリティの開発が原因で発生しました。

新しいユーティリティの中で、Sensuが最も興味深いものです。 現時点では、フォールトトレランスを確保する手段がないため、Riemannを真剣に検討しませんでした。Clojureで構成を記述するという考えはあまり好きではありません。

この記事では、Sensuについて説明します。仕事の基本原則を説明し、典型的な監視タスクを解決する例を示します。

Sensuについての重要な事実：

* Rubyで記述され、EventMachineを使用します（Pythonを好みますが、大丈夫です）。
* JSONの構成
* Nagiosのプラグインを使用できます。
*クライアント自身がサーバーに送信する場合、プッシュモードでRabbitMQを介して動作します
利用可能になったテスト結果。
* DEB、RPM、およびMSIパッケージもあります。
*シェフ用のパペットとクックブック用のモジュールがあります。

下の画像はSensuの動作を示しています。 私の意見では、すべてが非常に論理的であり、そのような作業スキームはスケーリングとフォールトトレランスを「そのまま」提供します。



システムは、sensu-server、sensu-api、およびsensu-clientsの3つの主要コンポーネントで構成されています。 センスダッシュボードも利用できます。 インストールは簡単で、ドキュメントに詳細が記載されています。最新バージョン0.12については、 ここから入手できます 。 前述したように、deb、rpm、msiパッケージがあります。

基本的な概念

これがどのように機能するかを理解するには、用語を理解する必要があります。 私は公式文書の翻訳を目標として設定していませんが、今後何が議論されるかが明確になるように、基本的な概念を示したいと思います。

次のエンティティがあります。

クライアント

これはsensu-clientがインストールおよび構成されたサーバーであり、RabbitMQで自身に関する情報を公開するため、Sensu監視システムに登録されます。 Sensuサーバーから一連のチェックを受信して​​実行し、結果をRabbitMQに追加します。

自己識別のために、彼は次のような構成が必要です（ドキュメントから取得）。

{ "client": { "name": "i-424242", "address": "127.0.0.1", "subscriptions": [ "production", "webserver", "mysql" ] } } 

「サブスクリプション」を除き、すべてが非常に明白です。 サブスクリプションは、このサーバーに関連付けられているロールのリストであり、サーバーで実行されるチェックのリストを決定します。 より詳細な調整については、 公式ドキュメントに記載されています。有用性から、チェックで値を使用できるフィールドを追加できるほか、クライアントがオフラインのままになるイベントを生成するために経過する必要がある時間間隔を追加できます。

確認する

チェックにより、クライアントで実行されるコマンドとそのパラメーターが決定されます。 Nagiosプラグインと完全に互換性があります。 チェックの成功の基準として終了コードを使用し、データソースとしてSTDOUTまたはSTDERRを使用します。 チェックはsensu-server構成で構成され、一般的なチェックは次のようになります（ドキュメントの例）：

 { "checks": { "chef_client": { "command": "check-chef-client.rb", "subscribers": [ "production" ], "interval": 60 "handlers": [ "pagerduty", "irc" ] } } } 

ここでも興味深いのは、サブスクリプションとハンドラーです。 サブスクリプションは、このコマンドを実行するクライアントを決定します。

一連のハンドラーは、このチェックからのデータを処理するときに実行されるコマンドのリストを決定します。 それらについてさらに説明します。

検証は「メトリック」である可能性があることに注意する必要があります。 STDOUTからのデータは常にハンドラーに単に渡されます。 これにより、メトリックデータをどこかに送信して、グラフを格納または描画できます（たとえば、Graphiteで）。 ドキュメントの詳細。

ハンドラー

ハンドラーは、チェックからのデータが到着したときに監視サーバーで実行されるコマンドとそのパラメーターを決定します。 たとえば、このハンドラは、チェックからゼロ以外の終了コードを受信すると、コマンドmail -s 'sensu event' email@address.comを実行しmail -s 'sensu event' email@address.com （ドキュメントの例）：

 { "handlers": { "mail": { "type": "pipe", "command": "mail -s 'sensu event' email@address.com" } } } 

ここではすべてが明らかです 。 プラグインリポジトリには多くのハンドラがあります 。 Pagerdutyで送信して手紙を送信し、Graylog2でgelfで送信できます。 ドキュメントの詳細。

上記のすべてがすでに動作するシステムを構築するのに十分です。 ミューテーター、拡張機能、APIもありますが、これは今では重要ではありません。

楽しい部分に到達する

Sensuは正確に「監視フレームワーク」として位置付けられており、これは「箱から出してすぐ」にZabbixのようなエンタープライズシステムについてなじみがないことを意味します。 プラグインのおかげですべての機能が追加されます。

何か役に立つことを試してみましょう。 簡単なタスクを見てみましょう-問題が発生した場合にクライアントのRedisをチェックし、Dashingパネルにアラートを表示し、Graylog2にメッセージを送信し、admin @ example.comに履歴を送信します。 また、Redisでメトリックを取得し、それらをストレージ用にGraphiteに送信してから、集約されたキー値もチェックします。

クライアントのアドレスは192.168.1.2Nで、Graphiteは192.168.1.80:8082にデプロイされ、RabbitMQとRedisも192.168.1.80にデプロイされます。 Graylog2は192.168.1.81でリッスンし、Dashingも展開されます。

構成

クライアント構成から始めましょう。

redisの役割でN個のサーバーがあるとします。

クライアント構成は次のようになります。

/etc/sensu/config.json

 { "client": { "graphite_server": "192.168.1.80:8082", "address": "192.168.1.2N", "name": "clientN", "subscriptions": [ "redis" ] } "rabbitmq": { "vhost": "/sensu", "host": "192.168.1.80", "password": "password", "port": 5672, "user": "sensu" } } 

N個の各クライアントでホストされています。

他のすべての構成ファイルはSensuサーバー上にのみあります。

基本設定：

/etc/sensu/conf.d/settings.json

 { "api": { "host": "192.168.1.80", "port": 4567 }, "redis": { "host": "192.168.1.80", "port": 6379 }, "rabbitmq": { "vhost": "/sensu", "host": "192.168.1.80", "password": "password", "port": 5672, "user": "sensu" }, "mailer": { "mail_from": "sensu@example.com", "smtp_port": "25", "mail_to": "admin@example.com", "smtp_address": "localhost" }, "dashing": { "auth_token": "YOUR_AUTH_TOKEN", "host": "http://192.168.1.81:8088" }, "gelf": { "server": "192.168.1.81" "port": "12201", } } 

ご覧のとおり、Sensuだけでなく、ダッシュ、gelf、メーラーハンドラーのパラメーターも設定しました。

次に、これらのハンドラー自体を定義します。

/etc/sensu/conf.d/handlers.json

 { "handlers": { "default": { "type": "set", "handlers": [ "mailer", "dashing", "gelf" ] }, "gelf": { "type": "pipe", "command": "/etc/sensu/handlers/gelf.rb" }, "mailer": { "type": "pipe", "command": "/etc/sensu/handlers/mailer.rb" }, "dashing": { "type": "pipe", "command": "/etc/sensu/handlers/dashing.rb" }, "graphite": { "mutator": "only_check_output", "type": "amqp", "exchange": { "durable": true, "type": "topic", "name": "metrics" } } } } 

ここではすべてが簡単です。 Graphiteでは、AMQPを介してデータヘルメットを作成します。 ハンドラーは、/ etc / sensu / handlersの監視サーバーで分解する必要があります。

次に、クライアントで実行されるチェックを構成します。

/etc/sensu/conf.d/checks.json

 { "checks": { "redis_processes": { "interval": 60, "command": "/etc/sensu/plugins/processes/check-procs.rb -p redis -c 8 -C 0 -w 7 -W 1", "subscribers": [ "redis", ], "handlers": [ "default" ] }, "redis_memory": { "dependencies": [ "redis_processes" ], "command": "/etc/sensu/plugins/redis/check-redis-memory.rb -c 204800 -w 51200", "interval": 60, "subscribers": [ "redis", ], "handlers": [ "default" ] }, "redis_metric": { "handlers": [ "graphite" ], "interval": 60, "dependencies": [ "redis_processes" ], "command": "/etc/sensu/plugins/redis/redis-graphite.rb --scheme stats.:::name:::.redis", "subscribers": [ "redis", ], "type": "metric" }, "redis_keys_from_graphite": { "interval": 60, "command": "/etc/sensu/plugins/graphite/check-data.rb -s :::graphite_server::: -t stats.:::name:::.redis.db0.keys -w 500 -c 900 -a 120", "subscribers": [ "redis" ], "dependencies": [ "redis_processes" ], "handlers": [ "default" ] } } } 

チェックはSensuプラグインによって実行されます。これは、/ etc / sensu / pluginsのクライアントで分解する必要があります。 Nagiosに精通している人にとっては、新しいものは何もありません。redis_metricメトリックのみが興味深いので、そこからデータをGraphiteに入れ、その後redis_keys_from_graphiteチェックで最後の10分間のデータを取得してチェックします。 一般に、ほとんどすべてのプラグインには--helpスイッチがあり、完全に正しいリファレンスを使用できます。

これが構成全体です。 すべてが明確で、すべてをリポジトリに保存できます。これは素晴らしいことです。

もちろん、DashingとGraphiteを構成する必要がありますが、これは記事の範囲外です。 Sensu + Graphiteのセットアップ手順はここにありますが、Dashingを使用するとすべてが明確になります。

Sensuには、クライアント、チェック、トリガーされたアラートのリストを表示できるシンプルなダッシュボードもあります。 APIおよびダッシュボードを使用して、ホストまたはチェックのアラートの生成をオフにし、システムの一般的なステータスを確認できます。
次のようになります（画面は私のものではありません）：

結論

ご覧のとおり、Sensuはルーターとオーガナイザーの役割のみを担い、すべての汚い作業は外部プログラムによって行われます。 これにより、ソースコードの小さなサイズとシステムの全体的なシンプルさを節約できます。 RabbitMQを介したクライアントの登録により、クライアントの「発見」のメカニズムを取り除くことができます。これは、クラウドに特に便利です。 スケーリングは非常に簡単です。HA+ロードバランシングの例はここにあります 。

私はZensbixと並行してSensuを約1か月間本番環境で使用しており、テスト版では数か月使用しました。 Sensuの柔軟性により、Zabbixを非常に長い間使用している間に、主要なパラメーターとプロジェクトメトリックスの監視をDashingパネルへの出力で構成でき、現在ではより包括的な監視に取り組んでいます。 一般に、多くのプロジェクト、特にクラウドでは、Sensuが優れた選択肢になります。これは、イベントを柔軟にルーティングでき、クラウドの動的な性質にもうまく適応できるためです。 プレゼンテーションでは、Sensuの監督下で数千台のサーバーに会ったため、パフォーマンスに問題はありません。

結論として、Sensu（すべて私見）の長所と短所を指摘したいと思います。

短所

• 既存の通知ハンドラーの設定は不十分です。 PagerDutyなどのサービスを使用しない場合、これがメインのマイナスになります。 唯一の解決策は、cなハンドラーを作成することです。
• 設定はyamlではなくjsonにあります。
• 外部のメトリックカストディアンが必要です。彼はチャートペインターでもあります。
• 完全なドキュメントではありません。 幸いなことに、プロジェクトはシンプルで、コードを読むだけで理解できます。

プロセンス

• 構成はgitに保存でき、Chef / Puppetですべてをレイアウトできます。
• スケーラビリティ。
• 耐障害性。
• ストレージシステムの選択における柔軟性。
• Nagiosプラグインのサポート。
• クライアントを自動接続します。
• サブスクリプションメカニズム。
• データは、生成されると顧客によって公開されます。
• テスト結果は、さまざまなハンドラーに柔軟に送信できます。