例外の更新間隔について

例外の更新間隔について教えてください
Windowsサービスの生死監視を行なっています。
Windowsサービスが稼働していなければ障害として検知するトリガーを設定しています。

但し、23:00〜23:10の間は該当のWindowsサービスが停止するため
この期間は監視停止するよう例外の更新間隔を設定しました。
が、23:05:40に返り値「6」で障害検知してしまいます。
例外の更新間隔は設定した時間(23:00)から有効にはならないのでしょうか

Zabbixサーバ:RHEL5.5 zabbix-1.8.3-1.el5.JP.i386.rpm
Zabbixエージェント:Windows2003 zabbix_agent-1.8.2-1.JP

「アイテム」
----------
ホスト :hostA
説明 :Windows サービス監視
タイプ :Zabbixエージェント
キー :service_state[DNS] *サービス名は例です
データ型 :数値 (整数)
データの形式 :10進数
単位 :
乗数を使用 :
乗数 :
更新間隔(秒) :60
例外の更新間隔 :間隔 600 sec at 1-7,23:00-23:10
ヒストリの保存期間(日):90
トレンドの保存期間(日):365
ステータス :有効
保存時の計算 :なし
値のマッピングの使用 :なし
アプリケーション :なし
----------

「トリガー」
----------
{hostA:service_state[DNS].last(0)}>0
----------

コメント表示オプション

お好みのコメント表示方法を選び「設定の保存」をクリックすると変更が反映されます。
ユーザー TNK の写真

例外の更新間隔は設定した時間(23:00)から有効にはならないのでしょうか

設定した時間丁度からにはならない場合があると思います。

確か、アイテムのチェックを実行する間隔は、チェックを行ったときに次に何秒後にチェックするかを保存していたと思います。
例えば、更新間隔が5分であった場合、例外として10分間隔で23:00-23:10という設定をしていたとします。
たまたま、22:59にそのアイテムのチェックが行われた場合、例外の時間帯にはまだ入っていないので、次のチェックは5分後の23:04に実行されると思います。その次は、23:04の時点では、例外の期間に入っていて間隔が10分なので、次のチェックは23:14分に実行されるというようになってしまうのではないでしょうか?
# 実際にソースの再確認はしていません。

ただし、書かれているようにアイテムの更新間隔が60秒に設定されているならば、よほど処理が遅れてキューにたまっているような状態でなければ、23:00-23:02頃までにチェックが実行されて検知される場合はあっても、5分も遅れて障害検知にはならないと思われます。
アイテムの更新間隔が60秒に設定されているか再度ご確認頂けませんでしょうか?

ご参考までに、私は定期的に停止時間帯があるようなサーバなどは、メンテナンス期間を設定してそのメンテナンス期間の間には障害を検知しても通知しないようにして運用しています。
1.8.3を利用されているのであれば、このメンテナンス期間の機能を利用されてはいかがでしょうか?

ユーザー ma34 の写真

TNKさん、返信ありがとうございます。

監視データ−最新データから該当のアイテムの値を確認して見ました。
時間    値
22:58:40  0
22:59:40  0
23:05:40  6
23:10:40  0
23:11:40  0

アイテムの更新間隔60秒で戻り値は取得できています。
23:00〜23:10の間は(23:05を除き)値を取得していないので、例外の期間設定は問題なさそうです。

メンテナンス期間はホスト単位/ホストグループ単位ごとになるので、該当サーバの監視要件を満たしません。
ただし、別サーバの監視には使えそうですので検討してみます。

ユーザー TNK の写真

もう一つ方法を考えてみました。

トリガーの条件式を以下のような式にしてみてください。
<code>
({hostA:service_state[DNS].last(0)}>0)&
(({hostA:service_state[DNS].time(0)} < 230000)|({hostA:service_state[DNS].time(0)} > 231000))
</code>
※本来は一行ですが、長くて見づらくなるので改行しています。

time()関数を利用して現在時刻(HHMMSSフォーマット)を取得し、それを23時より前と23時10分より後という条件も追加する形になります。

以下のURLにある「Example 9」を参考にしてみました。
http://www.zabbix.com/documentation/1.8/manual/config/triggers

ユーザー ma34 の写真

TNKさん

提示していただいたトリガー条件式で試してみたところ、
該当時間帯には検知されないことを確認できました。
ありがとうございます。

ユーザー ma34 の写真

お世話になります。

該当時間帯に抑止はできたのですが、
該当時間”外”にサービス停止が発生した際、
トリガーが複数回発生するようになりました。

具体的には
[監視データ]−[最新データ]
時間    値
10:10:40  0
10:11:40  0
10:12:40  0
-----サービス停止------
10:13:40  6
10:14:40  6

[監視データ]−[イベント]

