Sensu impression

Sensu を調べたhttps://github.com/sensu/sensu.git

201207@sawanoboly

チーム向け資料、オチ無し

Sensu は４つのサブシステムと２つのバックエンド

Server 重要 : redis と RabbitMQ Client 重要 : RabbitMQ api ： Redis のフロントエンド、ほぼ不

要 Dashboard :API のフロントエンド、不要

RabbitMQ ：通信全部ココ経由 Redis ： Master のロックとヒストリとク

ライアントのステータス記憶

Master:Lock

DashBoard と合わせてRedis のフロントエンド

サーバが Queue(exchange は fanout)

2012-07-17 20:06:01: Message received

Node: rabbit@ub1204Exchange: webserversQueue: 378snzgkd1rd0vl8eulul209ymu14entRouting keys: [<<>>]Properties: [{<<"priority">>,signedint,0}, {<<"delivery_mode">>,signedint,1}, {<<"content_type">>,longstr,<<"application/octet-stream">>}]Payload: {"name":"cron_check","issued":1342580761}

協力： RabbitMQ Tracing Plugin

クライアントが Subscribe

2012-07-17 20:06:01: Message published

Node: rabbit@ub1204Exchange: webserversRouting keys: [<<>>]Properties: [{<<"priority">>,signedint,0}, {<<"delivery_mode">>,signedint,1}, {<<"content_type">>,longstr,<<"application/octet-stream">>}]Payload: {"name":"cron_check","issued":1342580761}

協力： RabbitMQ Tracing Plugin

タスク定義{ "checks": { "cron_check": { "handler": "default", "command": “/etc/sensu/plugins/check-procs.rb -p cron -C 1 ", "interval": 60, "subscribers": [ "webservers" ] })サーバ、クライアントとも共通の書式handler, interval はサーバでのみ値が有効command はクライアントのみ、あとは共通

クライアントの動作 RabbitMQ につなぐ、事前に

subscribers 対象を決めておく RabbitMQ から Queue を取る、受け取る

のは check の名前だけローカルの config に check の名前が含

まれていれば実行 RabbitMQ の ResultQueue に結果を

突っ込む※ -v ならデバッグに出力もする

ログは” Result” キューへ2012-07-17 20:06:01: Message received

Node: rabbit@ub1204Exchange: Queue: resultsRouting keys: [<<"results">>]Properties: [{<<"priority">>,signedint,0}, {<<"delivery_mode">>,signedint,1}, {<<"content_type">>,longstr,<<"application/octet-stream">>}]Payload: {"client":"210.153.xxx.xxx","check":{"name":"cron_check","issued":1342580761,"output":"CheckProcs OK: Found 1 matching processes; cmd /cron/\n","status":0,"duration":0.082}}

Result の payload は？Payload: {"client":"210.153.xxx.xxx","check":{"name":"cron_check","issued":1342580761,"output":"CheckProcs OK: Found 1 matching processes; cmd /cron/\n","status":0,"duration":0.082}}

まずデバッグログへステータスの数字のみを Redis のヒストリ (LIST) に追記、２０回

分 Status が０以外なら Redis のイベントにメッセージを記述しつつ

ハンドラへ Status ０時の生ログはなくなる

ハンドラはサーバで動作タイプは３つ pipe: 任意コマンドの STDIN へ

( でも json 形式？ ) amqp: rabbit の指定 Exchange へ set: もう指定した一度ハンドラへ

いいところ全部 RabbitMQ を通す Redis にロックを置いて、 Server 側が冗

長クライアントで負荷が偏らない Rabbit 次第でだいぶスケーラブル

修正したいところ Result 捨てちゃう点 Result で実行対象がわからない点 check_task がコマンドライン固定な点

=> 引数かコマンドラインまるごと渡すように拡張など(server.rb:setup_publisher,setting.rb:checks の周辺？ )

ソース探訪キューする内容、これに args か cmd を入れたらよさげ[server.rb:setup_publisher] if @rabbitmq.connected? payload = { :name => check[:name], :issued => Time.now.to_i }

デキューの際[client.rb:execute_check]check = JSON.parse(payload, :symbolize_names => true)-- command = @settings[:checks][check[:name]][:command].gsub(/:::(.*?):::/) do -- snip -- IO.popen(command + ' 2>&1') do |io| check[:output] = io.read end

フォークしよう

Technology

Sensu impression