HAP2プラグインのベースライブラリ動作概要
はじめに
Hatohol 16.04のHAP2のベースライブラリは、下図のように4つのプロセスから構成されます。いずれもPythonで記述されています。矩形のボックスがそれぞれプロセスです。その中の文字列は、中心的な役割を果たすクラスを示しています。楕円は、プロセス間でデータをやり取りするためのキュー（Queue）です。矢印線はデータの経路を示します。
このような構成の理由のひとつは、イベント駆動型の動作を行うためです。プラグインは、RPC（リモートプロシージャコール）を提供するために、RabbitMQからの入力を検出しなければなりません。定期的にデータの存在を確認する方法もあります。その場合、構成はより単純にすることもできますが、入力データの有無にかかわらず動作が発生し、不必要にCPUを使用すること、実際にデータが届いてから受け取るまでにタイムラグが発生するというデメリットがあります。
この構成のもうひとつの特徴は、RabbitMQからのデータ入力をRabbitMQHapiConnectorだけが担当することです。一方、データの出力は、MainPluginとPollerの双方から直接行われます。次節以降、各プロセスについて、詳しく説明します。
RabbitMQHapiConnector
このプロセスは、RabbitMQからデータを読み取ります。16.04ではPikaという外部ライブラリを用いてRabbitMQと通信しています。入力されるデータは、基本的に、HatoholサーバからのRPCリクエスト、または、Hatoholサーバに対して発行したRPCに対するレスポンスです。このプロセスでは、データのフォーマットなどの形式的なチェックが行われます。Message IDがなくエラー応答できない破損したメッセージは、ここで破棄されます。それ以外の場合、ParsedMessageというオブジェクトに変換されて、DispatcherのDispatch queueに送信されます。
Dispatcher
Dispatcherは、Dispatch queueから次の３種類のデータを読み取り、それぞれに応じた処理を行います。
- RPCリクエスト
- レスポンス
- レスポンス配信先設定
Dispatch queueには、送信元を示す"Receiver"や"Main"などの文字列（図中の0:）とデータ本体（図中の1:）の組単位でデータが格納されています。RPCリクエストとレスポンスの場合、データ本体は、ParsedMessageというオブジェクトです。その中に格納されているメッセージIDが、予めレスポンス配信設定によって指定されたものであれば、レスポンスとして扱い、BaseMainPlugin、または、BasePollerのResponse queueに送信します。どちらに送信するかは、事前に送信されたレスポンス配信先設定によって決められます。次節でその詳細を説明します。そうでない場合、RPCリクエストと判断され、BaseMainPluginのRPC queueに送信されます。
BaseMainPlugin
BaseMainPluginの主要な役割のひとつは、RPCリクエストを処理することです。HAPI2.0では、通常、ExchangeProfileが、開始時にHatoholサーバから要求されます。その他、アイテムやヒストリが必要に応じて要求されます。応答は、図のように直接RabbitMQに対して送信されます。
BaseMainPluginがHatoholサーバに対してRPCを実行する場合、事前にDispatcherに対して、RPCのメッセージIDを通知します（前節のレスポンス配信先設定）。これが受け付けられた場合、Replay queueにTrueが返されます。この手続きにより、Dispatcherは、レスポンスを受け取った際、どのプロセスのReply queueにそれを配信すればよいか判断できます。
このクラスは、通常、継承されてプラグインごとに固有の実装が追加されることが想定されています。fetchItemsやfetchHistoryなどのRPCに対する振る舞いは、監視システムによって異なるからです。例えば、Hap2ZabbixAPIMainなどがそれに相当します。
BasePoller
BasePollerは、その名の通り、定期的に監視システムからデータを取得するために使用されます。ライブラリは、定期的にハンドラpoll()を定期的に実行します。その間隔は、GetMonitoringServerInfo()によってHatoholサーバから得られた値が使用されます。
このクラスも、BaseMainPluginと同じく、継承され、監視システムごとに実装されます。しかしながら、プロセスそのものは、オプションです。Zabbix用のプラグインでは使用されていますが、Fluentd用のプラグインでは使用されていません。
このプロセスがHatoholサーバに対してRPCを行う場合、BaseMainPluginと同じく、事前にメッセージIDをDispatcherに設定します。
まとめ
HAP2のライブラリを構成する４つプロセスの役割について説明しました。現状、これらはPythonで記述されています。ただし、プロセス間通信などを多用しているため、必ずしも実行効率が高いとは言えません。繰り返し使用されるベースライブラリであるため、将来的には、C/C++などで書き直す構想を一部の開発者は持っています（単なる希望のひとつで、その時期などは全く未定です）。その場合でも各監視サーバごとの固有の実装は、Pythonで容易に行えるようにする予定です。
