HAPI 2.0の概要
はじめに
HAPIは、Hatohol Arm Plugin Interfaceの略です。従来、Hatoholサーバは、下図のようにZABBIXやNagiosから、個別のデータ取得部により、監視データを集約してDBに保存していました。このデータ取得部をArmと呼んでいます。データ取得部は、その対象に応じて、個別の取得方法を採用しています。例えば、ZABBIXに対しては、ZABBIX APIを使用しますし、Nagios + NDOUtilsに対しては、MySQLのクライアントライブラリを使用しています。
この方式の問題点は、新たな監視システムに対応しようとした場合、Hatoholサーバの改変が必要になることです。なぜなら、データ取得部は、Hatoholサーバ内にハードコードされているからです。Hatoholサーバは、パフォーマンスを最大化するために、C++を使ったマルチスレッドプログラミングにより開発されています。そのため、改変や拡張には、比較的低レイヤーなプログラミングの知識が要求される上、少しのプログラミングのミス（バグ）で、Hatoholサーバ全体のクラッシュや動作不良を引き起こす可能性があります。
このことは、ユーザーや開発協力者による対応監視システムの増加を妨げる要因になると考えました。そこで、Hatohol 14.06で下図の赤いブロックでしたHAPIフレームワークが導入されました。
HAPIフレームワーク
HAPIフレームワークでは、Hatoholサーバには、監視システムに依存しないデータの受信部が具備されています。監視システムごとの差分は、別プロセスとして動作するデータ取得プロセス（Arm Plugin）と呼ばれるコンポーネントで吸収されます。このコンポーネントは、単にプラグインと呼ばれることもあります。Arm PluginとHatoholサーバに間には、メッセージの仲介を行うAMQPブローカーが配置されています。この方式の主な特徴は次のとおりです。
- Arm Pluginを任意の言語で記述可能
- 新しい監視システムへの対応で、Hatoholサーバの改変不要
- Arm PluginがクラッシュしてもHatoholサーバへの影響は限定的
- Arm PluginやAMQPブローカーを複数マシンに配置することで負荷分散が実現可能
- Hatoholサーバを停止することなく、新たな種類の監視システム追加が可能
- 監視システムが暗号化されたデータ取得方法を提供していない場合でも、HatoholサーバとArm Plugin間を暗号化することでセキュアな監視が可能（AMQPの暗号化フレームワークを利用）
- 監視システムとHatoholサーバが直接通信できない環境でも、その両方からアクセスできるエリアにAMQPブローカーを配置すると、監視ができるようになる。
この方式は、Hatoholに取り込まれてから1年あまり使用されました。一方、HatoholサーバとArm Plugin間のプロトコルがバイナリ指向であったため、Pythonなど軽量言語を用いた開発がやりにくいという課題もわかってきました。HAPIフレームワーク導入の目的のひとつは、第三者による監視システムの追加を容易にすることであったので、この点を是非解決したいと考え、新しいプロトコルHAPI 2.0を新たに策定に着手しました。
HAPI 2.0
HAPI 2.0では、前節で述べたように軽量言語でのArm Plugin開発を容易にするため、次の変更が加えられました。
- JSON-RPCをベースにしたテキストベースのプロトコル
- 標準のAQMPブローカーをQPidからRabbitMQに変更
（RabbitMQのほうが広く普及しており、プラグイン作成がより容易になると考えたため）
プロトコル仕様は、2015年の春に策定され、このサイトで公開されています。その実装は、Hatohol 15.06に初めて搭載され、2016年1月にリリースされたHatohol 16.01で安定化されました。16.01では、従来のArmとHAPI2.0を用いたArmの両方が搭載されていましたが、次版16.04では、従来型のArmが削除されます。そのためのパッチが先日開発コミュニティのマスターレポジトリにマージされました。（この記事を書く動機もこのマージによります）
まとめ
本稿では、Hatoholで今後主流になるHAPI 2.0と呼ばれるデータ取得フレームワークについて説明しました。Python、RubyやNodeJSなど、軽量言語を用いて、ユーザー自身が独自のプラグインを作成し、任意の監視システムからのデータを集約することができます。ご興味があれば、是非Plugin開発に挑戦してみてください。質問などがあれば、開発コミュニティのIssueに登録をお願いします。
