Nagios

序論

イベントハンドラ

イベントハンドラは、ホストかサービス・ステータスの変化が起こった時はいつも実行される任意のシステム・コマンド(スクリプトか実行形式)です。

イベントハンドラのはっきりした利用は、だれかが見つける前にNagiosが障害を率先して修理する使い方です。 イベントハンドラへの他の用途は:

* ホストの電源再投入は経験的問題で、簡単に自動スクリプトを実装すべきではありません。 自動再起動を実装する前に、慎重にこの結果を考えます。

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

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

ソフトとハード・ステータスはここで詳細に説明されます。

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

ホストと状態変更を扱うために定義できる違ったタイプのオプションのイベントハンドラがあります:

グローバルなホストとサービスのイベントハンドラは、全てのホストやサービスで発生した状態変化のために実行されます。ホスト特有またはサービス特有のイベントの直前でハンドラは実行されるかもしれません。 あなたのメイン設定ファイルでglobal_host_event_handler とglobal_service_event_handler オプションを使用することによって、グローバルなイベントハンドラ・コマンドを指定できます。

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

イベントハンドラを可能にします。

プログラム全体のベースでenable_event_handlersをメイン設定ファイルで使用することでイベントハンドラを可能または無効にすることができます。

ホストとサービス特有のイベントハンドラーは、event_handler_enabled指示を使用することによって、可能か、無効にすることができます。 ホストとサービス特有のイベントハンドラーは、グローバルなenable_event_handlers オプションが禁止されていると実行されません。

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

既に言及されるように、グローバルなホストとサービス・イベントハンドラはホストかサービス特有のイベントハンドラの直前実行されます。

ハード障害のためにイベントハンドラを実行し、復旧ステータスの通知を直後に出します。

イベントハンドラ・コマンドを書きます。

イベントハンドラ・コマンドは、おそらくシェルかパール・スクリプトになりますが、それらは、コマンド・プロンプトから走ることができる実行可能のどんなタイプであってもよいです。 最小限、スクリプトは引数として以下のマクロを取るべきです:

サービスのために: $SERVICESTATE$, $SERVICESTATETYPE$, $SERVICEATTEMPT$

ホストのために: $HOSTSTATE$, $HOSTSTATETYPE$, $HOSTATTEMPT$

スクリプトは、それに渡された引数の値を調べ、それらの値に基づき必要な動作を行うべきです。 イベントハンドラがどのように働くかを理解する最も良い方法は、例を見ることです。 あなたにとって幸運である1つが以下にあります。

チップ チップ: 追加のイベントハンドラー・サンプルスクリプトはNagiosが配布されているサブディレクトリ contrib/eventhandlers/ で見つけることができます。 Some of these sample scripts demonstrate the use of external commands to implement a redundant and distributed monitoring environments. これらのサンプル・スクリプトのいくつかは、冗長系、分散系の監視環境に当てはまる外部コマンド利用のデモです。

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

通常、イベントハンドラ・コマンドは、あなたのマシンで動いているNagiosユーザの何らかの許可の下で実行されます。 これは一つの問題があります。それは、システム・サービスを再起動するイベントハンドラを書きたいなら、ルート特権がこの種類のタスクを実行するのに一般に必要と言うことです。

理想的には、実装しているイベントハンドラのタイプを評価して、必要なシステム・コマンドを実行するために十分な許可をNagiosユーザに与えるべきです。 これを達成するのにsudoを使用したいかもしれません。

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

以下の例は、ローカルのマシンの上でHTTPサーバを監視していて、HTTPサービス定義のイベントハンドラ・コマンドとしてrestart-httpdを指定したと仮定します。 また、私は、サービスのmax_check_attemptオプションが4かそれ以上に設定されたと仮定しています(すなわち、実際の障害と認識される前に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回(「柔らかい」状態で)再試行されるか、またはWebサービスがどうにか 
#       「困難な」誤り状態に落ちるなら。 
#   

# どんな状態で、HTTPサービスがありますか? 
case "$1" in

OK)
    # サービスがただ来て戻ったので、何もしません…     
    ;;

WARNING) # 警告
    # それでも、サービスがたぶん走行であって、私たちは本当に警告ステータスを心配しません…
    ;;

UNKNOWN) # 未知
    # 私たちが、何が未知の誤りを引き起こしているかもしれないかを知らないので、何もしません…
    ;;

CRITICAL) # 批判的である
    # ああ!  HTTPサービスは問題を持っているように見えます--おそらく、私たちはサーバを再起動するべきです…      

    # これは、「柔らかい」状態ですかそれとも「困難な」状態ですか?
    case "$2" in

        # 私たちは「柔らかい」状態にあります、Nagiosが「困難な」状態に変わって、接触が通知     
        # される前に、チェックを再試行する中央にあることを意味して…
        SOFT) # 柔らかさ


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

            # ウェブサーバーを再起動する3回前にチェックが試みられるまで、待っています。チェック         
            # が4回目に失敗すると(私たちがウェブサーバーを再起動した後に)、ステータスのタイプは「困難に」         
            # ターンします、そして、接触は問題について通知されます。  うまくいけば、これが首尾よ         
            # くウェブサーバーを再起動するので、4番目のチェックは「柔らかい」回復をもたらします。          
            #  それが起こるなら、私たちが問題を修正したので、だれも通知されません!
            3)
                # HTTPがサービス(3番目の柔らかいきわどい状態)であると再起動し」ながら、-nを反響します…             
                echo -n "Restarting HTTP service (3rd soft critical state)..."
		/etc/rc.d/init.d/httpd restart
		;;
            esac
		;;

	# The HTTP service somehow managed to turn into a hard error without getting fixed.
	# It should have been restarted by the code above, but for some reason it didn't.
	# Let's give it one last try, shall we?
	# Note: Contacts have already been notified of a problem with the service at this
	# point (unless you disabled notifications for this service)
	HARD)
		echo -n "Restarting HTTP service..."
		# Call the init script to restart the HTTPD server
		/etc/rc.d/init.d/httpd restart
		;;
	        esac
        ;;
esac
exit 0

上に提供されたサンプル・スクリプトは、ローカルのマシンの上で2つの異なったインスタンスでウェブサーバーの再起動を試みます:

スクリプトは理論的にはサービスの障害が固定される前に障害を直し、Webサーバを再起動すべきです。しかし最初は働かない予備のイベントのケースも含まれています。 イベントハンドラはサービスがHARD障害状態になる1回目だけ実行されることに注意すべきです。 これは、サービスがHARD障害状態のままでNagiosがウェブサーバーの再起動を繰り返すスクリプトを作るのを防ぎます。 それが欲しいと思いません。

する事のこれが全てです! イベントハンドラはかなり簡単にかけて実装できます。そこで、それをやってみて、できることを見ます。

参照 参照: 状態タイプ, ホスト・チェック, サービス・チェック

English Deutsch 日本語

目次