はじめに

こんにちは。
本来は 12/01 に投稿するはずが諸事情で落としてしまい、結局カレンダーが終わりを迎えようとしているところで記事を書いています、スミマセン...
本稿では、普段から仕事でお世話になっている Sensu の歴史が気になり追いかけてみた内容を紹介します。

さすがに Github にある全部のコミットを追いかけるのはつらいので、開発開始から最初のリリース（v0.5.1）まで、README の推移を中心にざっくりと追ってみました。

歴史をおいかける

2011/07/12

README.org

Sensu が最初に Github へとコミットされた日です。
なんとなく感慨深いですね。記念日です。
空の README.org が追加されただけですが、ブレストなどしていたのかもしれません。

2011/07/15

README.org

この日から本格的に開発がスタートします。
具体的なアイデアが README.org に記載されました。
Notes の痕跡が、当時の雰囲気をうかがえる感じがしていいですね。

A Client Will
- ohai を使って自身の情報を client attribute として生成する
- 自身の run list や role をベースに fanout exchange を subscribe する
- keep alive (client attribute) を TCP socket 経由でサーバにおくる
- check を実行し、その結果を check id と client attributes と共に direct exchange にプッシュする
A Server Will
- OpsChef data bag を内部 work queue へ展開する（これにより nagios checks が role にマップされる）
- direct exchange を subscribe する（result を受け取るため）
- 内部 work queue から check を取り出し、check id（uuid）でタグ付けて、fanout exchange へプッシュする
- 送信した check id, タイムスタンプ, コマンド名を redis に保存する（自動で expire する）
- result を処理し、クライアントの critical/warning を redis に保存する。もし good ならそれまでの result をフラッシュする
- カレントの critical/warning メッセージ取得用に REST API を提供する

fanout exchange, direct exchange は AMQP の概念です。
message queue への配送の種別のことで、fanout は全てに配送され、direct はキーが一致するものにのみ配送されます。
これを眺めると、当初から Rabbitmq や Redis, Chef の利用を前提としており、今にいたっているのだなということがわかります。

2011/07/27

README.org

ゴールが設定され、API が分離されると共に handler の概念が追加されています。

A Handler Will
- event file path 用に1つのコマンドライン引数を受け取る
- JSON event file をパースする
- Event に応じた処理をする
Goals
- Friday, July 29th
  - クライアント/サーバ/API が要件通りに動作する
- Friday, August 6th
  - SA-Monitoring が Nagios と並走を開始する
  - いくつかの nagios plugin を動かす
  - pager duty handler を動かす（page はしない）

実際にコードを書き始めたのが 07/15 なので、そこから3週間で Nagios との並走を開始することを目指したようです。
Goal に SA-Monitoring とありますが、リポジトリ名こそ sensu なものの、当時は sa-onitoring として使われていたことが gemspec からもわかります。
SA は何の略称なんだろうと思いましたが System Administrations くらいしか思い浮かびませんでした。
handler のアイデアは pager duty を使いたいというのが動機なのかも？

2011/07/28

README.org

Dashboard の概念が追加されました。
Query OpsChef/Puppet for additional client (node) information とあるので、当初は Chef/Puppet に情報をとりにいく設計だったようです。
他には Server が data bag から情報をとるのでは無く、現在の JSON config スタイルになっています。

2011/08/23

README.org

Welcome to Sensu とヘッドタイトルが追加されました。
Lisence や Contribute に関する内容が追記され、本格的に OSS として動き出したことがうかがえますね。
ちなみに前日に 'renaming project' の開始がコールされており、このコミットで sa-monitoring から sensu へと名前が変更されると共に v0.1.0 から v0.2.0 になっています。
他には Plugin に関しての追記など、これまで暗黙の了解だった部分の補強が多く行われています。

2011/09/08

README.org

これが v0.5.1 リリース前の最終更新です。
ちなみに 08/22に v0.2.0 となってから17日程度で v0.2.1, v0.2.2, v0.3.0, v0.4.0, v0.5.0 と怒濤のバージョンアップが行われてます。
正式リリース前の追い込みというところでしょうか。
個々のアップデートは追いかける気力がわかなかったので興味ある方は gemspec のコミットログなどを足がかりにどうぞ。

sensu.gemspec

おわりに

Sensu が当初から構成管理システムとの連携などのモダンなアイデアを取り入れて設計され、開発開始からサービス投入まで約1ヶ月程度とスピード感をもって進んできたことがわかりました。
Sensu を使っていく上では特に必要の無い知識かもしれませんが、成り立ちを知ることで皆様の Sensu 愛がより深まれば幸いです。
さらに歴史を追いかけてみたい方はこのあたりを足がかりにされるとよいかと思います。