監視システムは登場人物が多くなるので、うまくいかないときにどこに問題があるのかパッと見わかりづらい.
どういう連携で監視システムが動いているのか全体構成を把握することと、サービス単体でチェックする方法、ログの見方などをおさえることが大事と思う.
curlでsensu-apiたたく、jqでjsonのsyntaxチェックするなどのテクニックも重要.

■サービスポート

※自分の環境の情報です

service	default port
sensu-client	3030
sensu-api	4567
uchiwa	3000
rabbitmq-server	5672
redis-server	6379

■ログ

※自分の環境の情報です

service	log path
sensu-server	/var/log/sensu/sensu-server.log
sensu-client	/var/log/sensu/sensu-client.log
sensu-api	/var/log/sensu/sensu-api.log
uchiwa	/var/log/uchiwa.{log,err}
rabbitmq	/var/log/rabbitmq

■sensu checkステータス

status	description
0	OK
1	WARNING
2	CRITICAL
3以上	UNKNOWN or CUSTOM

■jq install

## 
## RHEL系にインストールする
## 
cd /usr/local/src
wget "http://stedolan.github.io/jq/download/linux64/jq"
chmod +x jq

echo '{"test": "test"}' | ./jq .
  # json parse test
mv -i jq  /usr/bin/

■sensu server <=> sensu-clientの連携

sensu-clientとsensu-serverの監視業務の概要をつかんでおくといいと思う.
http://qiita.com/metheglin/items/edd332d577b6e167ac67

sensu-server,sensu-client <=> rabbitmq通信に失敗する

rabbitmqと通信できないとsensuは稼働しない.
rabbitmqと疎通できないと以下のようなログが出る.

/var/log/sensu/sensu-server.log

{"timestamp":"2015-04-23T00:27:23.907604+0900","level":"error","message":"[amqp] Detected TCP connection failure"}

@sensu-server
netstat -ln | grep 5672
  # rabbitmqプロセスが起動してport 5672をLISTENしているか確認する

rabbitmqデーモンが起動しているのに通信に失敗する場合、

protocol	daemon	port	description
tcp	rabbitmq	5672	開放必要(sensu-clientに向けて)
udp	rabbitmq	5672	開放不要っぽい(tcpdumpで確認した)

uchiwa/dashboardでclientが表示されない

sensu-apiがclientを認識しているか確認する
http://(sensu-apiのホスト名/IP):4567/clients

sensu-client起動できてはいるのに、sensu-apiでclientがとれない場合は、rabbitmqとの疎通に失敗している可能性が高い.
一つ前の手順にしたがって、rabbitmqのport開放やACLを確認する.
一回rabbitmqのvhost消してから作りなおしてもよさそう.

uchiwa/dashboardでclientの情報が更新されない

sensu-clientのclient.json変更しただけではsensu-serverのredisの値が更新されない.
sensu-client再起動する必要がある.

# @sensu-client
sudo service sensu-client restart

sensu clientがメッセージを受信しているか単体チェック

/dev/tcpへのリダイレクトかncコマンドのいずれかでsensu-clientへ直接メッセージを届けることができる.

参考):
http://sensuapp.org/docs/0.17/clients#what-are-sensu-clients

# @sensu-client

echo '{"name": "sensu-client-check", "output": "sensu-client-check", "status": 1}' > /dev/tcp/localhost/3030
echo '{"name": "sensu-client-check", "output": "sensu-client-check", "status": 1}' | nc localhost 3030

tail -F  /var/log/sensu/sensu-client.log
  # ログが出ることを確認

一度登録したsensu checkを削除する

redisにログインしてflushallする.
※sensu以外のデータストアとしてredisを使っていないか注意しておこなってください
※もっと正しいやりかたあると思いますが、知っているかたいたら教えてください！

uchiwa/dashboardでsensu checkが認識されない

uchiwaやdashboardはsensu-apiから情報を取得しているので、sensu-apiがsensu checkの追加を認識できていない可能性がある.
sensu-apiはredisから情報をとってきているので、redisに追加されていない可能性がある.

sensu-apiがsensu checkを認識しているか確認する
http://(sensu-apiのホスト名/IP):4567/checks

1-2. sensu-serverを再起動する

# @sensu-server
sudo service sensu-server restart
# @sensu-api
sudo service sensu-api restart

1-3. 認識されないsensu checkのjsonにsyntax errorなどがないか確認する

@sensu-server
cat vmstat_metrics.json  | jq '.'
parse error: Expected separator between values at line 7, column 16

/var/log/sensu/sensu-server.logをよく見ると、sensu-server起動時にエラーメッセージが出ている.
sensu check jsonファイル名でgrepして、message枠にエラーが出ていないか確認する.

/var/log/sensu/sensu-server.log

{"timestamp":"2015-04-19T16:41:27.241425+0900","level":"warn","message":"config file must be valid json","file":"/etc/sensu/conf.d/vmstat_metrics.json","error":"parse error: after key and value, inside map, I expect ',' or '}'\n          eme stats.:::name:::\"       \"interval\": 60,       \"subscribe\n                     (right here) ------^\n"}

json parse errorになっているときのsensu-server.log

sensu checkプロセス監視が想定外の動き

