「イベントハンドラ」の版間の差分

2010年8月23日 (月) 22:40時点における最新版

1 初めに
2 イベントハンドラはいつ実行されますか?
3 イベントハンドラのタイプ
4 イベントハンドラを可能にする
5 イベントハンドラ実行命令
6 イベントハンドラコマンドを書く
7 イベントハンドラコマンドのための許可
8 サービスイベントハンドラの例

初めに

イベントハンドラは、ホストまたはサービス状態の変化が起こるときはいつも実行される、任意のシステム・コマンド(スクリプトか実行出来うるもの)です。

明らかなのは、誰かが気付く前に、Nagiosが問題を予測して修正する能力がイベントハンドラのために使用される事です。イベントハンドラのための他のいくつかの用途は:

失敗したサービスの再起動
ヘルプデスクシステムに問題チケットを入れます。
イベント情報をデータベースに登録します。
*ホスト上でパワーを循環させます。
など。

* 自動スクリプトに関する問題を経験しているホスト上でパワーを循環させるのは、簡単に行うべきではありません。自動再起動を実行する前に、慎重にこの結果を熟考してください。 :-)

イベントハンドラはいつ実行されますか?

サービスかホストである時、イベントハンドラは実行されます:

SOFTは問題ある状態か
初めに、HARDの問題ある状態を調べます。
初めに、SOFTまたはHARDの問題ある状態から回復します。

SOFTとHARDの状態がここで詳細に説明されている。

イベントハンドラのタイプ

あなたがホストと状態変更を扱うために定義できる、任意のイベントハンドラの異なったタイプがあります:

グローバルなホストイベントハンドラ
グローバルなサービスイベントハンドラ
ホスト特有のイベントハンドラ
サービス特有のイベントハンドラ

グローバルホストとサービスイベントハンドラはすぐに優先して実行されるかも知れない、どんなホストまたはサービス特有のイベントハンドラにも生じる、あらゆるホストまたはサービス状態変化のために忙しくなります。あなたは自分の主な構成ファイル上で、global_host_event_handler と global_service_event_handler オプションを使用することによって、グローバルなイベントハンドラコマンドを指定できます。

ホストとサービス個々は、状態変更を扱うために実行されるべきであるそれら自身のイベントハンドラコマンドを持つことができます。あなたはあなたのホストとサービス定義における event_handlerの設定を使用することによって実行されるべきイベントハンドラを指定できます。 (任意)のグローバルホストかサービス特有のイベントハンドラが処理された後に、これらのホストとサービス特有のイベントハンドラは処理されます。

イベントハンドラを可能にする

プログラム全体ベースで、あなたの主な構成ファイルにおけるenable_event_handlers を使用することによって、イベントハンドラを可能にするか、または無効にすることができます。

あなたのホストとサービス定義におけるevent_handler_enabledの設定を使用することによって、ホストとサービス特有のイベントハンドラを可能にするか、または無効にすることができます。 enable_event_handlers というグローバルなオプションに障害があると、ホストとサービス特有のイベントハンドラは処理されないでしょう。

イベントハンドラ実行命令

既に言及されているように、グローバルなホストとサービスイベントハンドラは、ホストまたはサービス特有のイベントハンドラの直前に処理されます。 HARDの問題によってイベントハンドラを実行します、そして通知を送出した直後、状態を回復します。

イベントハンドラコマンドを書く

イベントハンドラコマンドは、おそらくシェルかパールスクリプトになるでしょうが、それらは、コマンド・プロンプトから動くことができる実行可能のどんなタイプであってもよいです。最低限、スクリプトは、議論として下記のマクロにすべきです:

サービス用: $SERVICESTATE$, $SERVICESTATETYPE$, $SERVICEATTEMPT$ ホスト用: $HOSTSTATE$, $HOSTSTATETYPE$, $HOSTATTEMPT$

そのスクリプトは、それにパスした引数の値を審査して、それらの値に基づくあらゆる必要なアクションを取るべきです。イベントハンドラがどのように働くかを理解する最も良い方法は、例を見ることです。あなたにとって幸運なことに、下記に1つ、提供されています。

ヒント: Nagiosディストリビューションに関するcontrib/eventhandlers/サブディレクトリにおいて追加サンプルイベントハンドラスクリプトを見つけることができます。これらのサンプルスクリプトのいくつかが余分に分配されたの監視環境を実行する外部のコマンド環境の使用を示します。

イベントハンドラコマンドのための許可

イベントハンドラコマンドは通常、あなたのマシン上でNagiosが動いている下でのユーザと同様の、同じパーミッションで動いています。タスクのこれらの種類を実行するのには一般にはroot権限が必要であるのと同様に、あなたがシステムサービスを再起動するイベントハンドラを書きたいなら、これは問題を提示できます。

理想的なのは、あなたは、あなたが実装するイベントハンドラのタイプを評価して、必要なシステムコマンドを実行するためにNagiosユーザのちょうど十分なパーミッションを承諾するべきです。あなたはこれを成し遂げるのにsudoを使用してみたがっているかもしれません。