サービス停止
10:13:40  xxxサービス 障害
10:14:00  xxxサービス 障害
10:14:30  xxxサービス 障害
10:14:40  xxxサービス 障害
10:15:00  xxxサービス 障害
10:15:30  xxxサービス 障害
10:15:40  xxxサービス 障害

上記の状態です。
条件式が間違っているのでしょうか

ユーザー ma34 の写真

以下のURLにある「Example 9」を参考に
該当時間”内”にサービス停止が発生したら、イベントが発生するように、トリガーを設定しテストしてみました。
http://www.zabbix.com/documentation/1.8/manual/config

({HostA:service_state[W32Time].last(0)}>0) &
({HostA:service_state[W32Time].time(0)}>130000) &
({HostA:service_state[W32Time].time(0)}<140000)

Zabbixサーバ 1.8.3
Zabbixエージェント 1.8.2

結果
13:23:45 障害
13:24:00 障害
13:24:30 障害
13:24:45 障害
13:25:00 障害
13:25:30 障害
13:25:45 障害

上記のように、アイテム取得時間(45秒のところ)のほかに、毎分00秒と30秒にもイベントが発生します。
time関数の条件式が評価されているようにも見えるのですが、
何か他に***.confあたりに設定値があるのでしょうか

ユーザー TNK の写真

「service_state[W32Time]」ではありませんが、手元の環境に同様の設定をしてみてもそのように複数回トリガーが発生することはありませんでした。

もしかして、トリガーの設定内の「イベント生成」に対して「ノーマル+障害イベントを継続して生成」を選択していませんか?
障害発生時に1回のみトリガーを発生させたい場合は、「ノーマル」を選択してください。

ユーザー ma34 の写真

TNKさん

障害発生時に複数回トリガーを発生させたいため、
トリガーの設定内の「イベント生成」に対して「ノーマル+障害イベントを継続して生成」を選択しています。

「ノーマル」を選択してテストしてみたところ、通知されます。
確認したところ、17:00:30にイベント生成されました。
アイテムの取得時間は16:59:45でした。

ユーザー TNK の写真

障害発生時に複数回トリガーを発生させたいため、
トリガーの設定内の「イベント生成」に対して「ノーマル+障害イベントを継続して生成」を選択しています。

ma34さんご自身でも書かれていますが、恐らく、time(0)の評価タイミングでもイベントが発生しているのだと思われます。

どのような目的で複数回トリガーを発生させたいのかがわかりませんが、障害が発生した際に定期的に複数回障害通知を行うことを実現されたいのであれば、エスカレーションの機能を利用された方が良いと思います。

「ノーマル」を選択してテストしてみたところ、通知されます。
確認したところ、17:00:30にイベント生成されました。
アイテムの取得時間は16:59:45でした。

書かれている内容を理解できないのですが、「ノーマル」にしても複数回通知されるということでしょうか?

設定を変更されてから、それが反映されるまで待ってから試験されましたか?
設定変更タイミングによっては、time(0)の評価タイミングがずれ込む可能性が考えられますので、設定変更を行ってしばらく待ってから再度確認してみてください。

ユーザー ma34 の写真

TNKさん

返信ありがとうございます。
エスカレーション機能については検討してみます。

「ノーマル」にしたところ、通知は1回で済みました。

設定変更ののち、反映を待ってテストしたところ、
アイテム取得時間と同時刻に通知されることを確認できました。
00秒に通知されたことから、time関数が優先されるのかと思いました。
混乱させてすみません。

恐らく、time(0)の評価タイミングでもイベントが発生しているのだと思われます。

ここのロジックはどのようになっているのでしょうかね。
(技術的な疑問として)

ユーザー TNK の写真

ここのロジックはどのようになっているのでしょうかね。
(技術的な疑問として)

興味がおありでしたら、ソースをご覧になられてみてはいかがでしょうか?

1.8.3(1.8.4)のソースを見ると以下のような処理になっているようです。

zabbix_serverは、src/zabbix_server/timer/timer.c 内の 関数:main_timer_loop() を呼び出していて、このメインループが、各分の00秒と30秒に 関数:process_time_functions() を呼び出しているようです。
そして、関数:process_time_functions() 内で、テーブル:triggers からトリガーを取り出して評価を実行しているようです。

アイテムの値の取得に関しては別の処理ループがあり、値を取得した後でその値を利用したトリガーの評価を行っていたはずです。

誤っているかもしれませんが、おおよそ上記のような処理ループになっていたと思います。

上で少しだけ触れましたが、zabbix_serverは、複数のプロセスがそれぞれ役割を持って起動されていて、プロセスの役割によっては別の処理ループで実行されるようになっているようです。
例えば、Pollerという役割は、設定されたアイテムの値を取得する役割を持ちます。
他にもIPMI用Pollerとか、Ping用Pollerなどがあります。

役割の違いによる処理ループの違いは、src/zabbix_serverserver.c をご覧下さい。