こんな人はあまりいないと思うけど、滑稽なはまりかたをしたので共有.
sensu checkのプロセス監視でcronデーモンの監視をしかけた.
試しにcronデーモンを落としてアラートが上がるかチェックしていたが、アラートが来ない...
監視対象サーバにログインしてみて、checkコマンドを直接打つと、あるときはCRITICALになり、あるときはOKになり、全く予期できない動きをした.

原因は、デバッグのために別窓で実行していたtail -F /var/log/sensu/sensu-client.log | grep cronコマンドだったw tail -Fは常駐するのでプロセス一覧出したときにgrep cronのところにcron文字列がヒットするためcronプロセスが生きていると判断されてしまう.

プロセス名を含むバッチを動かすときも問題になるかも.

handlerが機能していない気がする

handlerの文法確認する

https://sensuapp.org/docs/latest/checks
よくある問題だけど、handlers複数形の場合は配列形式で複数のハンドラを指定できるけど、handler単数形の場合は文字列形式で一つだけ指定できる.

1-2. 対応するhandlerが存在するか確認する

grep -r "graphite" /etc/sensu/conf.d/
  # "graphite"という名前になっているhandlerのjson設定があるか探す
  # 以下の形式のjsonが存在して、sensuユーザにread権限あれば問題なし.
  # {"handlers", {
  #   "graphite": {...
  #

1-3. handlerを配列形式で複数指定した場合、一つでも無効なhandlerがあるとすべてのhandlerが認識されない

handlers: ["debug", "graphite"]
と書いていたが、debug handlerが存在しなかったためか、graphite handlerまでが無効となってしまっている.
debugを外すとうまくいって、以下のようにsensu-server.logに出るようになる.

■修正前

handlers: ["debug", "graphite"]と設定したがdebug handlerが存在しない.

sensu-server.log

{"timestamp":"2015-04-22T14:25:53.997086+0900","level":"warn","message":"loading config file","file":"/etc/sensu/conf.d/cpu_metrics.json"}

↑handlersがjsonに出てこないため設定がおかしい.

■修正後

handlers: ["graphite"]

sensu-server.log

{"timestamp":"2015-04-22T14:25:53.997096+0900","level":"warn","message":"config file applied changes","file":"/etc/sensu/conf.d/cpu_metrics.json","changes":{"checks":{"cpu_metrics":[null,{"type":"metric","command":"/etc/sensu/plugins/cpu-metrics.rb","subscribers":["all"],"interval":10,"handlers":["graphite"]}]}}}

↑handlersが認識されていることがわかる

2回目以降のhandlerが実行されない？

1分間隔で死活監視していると、プロセス落としたときに1分間隔でアラートが来てかなりうるさい.
これを防ぐために、障害発生時のhandlerはいい感じに間隔をあけて実行してくれる機能がついている.

	default	memo
refresh	1800	どの間隔でhandlerを実行するか調整できる
inteval	60	sensu check jsonに記述したcheck実行間隔

イベント継続回数がrefresh / intervalで割り切れる数のときのみhandlerが実行される.

sensu handlerのテストをしているときはこの機能があると、長い時間待たなければいけないので逆に邪魔になる.
uchiwaでeventを選択して、resolvを押してイベント解決してしまえばイベント継続回数が0にリセットされるので、再度handlerを実行できる.
または、Events APIのresolveを実行してもよい.
https://sensuapp.org/docs/latest/api-events

sensu eventsのresolveができない

uchiwaが機能しているか確認

uchiwaでresolve操作したときにresolve操作のログが出ることを確認

{"timestamp":"2015-04-23T12:23:23.585168+0900","level":"info","message":"POST /resolve","remote_address":"127.0.0.1","user_agent":"Go 1.1 package http","request_method":"POST","request_uri":"/resolve","request_body":"{\"check\":\"cron\",\"client\":\"stg-wsaneys201\"}\n\n"}

sensu-apiが機能しているか確認

sensu-apiでresolve実行するときのログ

sensu-api.log

{"timestamp":"2015-04-23T14:10:50.937077+0900","level":"info","message":"publishing check result","payload":{"client":"stg-wsaneys201","check":{"command":"/etc/sensu/plugins/check-procs.rb -p cron","subscribers":["production"],"interval":60,"name":"cron","issued":1429765850,"executed":1429765850,"duration":0.051,"output":"Resolving on request of the API","status":0,"total_state_change":0,"force_resolve":true}}}

sensuの途中のバージョンから微妙にresolve apiのインタフェースかわってるので、最新のドキュメント（またはそのバージョンのドキュメント）を確認する.
https://sensuapp.org/docs/latest/api-events

resolve apiをcurlで確認する例.
--dump-header -をつけてレスポンスヘッダを確認したほうがいい.

curl --dump-header - -X POST -d '{"check":"cron","client":"sensu-client"}' http://(sensu-apiのホスト):4567/resolve

  # eventが存在しないとき
  # HTTP/1.1 404 Not Found

  # eventが存在するとき
  # HTTP/1.1 202 Accepted
  # {"issued":1433564961}

rabbitmqとの疎通を確認

sensu-apiも異常なさそうだったら、rabbitmqとの疎通を確認する.
resolveすると、sensu-apiがredisを直接操作すると思っていたが、rabbitmqにメッセージを送り、それを受信したsensu-serverがイベント解決処理をおこなう.
一番上記載のrabbitmq通信に失敗するケースを調査する.

Environment

sensu version 0.17

$ cat /etc/issue
Amazon Linux AMI release 2015.03
Kernel \r on an \m

$ uname -a
Linux *** 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux