トリガー関数 count が見る値の範囲について

■環境
Zabbix Version:2.4.3 (バージョン上げてないので古いですが…)

でWEB監視を実施しています。
サイトの作りが甘く、503応答が多いサイトなので、トリガー条件を緩くして対応しています。

トリガー条件: {test_website:web.test.fail[{$URL}].count(#2,0,"gt")}=2 and {test_website:web.test.rspcode[{$URL},{$URL}].last()}<>503

Webシナリオの応答コードは200を設定しています。

上記の条件の意図は、直近の2回の結果が2回とも失敗のステップが1つ以上あり、かつ、最終的な応答コードが503でない場合に発報する想定です。
しかし、以下の条件の時に意図せずに発報し、直後(1秒しない間)に復旧しています。

最新 200応答
1回前 503応答
2回前 503応答

count関数が最新の監視結果を見ずにその前の監視状態で判断しているように見えました。
トリガーの書き方が間違っているのでしょうか。

コメント表示オプション

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

推論も入ってしまうのですが・・・

web 監視のアイテムもまったく同時に更新されるわけではないようです。
※3.0 ですが、試しに設定したweb 監視のヒストリをDB上で確認したところ、nsで差が見えました。
+--------+------------+-------+-----------+
| itemid | clock | value | ns |
+--------+------------+-------+-----------+
| 26634 | 1528773346 | 200 | 178339599 | ※web.test.rspcode のアイテム
| 26630 | 1528773346 | 0 | 178585678 | ※web.test.fail のアイテム
+--------+------------+-------+-----------+

恐らく、以下挙動になったのではないでしょうか。

①web.test.rspcode のアイテム更新/トリガー判定
→ web.test.rspcode は最新を見るため「200」 + web.test.fail はまだ更新されていないため前回と前々回を使用して 2
= 条件一致→アラート発報

②web.test.fail のアイテム更新/トリガー判定
→ web.test.rspcode は最新を見るため「200」 + web.test.fail は最新二つで 1
= 条件不一致→アラート復旧

※詳しい方々、間違っていましたらご指摘ください。

ユーザー fripper の写真

トリガーの評価は、アイテム単位で値の更新があった場合に実施されるため
仰っておられる推論のとおりなのだと思います

Web監視の機能は、1項目の設定で仮想的に複数アイテムの値が更新されるような機能なので
トリガー条件に含まれる一部のアイテム値が更新された時点でも評価されてしまい
その時点では「障害」として検出
残りのアイテム値が更新された時点で再評価され、「復旧」として検出‥といった
処理の流れになってしまったのだと思います

現状の仕組み上、単純な設定等での回避は難しいのではないかと思います

ユーザー TH の写真

なるほどですね。
アイテムが同時に更新されるわけではないということですね。

だとすると、Webシナリオの応答コードを200と503にして、503が多発したときに別トリガーで発報するようにしてみようと思います。

あまりトリガーで細かいことやらない方がいいのかもしれませんね。