I/F link down障害検知が約1分で復旧状態に遷移してしまう
いつもお世話になっております。
標題の件について、助言いただけますと幸いです。
■検証環境
OS:RHEL7.4（SElinux、firewalld無効済み）
Zabbix:3.4.5
監視対象：cisco 3560、Windows
■適用しているトリガー
名前：Interface {#IFDESCR}: Link down
条件式：{$IFCONTROL:"{#IFNAME}"}=1 and ({ホスト名:net.if.status[ifOperStatus.{#SNMPINDEX}].last()}=2 and {ホスト名:net.if.status[ifOperStatus.{#SNMPINDEX}].diff()}=1)
※LLDにてデフォルトのトリガープロトタイプを用いて自動生成したトリガーを使用しています。
■実現したいこと
監視対象のポートのlink up状態からlink downに遷移したときに発報させたい。
また上記、link down状態からlink upに遷移したときに「解決済」という形で復旧表示させたい。
上記デフォルトのトリガーでいけるのではと、設定し抜線試験を行ったところ、Interface ＜インタフェース名＞: Link downと表示され発報してくれたのですが、
約1分ほどで「解決済」と表示され復旧状態になってしまいます。 ※この間、挿線は行っておりません
想定では、再度link upとなるまで障害が通知されるかと思っていたのですが、毎回1分ほどで解決済となってしまいます。
トリガーの意味を読み違えてますでしょうか？
監視対象は冗長構成等は組んでおらず単一のポートです。
お手数ですが、ご教示いただけますと幸いです。
lunamio - 投稿数: 12
すみません、アイテム情報を記載するのを失念しておりました。
添付のとおりです。
※これもデフォルトを使用しています
wakaba - 投稿数: 228
広瀬です
私は単純にこれだけで、ダウン、アップ通知正常に来ますよ。
{＜テンプレート名＞:ifOperStatus[{#IFDESCR}].diff(0)}=1
ポートUp/Downがフラッピング状態に陥る事態が発生するなら、機械的な故障やケーブル損傷も
あり得ますが、ケース的にはかなり少ないと思うので細かい処置はしないことにしてます。
$IFCONTROLのユーザマクロに何を投入されているか解りかねますので、トリガー条件式の意図が
判断できないため、簡単な回答ですがご参考程度に
lunamio - 投稿数: 12
コメントありがとうございます。
ご教示いただいた式、参考にさせていただきます。
明日にでも検証環境で試してみます。
＞$IFCONTROLのユーザマクロに何を投入されているか
すみません、記載を失念しておりました。値はデフォルトの1となります。
また、上記マクロについての認識があやふやなままデフォルトの式を使用していたのですが
どういったことを指すマクロなのかご教示いただけませんでしょうか。
マニュアルも一読したのですが、読み落としている可能性が高く。
よろしくお願い致します。
wakaba - 投稿数: 228
広瀬です
$で始まるものは、ユーザ定義マクロとなります。ご自身で何かしらの意図があり、
作成される変数のようなものです。
※何を示すと言われても逆に聞きたいくらいなのですが・・・
・・・なので、ZABBIX上には元々存在しない設定値を示すものとなりますので、
済みませんが、その点についてはお答え出来かねます。
https://www.zabbix.com/documentation/2.2/jp/manual/config/macros/usermacros
ユーザ定義マクロについては上記をご参考下さい。日本語訳が2.2の時代までしか
無いので、お使いのVerが3.4.5はさらに変化しているので、最新のVerも参考に
願います。
lunamio - 投稿数: 12
言葉足らずで申し訳ありません。
意図して作成していないにもかかわらず、デフォルトですでに存在していたので
それが何を示しているのかが不明という意でした。
どちらにせよ、理解しきれていない部分があるため今後掘り下げて検証してみたいと思います。
ちなみにですが、linkup/down検知の件、下記の条件式で想定どおりの動きをしてくれました。
障害条件式：({＜テンプレート名＞:net.if.status[ifOperStatus.{#SNMPINDEX}].last()}=2 and {＜テンプレート名＞:net.if.status[ifOperStatus.{#SNMPINDEX}].diff()}=1)
復旧条件式：({＜テンプレート名＞:net.if.status[ifOperStatus.{#SNMPINDEX}].last()}=1)
fripper - 投稿数: 495
＞＞障害条件式：({＜テンプレート名＞:net.if.status[ifOperStatus.{#SNMPINDEX}].last()}=2 and {＜テンプレート名＞:net.if.status[ifOperStatus.{#SNMPINDEX}].diff()}=1)
テンプレート・デフォルトの条件式のままだと
{#SNMPINDEX}番のポートに関する「最新のチェック結果がLink-down(2)」で、なおかつ、「１つ手前のチェック結果との差分値が１」だった場合‥
という条件となっているので
Link-downの発生直後、１回目のチェック時点では「最新のチェック結果がLink-down(2)」の条件と
「１つ手前のチェック結果との差分値が１」の条件を両方満たしているので「障害発生」として検知されます
Link-downの発生後、２回目のチェックでは、「最新のチェック結果がLink-down(2)」の条件は満たしているのですが
「１つ手前のチェック結果との差分値が１」の条件を満たさなくなってしまい「障害復旧」となってしまったのだと思います
＞＞復旧条件式：({＜テンプレート名＞:net.if.status[ifOperStatus.{#SNMPINDEX}].last()}=1)
という復旧条件式を設定したことによって、
「最新のチェック結果がLink-up(1)」という条件になりますので、意図された動作となったのだと思います
テンプレート・デフォルトの条件式で「１つ手前のチェック結果との差分値が１」という条件がわざわざ記載されているのは
推測でしか言えないのですが、
「もともとLink-downだったポートに対して、テンプレートが適用され、監視項目・トリガーが設定された場合」に
大量の警告・障害検知が発生してしまうトラブルを未然に防ぎたかった‥という意図があったのではないかと推測します
lunamio - 投稿数: 12
ご返信いただきありがとうござます。
また返信遅れまして申し訳ございません。
＞Link-downの発生後、２回目のチェックでは、「最新のチェック結果がLink-down(2)」の条件は満たしているのですが
＞「１つ手前のチェック結果との差分値が１」の条件を満たさなくなってしまい「障害復旧」となってしまったのだと思います
条件を満たさなくなったとき復旧となってしまうのですね。
大変参考になります。
＞「もともとLink-downだったポートに対して、テンプレートが適用され、監視項目・トリガーが設定された場合」に
＞大量の警告・障害検知が発生してしまうトラブルを未然に防ぎたかった‥という意図があったのではないかと推測します
port shsutdownしていないポートなどが検知されてしまうということですね。
ここは当方も気にしているところでしたのですっきりしました。※NW導入ベンダが別なため、port shutdownを指定することもできず。。。