できぬなら作ってしまえ？ OSS監視ツール「Hatohol」ができるまで：Hatoholで実現する分散監視（1）（2/2 ページ）

» 2014年02月14日 18時00分公開

Hatoholのアーキテクチャ

　Hatoholは図3のように、「Hatoholサーバー」と「Hatoholクライアント」から構成されます。

図3　Hatoholのアーキテクチャ

　Hatoholサーバーは、実行性能やスレッド、子プロセスなどのきめ細かい制御能力を重視し、C++で実装されています。一方Hatoholクライアントは、Djangoフレームワークを用いてPythonで実装されていますが、UIのための多くの処理は、オペレーターのPCのブラウザー上で実行されるJavaScriptが行います。このJavaScriptによるWebUIには、モダンなルックと高度な機能を提供するBootstrapとjQueryが利用されています。

　Hatoholサーバーは、ZABBIXサーバーやNagiosから定期的にデータを収集します。ZABBIXサーバーとの通信にはZABBIX APIを使用します。Nagiosは、それ自身では監視データを保存する機能を持ちませんが、NDOUtilsというソフトウェアと組み合わせることで、監視データをMySQLなどのデータベースに保存できます。Hatoholは、この仕組みを利用してデータを定期的に読み出します。

　この際、トリガーとイベントに関しては、前回読み出した時からの差分のみを取得します。このため、各監視サーバーとの通信に要する帯域や処理の負荷はそれほど高くありません。

　これに対し、常に変化し得るアイテムの値については、オペレーターのPC上での閲覧操作を契機にして、各サーバーから取得します。監視データが閾値を越えたかどうかの判断は、従来どおり各監視サーバーで行われます。この分散的なアーキテクチャにより、冒頭で述べた「より多くの機器をスケールアウトしながら監視する」という課題を克服しています。

　Hatoholサーバーは、各監視サーバーから収集したデータを統合して出力する機能を持ちます。出力プロトコルはHTTP（REST）で、データフォーマットはJSONです。

　Hatoholクライアントは、オペレーターがWebブラウザーでアクセスすると、HatoholサーバーのRESTインターフェースを通じて統合されたデータを取得し、HTMLファイルを生成して送信します。監視サーバーやアクションの追加などの操作も、同様にREST APIによって行われます。

　ご存じの通りRESTとJSONは汎用的な技術であるため、ユーザー独自のクライアント、例えば、AndroidやiOS用のクライアントを作成したり、専用の上位レベル監視ツールを開発することも容易です。また、このRESTインターフェースを利用する、Pythonで作成されたコマンドラインツールも提供されているので、それらを利用して、バッチ処理による監視データ一覧などを取得することも可能です。

Hatoholの設計思想

　Hatoholは、「監視」という目的の特性上、1カ所の障害などが他の部分に影響して、監視自体ができない事態が発生するのを極力抑えることを理念にして、設計されています。

　例えば、各監視サーバー1つにつき、1つのデータ取得用スレッドが生成されます。RESTインターフェース部も、複数の応答用スレッドが起動時に用意されます。それらは独立して動作するので、監視サーバーやクライアントからの反応が遅くなったり、通信が不通になってタイムアウトを待つような状態に陥っても、それらに関係のない部分は、正常に動作し続けます。

　また、監視サーバーから取得されたトリガーやイベントは、HatoholサーバーのData DBに格納されます。クライアントからのデータ要求時には、そこから読み出されるので、仮に監視サーバーがダウンしていても、その直前までのデータをすぐに取得可能です。

　その他にも、アクションは、監視サーバーからの該当するイベントの取得後に非同期（バックグラウンド）で実行されます。そのため、アクション実行に時間を要しても、その間の監視データの読み出しやクライアントへの応答が滞ることはありません。

　加えて、大量のイベント発生に伴う、アクションの連続的な実行が行われる場合でも、同時実行数が制限された状態でバックグラウンド処理されるため、監視そのものの中断は発生しません。