閾値監視を目的としたトリガーで依存関係を設定すると正常に動作しない。
いつもお世話になっております。xxjashixxと申します。
トリガーの依存関係について以下の問題が発生しています。
※環境
OS：RHEL 6.4
Zabbixバージョン：Zabbix-2.0.8
以下のようなテンプレートAを作成しホストAにリンクさせたところ想定したイベント動作になりません。
・テンプレートA
アイテムA(itemkey = vfs.fs.size[/,pused])
トリガーA (条件式 = {FS:vfs.fs.size[/,pused].count(#2,90,ge)}=2)
トリガーB （条件式 = {FS:vfs.fs.size[/,pused].count(#2,80,ge)}=2) ※依存先：トリガーA
・想定するイベント動作
検知事象
対象領域の使用率を瞬間的に90%以上へ
想定動作
トリガーの依存関係によりトリガーAのみイベント検知
実際の動作
トリガーA,B共にイベントとして検知
ZabbixSIAのカスタマーフォーラム(ZBX-3163 & ZBX-6016)の内容から、依存関係を持つトリガーを作成
する時の制約としてTriggerIDの採番順序が関係しているという所までは分りました。
しかし、テンプレート作成時に上記制約に配慮しトリガーを作成しましたがテンプレートをホストにリンクさ
せた際にその採番順序が変わってしまい正常に動作しない様です。
テンプレートA
アイテムA
トリガーA TriggerID=10001
トリガーB TriggerID=10002（トリガーAに依存）
テンプレートリンク後のTriggerID
ホストA
アイテムA（テンプレートA）
トリガーA TriggerID=11002
トリガーB TriggerID=11001（トリガーAに依存）
採番順序が変わってしまう要因として調べた結果、どうやらトリガー関数の引数に設定している閾値に
対して昇順で採番をしているものと推測します。
試しに以下の設定を行い動作確認をした所、想定した動作になることを確認致しました。
itemkeyを使用率(pused)から未使用率(pfree)に変更
・テンプレートA
アイテムA(itemkey = vfs.fs.size[/,pfree])
トリガーA (条件式 = {FS:vfs.fs.size[/,pfree].count(#2,10,le)}=2) ：TriggerID=10001
トリガーB （条件式 = {FS:vfs.fs.size[/,pfree].count(#2,20,le)}=2) ※依存先：トリガーA ：TriggerID=10002
テンプレートリンク後のTriggerID
ホストA
アイテムA（テンプレートA）
トリガーA TriggerID=11001
トリガーB TriggerID=11002（トリガーAに依存）
昇順で対応できる物については対応できますが、snmp監視等については未使用率ではなく使用率で
しか取得できない物も存在します。
そもそも閾値監視を行うようなトリガーの依存関係については想定していないのでしょうか。
内容についてお気づきの点が御座いましたらご返答頂けると幸いです。
宜しくお願い致します。
TNK - 投稿数: 4742
トリガーの依存関係を利用するパターンとして、例えば、ネットワ
ークがダウンしたら、その先のサーバにはアクセスできないので、
値が取得できなくてもトリガーを発生させない、とか別のアイテム
に対する評価をするために利用することができます。
同じアイテムに対して行うのであれば、別の方法を取られた方が良
いでしょう。
通常はテンプレートで、テンプレートを割り当てているすべてのサ
ーバで同じ閾値で監視を行って一時的に特定のサーバだけ閾値を変
えたいということであれば、ユーザマクロを利用したテンプレート
を作成して、個別に閾値を変えたいホストのマクロで同じマクロ名
で別の閾値を指定するような方法が考えられます。
または、一度障害が発生したら、数値が安定するまで閾値を変更す
るということであれば、TRIGGER.VALUEを利用して、障害状態であ
るかないかで別の閾値を指定するような条件式を書くことで実現で
きたと思います。
ということを、なぜ設定されたいのか、その意図が理解できていな
いので、回答になっているかわかりませんが、もう少しどのような
目的であるのかをお教えいただければ、別の方法で対処できるかも
しれません。
heya - 投稿数: 319
こんにちは。
想像ですが、例えば、値が順に 78%, 83%, 89%, 92% と変化していくときは、83% のときに 80% 超過の通知、92% のときに 90% 超過の通知が出ます。これはいいんですが、75%, 78%, 93% のように一気に（80% を通り越して）90% を超えたときには、80% 超過の通知と 90% 超過の通知が両方同時に出てしまうことになります。これが 90% 超過の通知だけの方が分かりやすい、ということかなと思います。
ただこの場合回復時はどうするんだとか一筋縄ではいかなさそうな気がしますが・・・。
xxjashixx - 投稿数: 5
TNK様、heya様
ご返答ありがとうございます。
当方の望む動作としてはheyaさまが仰られている内容となります。
復旧時の動作としては"90%"の閾値超過から正常に推移した際は"90%"の復旧メッセージ
"90%"から緩やかに推移していく場合には"90%"を下回った際に"90%"の復旧通知、"80%"
の障害通知となり"80%"を下回って"80%"の復旧通知となります。
TriggerIDの制約に従い設定すると想定した動作になりますが、TNK様の仰っている内容か
らそもそもトリガーの依存関係を設定する際の制約が死活監視であることとなるならば当
方の設計ミスと言う事になりますね。
heya - 投稿数: 319
こんにちは。
＞"90%"から緩やかに推移していく場合には"90%"を下回った際に"90%"の復旧通知、"80%"
＞の障害通知となり"80%"を下回って"80%"の復旧通知となります。
これだったら、ややこしいことはしなくてもトリガーBを「80%以上90%未満」という条件にすればいいのでは？
{FS:vfs.fs.size[/,pused].count(#2,80,ge)}=2&{FS:vfs.fs.size[/,pused].count(#2,90,lt)}=2
・・・と思ったんですが、これだとダメそうです。
この場合、緩やかに増加して 90% 以上になったときトリガーBが回復になるのと、90% 前後を行ったり来たりするときにトリガーAもBも条件を満たさなくなるという問題があります。
例えば 75%, 83%, 86%, 92%, 88%, 91%, 70% となったとき、86% になった時点でトリガーBが障害になりますが、その次 92% になったときは「二回連続 80～90%」という条件を満たさずにトリガーBは回復、しかしその後「二回連続 90% 以上」というトリガーAの条件には一度も当てはまらない、ということになってしまいます。二回連続でなく一回だけでいいなら大丈夫なんですけどね。
うーん、やっぱり難しい。
TNK - 投稿数: 4742
難しいですね。
heyaさんも書かれてますが、80から90までと90以上に分けると、90
を超えたところで、80から90の回復通知がきてしまうし.....。
ちょっと私も考えます。
xxjashixx - 投稿数: 5
TNK様、heya様
ご返答有難うございます。
依存関係が使用できないのであれば対応として依存関係を無効にするしかないと思っております。
ただ、正常に動作しているトリガーもあり残念という感じです。
検証をCPUのidle監視で行っていたので問題なく他の監視でも使用できると思っておりました。
依存関係については便利な面もあるので是非、死活以外の監視でも使用したいですね。
xxjashixx - 投稿数: 5
何時の間にかZBX-3163が2.2.4でFIXされてました。
まだ試していませんが、この件もトリガーの評価順序が改善された事により上手く動作しそうですね。
https://www.zabbix.com/documentation/2.2/jp/manual/introduction/whatsnew224
ただ工程の関係で安易にバージョンアップが出来ないのが残念です・・・。