はじめに
- 前回はざくっと sensu を使ってみたのでも少し掘り下げてみる
- 検証に作った Dockerfile 達もちょっと修正してみる
参考
sensu のおさらい
sensu ってなんすか？
以下、個人的な認識。
- 軽量でシンプルな監視システム
- ruby で実装されていて EventMachine が使われている
rabbitmqとredisが利用されている- クライアント自身が自分を監視して結果をサーバーの
rabbitmqに送りつける - クライアントの監視結果（
OK=0/WARNING=1/Critical=2）はRedisにLIST型で記録される（されていた） - 設定やログは全て
JSON形式で書かれている - 行う処理として監視の Checks と監視の結果を処理する Handlers に分けられる
sensu内で扱われるデータがJSON形式である所以か他のシステムとの連携もし易い
ドキュメントの冒頭に...
Sensu is often described as the “monitoring router”
とあるように、既存の監視システムのような多機能、オールインワンというよりもシンプルだけど利用者が自由に機能を組み合わせることが出来る監視システムを目指している印象を受ける。
システムの構成
こちらを参考に自分なりに整理してみたのが以下の構成図。
rabbitmq は各クライアントから監視結果のキューイングや逆に sensu-server から各クライアントへのキュー処理を redis はクライアントから送られた監視結果やクライアントの情報を蓄積しているようだ。sensu-dashboard は sensu-api を利用して構成されているので標準のもの以外に sensu-admin というダッシュボードもある。以下は sensu-admin の動画。
標準のダッシュボードよりも多機能なようだ。
も少し掘り下げてみる
監視データを見てみる
監視のデータは redis に記録されているようなので redis にログインしてレコードを見てみたい。キーの一覧は下記の通り。
redis 127.0.0.1:6379> keys * 1) "history:882de11a9eed" 2) "history:a4a8b1519ba2" 3) "events:882de11a9eed" 4) "events:a4a8b1519ba2" 5) "history:882de11a9eed:cron" 6) "history:a4a8b1519ba2:cron" 7) "client:882de11a9eed" 8) "client:a4a8b1519ba2" 9) "execution:882de11a9eed:cron" 10) "lock:master" 11) "execution:a4a8b1519ba2:cron" 12) "history:882de11a9eed:keepalive" 13) "history:a4a8b1519ba2:keepalive" 14) "clients" 15) "execution:882de11a9eed:keepalive" 16) "execution:a4a8b1519ba2:keepalive" redis 127.0.0.1:6379>
監視対象のノード数や監視項目次第でキーの数は前後すると思われる。また、キーの名前は...
${項目}:${クライアントのホスト名（client_name）}:${監視項目}
が標準のようで、キーは以下のように幾つかのタイプに別れている。
| キー名 | タイプ | memo |
|---|---|---|
| history: | set | SMEMBERS ${key} で確認する |
| history:${client_name}:${監視項目} | list | SMEMBERS ${key} で確認する |
| events: | hash | hgetall ${key} で確認する |
| client: | string | get ${key} で確認する |
| clients | set | クライアントのリストが確認出来る |
| execution: | string | |
| lock: | string |
history:${client_name}:${監視項目} あたりを覗いてみる。
LINDEX history:882de11a9eed:cron 0
以下のように数字が出力される。
"2"
この 2 は Critical の 2 であると思われる。
キューを覗いてみる
次に rabbitmq の状態を確認する。rabbitmq にも他聞に漏れず Web 管理画面があるのでそれを使って rabbitmq の状態を確認してみる。rabbitmq が稼働しているホストのポート 25672 ポートにブラウザでアクセスすると以下のような管理画面にアクセスすることが出来る。
おお、とりあえず rabbitmq は動いているようだ。でも、キューの中身ってどうやって見るんだろうな...。
監視項目の追加
だいぶん遠回りしてしまったけど、監視の項目を追加してみる。監視の項目は以下のような種類から選んで追加を行う。
- Nagios Plugin
- Sensu Community Plugins
とりあえず Sensu Community Plugins から check-load.rb を追加する場合、以下のように puppet のマニフェストを書いた。
exec{'get_check-load':
cwd => "/etc/sensu/plugins/system/",
command => "/usr/bin/wget -q https://raw2.github.com/sensu/sensu-community-plugins/master/plugins/system/check-load.rb",
creates => "/etc/sensu/plugins/system/check-load.rb",
}
file{'/etc/sensu/plugins/system/check-load.rb':
mode => 0755,
require => Exec["get_check-load"],
}
package { 'sensu-plugin': ensure => latest, provider => 'gem' }
sensu::check { "loadaverage":
handlers => 'default',
command => '/etc/sensu/plugins/system/check-load.rb',
subscribers => 'sensu-test'
}
このマニフェストで puppet apply すると以下のようにファイルが生成されて sensu-client が再起動する。
/etc/sensu/conf.d/checks/loadaverage.json
中身は以下のような JSON となっている。
{ "checks": { "loadaverage": { "handlers": [ "default" ], "subscribers": [ "sensu-test" ], "interval": 60, "command": "/etc/sensu/plugins/system/check-load.rb", "standalone": true } } }
Dockerfile の修正
ということで、今回、ちょっと深堀したので検証に作成した Dockerfile を以下のように修正した。
ホスト名の定義
facter を使ってホスト名を自動で登録させるようにした。facter は chef で言うところの ohai にあたるツール。
rabbitmq_ssl_cert_chain => "puppet:///mount_point/sensu/client/cert.pem", rabbitmq_host => 'localhost', subscriptions => 'sensu-test', client_name => "${hostname}", #=> これ client_address => 'localhost' }
${hostname} にはコンテナのホスト名が定義される。
出来るだけ puppet で設定を収束させる
Dockerfileにワーってコマンドを並べると汎用性と可読性が懸念されるのでpuppetで頑張るpuppetでもchefでもいいんだけど...
次回は
Handlerを少し掘り下げてみたいpuppetのサバクラ構成でsensuクライアントの設定を自動化させるserfと組み合わせればも少し設定の手間を減らせる環境を構築出来そうなので試してみる
