メッセージバス・redis・JSONがつなぐsensuサーバーとクライアント
続いてsensuのアーキテクチャの説明となった。sensuは、サーバーとクライアントのやり取りのためのメッセージバスとしてRabbitMQを利用する。sensuサーバーは1台でなくても複数台で構成してもよい。各クライアントは、sensuのエージェントがインストールされチェックを行い、結果メッセージをRabbitMQに返す。イベントデータの格納にはredisを使っている。
コンフィグレーションは、JSONファイルを使って行う。JSONファイルは複数で構成しても構わない。そのため、コンフィグレーションを一元管理することができ、運用側も理解しやすくなる。コンフィグレーションは「name」「address」「subscriptions」の3つのフィールドが必須項目であり、これにカスタムデータをつけることができる。
そして、クライアント、RabbitMQ、redisそれぞれの定義例をスライドで簡単に説明し、チェックの定義として、ロードバランサーを30秒ごとにアップしているか調べる例が紹介された。次に、パイプ、UDP、TCP、AMQP、Setのそれぞれについてハンドラの定義方法が解説された。
アラートのボイスメッセージが着信してデモ成功
sensuのチェックは、ChefやPuppetなどコンフィグレーションマネージャとの連携がしやすいと述べたが、その例として、Poter氏が用意したVirtualBoxのアプリケーションを使ったデモが行われた。会場では、Sandbox上のサーバーがクライアントであるプロキシサーバーに死活チェックをかけ、ダウンしている場合、ボイスメッセージを飛ばすというものだ。デモが成功し、Poter氏の携帯に着信があり、ボイスメッセージが読み上げられると、会場からは歓声があがった。
最後に、デモしたサンプルアプリケーションなどは氏が用意したUSBで希望者に配布された。同じものはWebからもダウンロード可能としているので、参加者にsensuを使ってモニタリングの自動化に役立ててほしいと呼びかけていた。
