トリガーの判定が設定通りに行われない件
最近、不可解な事象が発生しましたので、みなさまの知恵を貸して頂ければと思い、質問を投稿いたします。
トリガーの判定式にマッチしていないにも関わらず、アクションメールが送られたり、OK メールが送られたりしたことがありました。
メモリの使用率監視です。
トリガー判定に用いているアイテムの値が以下のような推移にも関わらず、下記記載の1) トリガーの OK が返ってきたり、マッチしない状況でアクションメールが送られてきました。
私の設定およびトリガーの考え方が誤っていましたら、ご指摘ください。
Zabbix サーバーのバージョン:2.0.4
対象ホストの OS:Windows 2008 R2 Standard Edition
時刻 値
02:23:47 95
02:23:17 94
02:22:47 94 ←ここでOK
02:22:17 94 ←ここでアクションメール
02:21:47 94
02:21:17 93
02:20:47 93
02:20:17 92
02:19:47 92
02:19:17 91
02:18:47 91
02:18:17 91
02:17:47 91
02:17:17 90
02:16:47 90
02:16:17 89
02:15:47 89
10:39:17 29 ←ここでOK
10:38:47 29 ←ここでアクションメール
10:38:17 29
10:37:47 29
10:37:17 29
10:36:47 29
10:36:17 29
10:35:47 29
10:35:17 29
10:34:47 29
10:34:17 62
10:33:47 94
---------------------------
各設定は、以下の通りです。
トリガー:
1) {host01:vm.memory.size.pused.count(600,90,gt)}=10
2) {host01:vm.memory.size.pused.count(600,95,gt)}=10
キー:vm.memory.size.pused
100*last("vm.memory.size.used")/last("vm.memory.size[total]")
30 秒更新
キー:vm.memory.size.used
式:last("vm.memory.size[total]")-last("vm.memory.size[free]")
60 秒更新
アイテム:Total memory
キー:vm.memory.size[total]
3600 秒更新
アイテム名:Free memory
キー:vm.memory.size[free]
60 秒更新
TNK - 投稿数: 4760
例えば、トリガー 1)に関してですが、vm.memory.size.pusedが90
を超える回数が600秒で10回だったらということですので、
02:17:47 91
02:18:17 91
....
02:22:17 94 ←ここでアクションメール
と10個めでトリガーの設定どおり、正しくアクションが実行されて
いるように見受けられます。
どのような条件で通知するようにされたいのかをお教えください。
koji.bz - 投稿数: 20
TNK 様
返信、ありがとうございます。
ご指摘の部分のアクションは、私も問題ないと思ってます。
私の質問が悪かったのですが、以下の点が疑問に感じた部分となります。
1) 02:22:17 94 ←ここでアクションメール
この後の値が、[94]のままなのに、OK メールが送信された
2) 10:39:17 29 ←ここでOK
10:38:47 29 ←ここでアクションメール
10:38:17 29
と、こちらは[90%]を下回ったカウントが10個目でアクションが発生している
TNK - 投稿数: 4760
1)は、10個ではなく11個になったので条件に合致しなくなるため、
回復だと判断されたのだと思います。
2)の方は、その前のアイテムの情報がわからないのですが、同様に
countの値が10個以外の条件になったのではないかと思われます。
600秒と指定されているのですから、10分前の値から数を確認して
みてください。
koji.bz - 投稿数: 20
TNK 様
早急な回答、ありがとうございます。
「カウント」と言う事だと、おっしゃっている意味合いに合致しています。
もう一度、値を洗い直してみます。
確認後、再度コメントいたします。
koji.bz - 投稿数: 20
自分で書いてて何ですが、元アイテムの更新時間が 30 秒なのに、トリガー式では[600 秒で、閾値を超えた値を 10 回越えたら]としています。
元々は、60 秒間隔で値を取得し、600 秒の間で閾値を 10 回越えたらアラート(10 回連続で閾値超え)、との考え方だったようです。
監視の要件を再確認したところ、[10 分間閾値を超えたらアラート]としたいとのことですので、アイテムの更新時間を変更するのは必要ですが、「カウント」だと今回のような事に陥りそうです。
2) の部分については、値が以下の状態でした。
90 を下回った後に、10 回カウントしてトリガーが出て、OK が来ている状態でした。
時刻 値
10:40:47 29
10:40:17 29
10:39:47 29
10:39:17 29 ←ここでOK
10:38:47 29 ←ここでトリガー
10:38:17 29
10:37:47 29
10:37:17 29
10:36:47 29
10:36:17 29
10:35:47 29
10:35:17 29
10:34:47 29
10:34:17 62 ←ここから 90 を切っている
10:33:47 94
10:33:17 94
10:32:47 94
10:32:17 94
10:31:47 94
10:31:17 94
10:30:47 94
10:30:17 94
10:29:47 94
10:29:17 94
TNK - 投稿数: 4760
繰り返しになってしまうと思いますが、条件式が、
ではなく、
になっています。
10回を超えたらということであれば、不等号を利用して
{host01:vm.memory.size.pused.count(600,90,gt)}>10
などと条件式を修正する必要があると思います。
ではありません。
過去10分間で90を超えるのが、10:29:17の回から数えてちょうど
10回になってトリガーが発生し、10:39:17になって10分前から数
えると9回になったのでOKになったという状態だと思われます。
ご確認ください。
koji.bz - 投稿数: 20
TNK 様
返信、ありがとうございます。
不等号の件、ごもっともです。
修正いたします。
2) の件は、「9 回になったのでOK」は、ご説明頂いた内容で理解できます。
10:38:47 で過去 10 分間で 90 以上を 10 回検知したことになりますが、10:33:47 の時点でトリガーがなかったことが、私としては理解できないです。
何か、私のトリガー式に関する認識が誤っているのでしょうか。
koji.bz - 投稿数: 20
自己レスです。
もう一度、トリガーで指定しているアイテムの値を眺めて、確認しました。
TNK 様のご指摘通りの結果となりました。
お騒がせしました。
TNK 様、的確な回答を頂き、ありがとうございました。