そもそもSensu（公式サイト）が誕生するきっかけとなったNagiosの問題点とは何でしょうか。Nagiosは、監視サーバが監視対象となるクライアントの情報を持っている必要があります。新たなクライアントを監視するには、設定ファイルに追記し、サービスをリロードする必要があるため、クラウドのように頻繁にシステム構成が変更されるような環境には不向きだったのです。

　そこで、Sensuは最初からクラウド環境での利用を想定して設計されました。下記のような機能がコンセプトになっており、サーバ数が頻繁に増減したり、サーバが自動でデプロイされたりするような環境にも柔軟に対応することが可能です。

• 監視クライアント（エージェント）を自動で監視サーバに登録、削除できる
  • 監視サーバ側の設定変更やリロードは必要ない
  • 監視クライアントにエージェントをインストールするのみでよい
• 設定ファイルはJSON形式で、自由に分割することができる
  • 「Chef」などの構成管理ツールと親和性が高い
  • SensuをChefと組み合わせてインストールするためのCookbook（インフラの状態をコードで記述したファイル群）「sensu-chef」やPuppetと組み合わせてインストールするためのマニフェスト（インフラの構成情報を記述した設定ファイル）「sensu-puppet」を標準で提供する
• Nagiosの監視プラグイン「Nagios Plugins」と互換性がある
  • Nagiosから移行する際、既存の資源を活用できる
• 監視サーバやミドルウェアをスケールアウトできる
  • 冗長化や大規模な環境で導入できる
• 標準でRESTful APIを備え、ドキュメントも充実している
  • フロントエンドやツールなどと連係できる

Sensuの仕組みと基本的な構成

　Sensuは「sensu-server」（監視サーバ）、「sensu-client」（エージェント）、「sensu-api」（RESTful API：ソフトウェア連係の設計原則「REST」に準拠したAPI）の3つのコンポーネントで構成されています（図1）。sensu-serverとsensu-clientの通信には、メッセージ指向ミドルウェアの「RabbitMQ」、監視対象や監視結果の保存にはキーバリューストアの「Redis」を使用しています。なおSensu v0.19.0からは、Redisを通信にも使用できるようになりました。

図1　Sensuは監視サーバ、エージェント、APIの3つのコンポーネントで構成されている（出典：Sensu, a monitoring framework | PorterTech）

　ここで、Sensuにおける監視の流れを簡単に説明しておきましょう。Sensuにおける監視の流れは以下のようになり、データのやりとりはほとんどがJSON形式で行われます。

1. sensu-serverからsensu-clientに対して監視の実行を指示する
   • 指示は、RabbitMQの各sensu-clientのキューにキューイングされる
2. sensu-clientはキューイングされた監視を実行し、結果をsensu-serverに送信する
   • sensu-client上でコマンドやスクリプトを実行し、出力と終了ステータスを取得する
   • 監視結果はRabbitMQを通じてsensu-serverに送信する
3. sensu-serverは受信した監視結果に応じて、通知などの処理を実施する
   • 終了ステータスは「0：OK」「1：WARNING」「2：CRITICAL」の3つに分類される

　監視やその結果に応じた処理を行うプラグイン（スクリプトなど）の設定はsensu-server上で定義し、実際に実行するスクリプトはsensu-clientに配置します。監視の設定には「どの役割のsensu-clientで実行するか」が定義されており、sensu-clientは自分の役割（Webサーバ、メールサーバなど）に応じた監視を実行します（役割は複数定義、設定できるため、n対nの関係になっています）。

　またsensu-client上で設定を行い、独立して監視を実行できるスタンドアロン機能もあります。クライアント独自の監視を行うことができ、結果はsensu-serverに集約されるため便利です。

　Sensuはこのような構成になっているため、新たなsensu-clientを追加した場合でも、sensu-serverの設定を変更することなく監視を開始することができます（監視項目の追加など、設定を変更した場合はサービスのリロードが必要）。

Sensuのダッシュボード「Uchiwa」

　Sensuのダッシュボードには「Uchiwa」というしゃれた名前が付けられています。UchiwaはSensuとは別のプロダクトですが、両者を組み合わせて使うことが一般的です（2014年末までは「sensu-dashboard」がありましたが、既にサポートが終了しています）。

　Uchiwaでは、発生中のアラートやクライアントと監視項目の一覧など、Sensuの情報を一元的に閲覧することができます（設定の変更などはできません）（画面1）。複数のSensu環境にも対応しており、大量の情報をフィルタリングして見やすくすることも可能です。また、メンテナンスなどの際にアラートを一時的にサイレントにしたり、監視クライアントを削除したり、アラートを停止したりするなど、管理者向けの機能も備えています。

画面1　Sensuの情報を一元的に閲覧できる「Uchiwa」（出典：Uchiwa | Simple Dashboard for Sensu）