はじめに
- 前回からの続きで...パッシブ監視の続き
参考
閑話休題
僕らはいつまで Nagios を使い続けるのだろう
いきなり閑話休題で恐縮だが、この記事を書いていたら以下のような資料が公開されていることを教えて頂いたので見てみた。
なんで Nagios を使っているか？ってところで「Everybody uses it.」て書かれて納得。ただ、多くのプラグインがある点については評価出来るとは思うが、スライドの作者が以下のように言及している*1
- スケールさせ辛い
- 設定が複雑
- まともなプラグラマティックなインターフェースが無い*2＝
APIのインターフェースが提供されていない
が言われてみると「ああ、確かに」と思ってしまう。折しも、今回、Nagira は上記の Nagios のイマイチな部分を補うことが出来そうな気がして触っていたりするのではあるが、将来的には上記のスライドにも紹介されている sensu を導入したいと企んでいる。
でも Nagios を使わないといけない...
でも、Nagios を使わないといけないのは上のスライドにもあるように「みんなが使っている（いた）から」というのと「既に使われていたから」という理由だけ。そんな中で Nagira で出来ることってスライドの中で言及されていた Nagios のイケてないところを多少でも補えているのかもしれない。
パッシブ監視の続き
どんなところで使うか
こちらを参考にさせて頂くと以下のような場面で使えそう。
Nagiosサーバーと監視対象の間が Firewall 等でアクティブ監視が難しい場合- NRPE 等のエージェントをインストールしたくない、出来ない場合
- 定期的では無くて異常が発生した場合のみアラートを上げたい場合
パッシブ監視を有効にする
インストール直後は既にパッシブ監視は有効になっているので特に設定は不要だが、個別に有効にする場合には nagios.cfg の accept_passive_service_checks を 1 にして Nagios のプロセスを再起動する。
accept_passive_service_checks=1
また、個々のホスト、サービスでパッシブ監視を有効にする場合には passive_checks_enabled を 1 にする。（無効にする場合には 0 にする）
例えば、HOGE というサービスをパッシブ監視したい場合には以下のように設定する。
/etc/nagios3/conf.d/services_nagios2.cfg に以下を追加する。
define service {
hostgroup_name hoge-servers
service_description HOGE
check_command check_dummy!0
use generic-service
notification_interval 0 ; set > 0 if you want to be renotified
active_checks_enabled 0
passive_checks_enabled 1
}
合わせて hostgroups_nagios2.cfg に以下を追加...
define hostgroup {
hostgroup_name hoge-servers
alias HOGE servers
members localhost
}
更に /etc/nagios3/command.cfg に以下を追加。
# 'check_dummy' command definition
define command{
command_name check_dummy
command_line $USER1$/check_dummy $ARG1$
}
ん、、、かなり面倒くさいが、この状態で以下を実行して設定の確認。
nagios3 -v /etc/nagios3/nagios.cfg
エラー等が出ない場合には...
/etc/init.d/nagios3 restart
で Nagios を再起動する。正常に再起動されると以下のように監視項目として追加される。
Nagira を経由で監視結果を登録する
パッシブ監視の結果を Nagios に送りつける場合に以下のようなフォーマットでデータを投げる必要がある。
ホスト監視の場合...
[<timestamp>] PROCESS_HOST_CHECK_RESULT;<host_name>;<host_status>;<plugin_output>
サービス監視の場合...
[<timestamp>] PROCESS_SERVICE_CHECK_RESULT;<host_name>;<svc_description>;<return_code>;<plugin_output>
これを nagira 経由で送る場合、例えばサービス監視の場合には以下のような JSON フォーマットで書くことが出来る。
{ "return_code":"0", "plugin_output" : "HOGE OK", "svc_description" : "HOGE", "service" : "HOGE" }
この JSON フォーマットのファイルを service_check.json 等の適当なファイル名で保存して以下のようにして Nagira に送る。
curl -s -XPUT -H "Content-type: application/json;" -d @service_check.json "http://${Nagios_Host}:4567/_status/localhost/_services/HOGE" | jq .
上記を実行すると以下のようなレスポンスが返ってくる。
{ "object": [ { "messages": [], "result": true, "data": { "action": "PROCESS_SERVICE_CHECK_RESULT", "host_name": "localhost", "service_description": "HOGE", "service": "HOGE", "svc_description": "HOGE", "plugin_output": "HOGE OK", "return_code": "0" } } ], "result": true }
そして、Nagios サーバーの /var/lib/nagios3/rw/nagios.cmd に以下のように登録されている。
[1392769099] PROCESS_SERVICE_CHECK_RESULT;localhost;HOGE;0;HOGE OK
とりあえず Nagira を介して Nagios へのパッシブ監視は成功したやに見えるが...
上図のようにいつまでたっても Web 画面上の State が Pending のままで変わらない...orz...Nagira 自身よりも Nagios の設定に問題がありそうなのでこれは引き続き調べたい。
まとめ
まとめという程でも無いけど...
- やっぱ
Nagiosは設定が面倒かも（監視システム自体がそれほど頻繁に設定変更するかどうかは置いといて） - でも
Nagiraを使うことでお手軽にNagiosのパッシブ監視が出来そう /var/lib/nagios3/rwへの書き込み権限が無い場合でもNagira自身はエラーにならずにレスポンスを返す挙動が見られたのでエラーハンドリングが少し甘いような気がする
