SensuをChefで入れようとして四苦八苦した話

既存のサーバーにchef-soloで入れてみたが結構苦労した。地雷を踏みまくった気がする。
Sensuの勝手が分からなかったせいもあるが、だいたいはChefのクックブックの選択をミスったせい。あと既存のクックブックと新規のクックブックの依存性の衝突とか。

Sensuについては以下を参照。

監視ソフトをNagiosからSensuに切り替えて2ヶ月経ったのでまとめた – Glide Note – グライドノート
Sensuを使って自由度の高い監視システムの構築を行う方法 | Ryuzee.com
Sensu 監視システムを Chef で制御 – jedipunkz’ blog

大変参考になりました。

Cookbookの選択ミス

最終的にうまくいったBerksfileの指定

cookbook "yum", "3.0.0"
cookbook "git"

cookbook "rabbitmq", "3.0.4"
cookbook "redis", :git => "https://github.com/miah/chef-redis.git"
cookbook "sensu", :git => "https://github.com/sensu/sensu-chef.git", :tag => "0.8.0"
cookbook "monitor", :git => "https://github.com/portertech/chef-monitor.git", :ref => "774a95002cab6489256c46da84ab3c566c8078e1"

:tagとか:refとか指定しているのはクックブックの取得元をgitにする際にこれを指定しないと以下のようなエラーが出るため。

Failed to download 'monitor' from git: 'https://github.com/portertech/chef-monitor.git' with branch: 'master' at ref: '774a95002cab6489256c46da84ab3c566c8078e1'
Cookbook 'monitor' not found in any of the default locations

berkshelfのバグ？

だめだったBerksfileの指定

sensuとmonitorがイカンかった。

cookbook "sensu"
cookbook "monitor"

OpsCodeの方に新しいバージョンが上がってないようで、上のように書くとバグ入りの古いSensuプラグインが入ったりする。
ChefのクックブックはGithubの方でけっこう活発にアップデートされていても、OpsCodeの方に登録されている方が更新されていないケースがけっこうあるっぽい。Githubでタグ指定するのが確実なのかもしれん。

ちなみにmonitorはsensuのクックブックのラッパー。sensuクックブックを直接使おうとすると微妙に面倒くさく、他にもラッパーを作っている人が多くいるようだ。

node.jsonの指定

こちらは一応のメモ。

サーバー側。

{
  "run_list": [
    "recipe[monitor::master]",
    "recipe[monitor::redis]",
    "recipe[monitor::rabbitmq]"
  ],
  "sensu": {
    "use_ssl": false,
    "dashboard": {
      "password": "xxxxxxxxxx"
    }
  }
}

クライアント側。

{
  "run_list": [
    "recipe[sensu::rabbitmq]",
    "recipe[monitor]",
  ],
  "sensu": {
    "use_ssl": false
  },
  "monitor": {
    "master_address": "10.0.0.10"
  }
}

クックブック選択ミスにより引き起こされた数々の現象

sensu-serverとsensu-clientの死

立ち上がってもすぐに死ぬようになった。

結論を言うと以下のディレクトリやその中のファイルのオーナーがいつの間にかrootもしくは489のような存在しないユーザーになっており、sensuユーザーから読み書きできない状況になっていたためだった。

• /etc/sensu
• /var/run/sensu/
• /var/log/sensu/

これらのオーナーをsensuにすると問題なく動作するようになったが、古いクックブックを使っていても最初は動いていたのに途中から動かなくなったとか、謎は深い。

バグ入りのcheck-procs.rb

unicornのプロセスが立ち上がっていることを監視するチェックを以下のごとく書いてみた。
data_bagsで追加できるのはよろしいですね。

data_bags/sensu_checks/unicorn.json

{
  "id": "proc_unicorn",
  "handler": [ "default" ],
  "command": "check-procs.rb -p unicorn -C 1 ",
  "subscribers": [ "rails-app-with-unicorn" ],
  "interval": 10
}

これをサーバーに適用してしばらく待つと・・・

CheckProcs CRITICAL: Found 3 matching processes; cmd /unicorn/

！？

プロセスがひとつも上がっていなかったらアラートが出るはずなんだが。3つあがっているのにアラートとはこれイカに。

このあたりを参考にSensuのクライアント上でチェックをコマンドラインから実行してテスト。

/opt/sensu/embedded/bin/ruby /etc/sensu/plugins/check-procs.rb -p unicorn -C 1
/opt/sensu/embedded/bin/ruby /etc/sensu/plugins/check-procs.rb -p unicorn -C 3
/opt/sensu/embedded/bin/ruby /etc/sensu/plugins/check-procs.rb -p unicorn -C 5

色々試すがOKにならず。

そこで/etc/sensu/plugins/check-procs.rbの内容を見てみたら最新のcheck-procs.rbと違う。
どうもバグ入りのplugins/check-procs.rbが入ってたようだ。Fxxx!

で、犯人捜しでchef-monitorにたどり着く。

しかし見るに現在は修正されたcheck-procs.rbが入っている。
更に色々と調べてみると、どうやらGithubの方だけ更新されてOpsCodeの方は更新されてないというオチだった。ぬう。

既存のクックブックと新規のクックブックの依存性の衝突

Jenkinsが入っているのと同じサーバーに入れたのだが、それらを入れてからこの数ヶ月の間にyumのクックブックが2系から3系に破壊的バージョンアップを果たしており、2系のyumのクックブックに依存する古いJenkinsのクックブックが使えなくなっていた。

Jenkinsのクックブックもその間に2.0系にバージョンアップしておりこれ上げればおそらく問題ないと思われるが、1.2.2で入れたものに対して2.0系を適用してOKなのかどうかいまいち自信がなく。

Jenkinsのみなら古いyumのクックブック（2.4.4など）を使えば1.2.2のままで問題ないのだが、何かに依存して使われているnginxのクックブックが新しい方のyumに依存しており、にっちもさっちもいかない状況。
とりあえずjsonのrun_listから外してもアンインストールされるわけではないので、Jenkinsを外してしのいだ。

今後どうしたものか思案中。サーバーを分けるのがベストなんだろうけど、その調子でサーバーを増やして行くのも諸般の事情により難しく。
データのバックアップを取った上で2.0系を動かしてうまくいけばよし、うまくいかなければいったん削除して2.0系で入れ直しというのがいいだろうか。

サードパーティのクックブックを使う際にはこう言うバージョンアップの挟み撃ちにされるケースもあるということで。

動作確認のサンプルでハマるの巻

公式ドキュメントの通りにcrondのチェックを試してみたら、crondを止めてもアラートが上がらず、動いているのか動いていないのか分からないという状況に。

ログを見てみるとどうやら動いているようだが、チェックはOKのまま。

答えを言うとincrondが動いていたため/crond/のパターンにマッチしていたというオチだった。
リアルな既存サーバーに適用するとこんな罠もある。

これはクックブックの選択の問題とは関係ない。

その他の注意

サーバー側のRabbitMQのポートを開けておくのを忘れずに。

Sensuの所感

セットアップでえらいハマったけど、チェックの追加とか簡単にできるのはいいかんじだ。
軽快に使って行けそう。