サービスイベントハンドラの例

以下の例は、あなたがローカルのマシンの上でHTTPサーバを監視していて、HTTPサービス定義のためのイベントハンドラコマンドとしてrestart-httpdを指定したと仮定します。また、私は、あなたがサービスを4以上の値にするためのmax_check_attemptsオプションを設定したと仮定しています。 (本当の問題があるか考察される前に、サービスは4回チェックされます。) 簡略化された例のサービス定義はこれに似るかもしれません…。

define service{

	host_name			somehost

	service_description	HTTP

	max_check_attempts		4

	event_handler		restart-httpd

	...

	}

サービスがイベントハンドラでいったん定義されると、私たちはそのイベントハンドラをコマンドとして定義しなければなりません。 restart-httpdのための例のコマンド定義は以下に示されています。私がイベントハンドラスクリプトをパスしているコマンドラインにおけるマクロに注意してください - これらは重要です!

define command{

	command_name	restart-httpd

	command_line	/usr/local/nagios/libexec/eventhandlers/restart-httpd  $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$

	}

今、実際に、イベントハンドラスクリプトを書いてみましょう。 (これは/usr/local/nagios/libexec/eventhandlers/restart-httpdスクリプトです)。

#!/bin/sh
#
# ローカルのマシン上でウェブサーバーを再起動するためのイベントハンドラスクリプト
#
# 注意: サービスが3回(「soft」状態で)再試行されるか、または
#       Webサービスがどうにか「hardな」エラー状態に陥る場合にだけ、
#       このスクリプトはウェブサーバーを再起動するでしょう。
#
# どんな状態でHTTPサービスがありますか?

case "$1" in

OK)
	# サービスが丁度、戻った来たので、何もしないでください…
	;;

WARNING)
	# サービスがたぶんまだ稼働していて、本当に私たちはwarning状態を心配しません…
	;;

UNKNOWN)
	# 私たちが、何が未知のエラーを引き起こしている可能性があるかを知らないので、何もしないでください…
	;;

CRITICAL)
	# ああ!  HTTPサービスに問題があるに見えます--おそらく、サーバを再起動するべきです…
	# これは "ソフト" 状態？ "ハード" 状態？
	case "$2" in

	# Nagiosが「ハード」状態に変わって、コンタクトが通知される前に
	# チェックを再試行する最中にあることを意味する「ソフト」状態にあります。

	SOFT)

		# どんなチェック試みに、私たちがいますか?  それがまさしく、まぐれ当たりであるかもしれないので
		# 私たちは、最初のチェックの際にウェブサーバーを再起動したくはありません!

		case "$3" in

		# ウェブサーバーを再起動する前に、チェックが三回試みられるまで、待ってください。
		# チェックが4回目に失敗すると(私たちがウェブサーバーを再起動した後に)、
		# 状態のタイプは「ハード」になり、コンタクトは問題を通知するでしょう。
		# 上手くいけば、これが首尾よくウェブサーバーを再起動するので、
		# 4番目のチェックは「ソフト」回復をもたらすでしょう。
		# もしそれが起こるなら、私たちが問題を修正したので何も通知されません!

		3)
			echo -n "Restarting HTTP service (3rd soft critical state)..."

			# HTTPDサーバを再起動するために、イニットスクリプトを呼び出して下さい。

			/etc/rc.d/init.d/httpd restart
			;;
			esac
		;;

	# HTTPサービスは修正されず、どういう訳かハードエラーに変わりました。
	# そうしなかった理由がなかったのなら、上記のコードによって再起動されるべきでした。
	# それに最後のトライを与えて良いですか？
	# 注意: コンタクトはこのポイントにおけるサービスに関する問題について既に通知されました。
	# (あなたがこのサービスのための通知を無効にしなかったなら)。

	HARD)
		echo -n "Restarting HTTP service..."
		# HTTPDサーバを再起動するために、イニットスクリプトを呼び出して下さい。
		/etc/rc.d/init.d/httpd restart
		;;
	esac
	;;
esac
exit 0

上に提供されたサンプルスクリプトは、2つの異なったインスタンスにおいてローカルのマシン上でウェブサーバーを再起動しようとするでしょう:

サービスが3回目、再チェックされた後、SOFT CRITICAL状態にある時
サービスが最初にHARD CRITICAL状態に入る時

理論的に再起動するべきそのスクリプトとウェブサーバーは、サービスがHARD問題状態に入る前にその問題を解決するが、それは初回には動かないイベントで、予備の場合に含みます。イベントハンドラは、サービスがHARD問題状態になる1回目に実行されるだけであることに注意するべきです。これは、サービスがHARD問題状態に残っているなら、Nagiosがウェブサーバーを再起動するために絶え間なくスクリプトを実行するのを防ぎます。あなたはそれをしたくない。 :-)

それをするため、それが全てです! イベントハンドラは、書いて実行するのはかなり簡単です。そしてそれをやってみて、あなたができることを確かめて下さい。