メンテナンス期間なのに「xxxxx has just been restarted」が送信されてしまいます
はじめまして、こんにちは。
いつも本サイトを参考にさせて頂いており、勉強させて頂いております。ありがとうございます。
zabbixはまだ初めて１ヶ月ほどの初心者です。よろしくお願いいたします。
Zabbixバージョンは、2.2.3を利用しており、
約５０台のサーバを監視しております。
その中で、１０台ほどのサーバが毎晩再起動するため、その再起動の時間帯は
アラートを飛ばさないように設定したいと思い、以下の設定を行いました。
-----------------------------------------------------------------------
【メンテナンス】
メンテナンスタイプ：収集なし
開始日時＝2014/7/11 00:00:00～2017/7/12 00:00:00
【期間】
期間のタイプ＝毎日
繰り返し間隔＝１
開始時刻＝3:55
メンテナンス期間＝30分
【ホスト＆グループ】
XXXXX0SV
XXXXX1SV
XXXXX2SV
XXXXX3SV
XXXXX4SV
XXXXX5SV
XXXXX6SV
XXXXX7SV
XXXXX8SV
XXXXX9SV
-----------------------------------------------------------------------
上記の設定を行い、サーバの再起動時間は「4:00」です。
サーバ側のイベントビューアを見ると、「4:00～4:03」の間には再起動が終わっております。
早速上記の設定を有効にして監視しているのですが、
毎朝以下のアラートが飛んでしまいます。
※アラートが飛んだ時間「4:25」
Trigger: XXXXX0SV has just been restarted
Trigger status: PROBLEM
Trigger severity: Average
Trigger URL:
Item values:
1. System uptime (XXXXX0SV:system.uptime): 00:24:48
2. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
3. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
Original event ID: 11032
実際のサーバ再起動時間は4:00～4:03なのに、なぜ上記のようなアラートが飛んでくるのでしょうか？
自分なりに調べてみたのですが、時刻がずれているわけでもありません。
もしご存知の方がいましたら、何かヒントを頂ければと思い投稿いたしました。
よろしくお願いします。
fripper - 投稿数: 495
トリガーの発動条件式はどのようになっていますでしょうか？
トリガー名から想像するに、デフォルトのテンプレートとして用意されている
「再起動検知」のトリガーが反応しているように見受けられますが‥
デフォルトの「再起動検知」トリガーですと、以下のような条件式になっています
{Template OS Linux:system.uptime.change(0)}＜0
このままですと、メンテナンス中にデータ取得を停止している場合には
メンテナンス開始直前に取得した稼働時間情報 約23時間？
と
メンテナンス終了直後に取得した稼働時間情報 約25分
とを比較し、変化量がマイナスのため、トリガーが発動してしまうことになります
トリガーの発動条件を見直すなどの対策が必要となります
saito_r - 投稿数: 9
fripper様
アドバイス有難うござます。
ご指摘の通り、テンプレートのまま利用しておりました。
{Template OS Windows:system.uptime.change(0)}<0
このまま利用していました。これではダメなのですね。
実は自分で調べた際に、
---------------------------------------
1. System uptime (XXXXX0SV:system.uptime): 00:24:48
---------------------------------------
上記のエラーから、ご指摘のトリガーを見ていたのですが、
ヘルプなどを見ても、解説が乏しく、このキーがいったいどのような意味なのかわからずにいました。
テンプレートだから、大丈夫だろうと、それ以上深く調べておりませんでした。
■system.uptime
→システムの起動時間
■change(0)
→最新データと一つ前のデータの差異を返す
頂いたアドバイスを元に、更に調べてみたのですが、各キーとトリガー関数は上記の様な説明でした。
この条件をどのようにカスタマイズすれば思い通りの結果がでるのか、わからずにおります。
(1)メンテナンス時間は再起動のアラームが飛ばないようにする
(2)(1)以外の時間帯は再起動のアラームを飛ばす
これらの条件で運用するためには、下記の条件式[<0] をどのように設定すれば良いのでしょうか？
{Template OS Windows:system.uptime.change(0)}<0
お忙しい中、申し訳ありませんが、よろしくお願い致します。
saito_r - 投稿数: 9
自己レスです・・・
トリガーの発動条件を自分なりに、考えてみました。
{Template OS Windows:system.uptime.last(0)}<300
起動時間が300秒（５分）以下の場合、エラーとする・・・
といった記述に変更して調整すべき、という意味ですよね？
fripper - 投稿数: 495
saito_r 様
仰るように、Windows 用のテンプレートでは、last を使った表現で、ｘｘｘ秒以内だったらNG‥という
条件になっているようです。
今回の Linux テンプレートでも、同じような、時間条件だけをご利用環境の都合に合わせたもの‥
（ last(0) ＜ 3600 等） にすることで、回避できるかと思います
saito_r - 投稿数: 9
fripper様
アドバイスいただき、ありがとうございます。
さっそく、last関数を使って、秒数を調整して様子を見てみようと思います。
助かりました。ありがとうございました。
TNK - 投稿数: 4671
少しだけ補足させて頂きます。
とのことですが、
に設定されていたのが原因だと思われます。
fripperさんが書かれている通り、メンテナンス期間の間、値の収
集を行わず、メンテナンス期間終了後に収集された値が、今回の場
合、
メンテナンス期間開始直前の値(3:55よりも前)
と
メンテナンス期間終了直後(3:55の30分後 = 4:25以降)
の値の差分が負になってトリガーが発生したのでしょう。
データ収集ありでメンテナンス期間を設定しておくと、メンテナン
ス期間であっても値の取得が行われるので、サーバを再起動した直
後のみトリガーは発生しますが、アクションの実行条件に、
メンテナンスの状態 期間外 メンテナンス
が設定されていれば、メンテナンス期間中にアクションが実行され
ることはありません。
今回の対応策としては、書かれていたような、
というような条件式であれば、4:03頃には再起動が終わっていて、
4:25あたりに値の取得が再開されるでしょうから、uptimeの値は
5分以上になり、メンテナンス期間終了後にアクションが実行され
ることはなくなると思います。
saito_r - 投稿数: 9
TNK 様
はじめまして、コメントありがとうございます。
詳細な解説、助かります。
メンテナンスタイプが、そういう事に影響しているのですね、全く気づけませんでした。
メンテナンス期間は、問答無用で「収集無し」とするのが当たり前と・・・勝手に決めつけておりましたが、
稼働時間の事を考えると、収集すべきですね。
自分で「＜３００」と設定していたものの、まだ若干モヤっとしていたのですが、
最後に書いていただいた、解説でようやく完全にわかりました。
本当に、ありがとうございました。
TNK - 投稿数: 4671
メンテナンス期間内の値収集は、収集していても良いのですが、
メンテナンス作業のために一時的にサーバの負荷が上昇してい
たり、試験的にテスト用のトラフィックを発生させたりなど様々
なテストを行ったりする場合も考えられるため、後でグラフを
見たときなどに通常の運用時には考えられない負荷の高い時間帯
があったり、最大値に通常の運用時以外の値も含まれたりするこ
とにもご注意ください。
余計な値の記録は不要と考えるか、メンテナンス作業中の値も
参考に取得しておくことも有用と考えるか、運用のポリシーなど
に合わせてご検討ください。
saito_r - 投稿数: 9
TNK様
こんにちは。再度のお返事ありがとうございます。
----------------------------------------------
たり、試験的にテスト用のトラフィックを発生させたりなど様々
なテストを行ったりする場合も考えられるため、後でグラフを
----------------------------------------------
⇒確かにご指摘の通りでした。
メンテナンス期間は平日日中とは異なる処理が流れますので
サーバ負荷上昇は十分に考えられますよね。考えが甘かったです。
メンテナンス中の動きを十分思慮した上で、ログの収集を決めたいと思います。
Zabbixの導入を始めたばかりで、ルールや運用ポリシーなどがまだ決まっていませんが
ご指摘いただいた点を考えると、これらのルール決めは重要ですね。
早速決めていきたいと思います。
本来なら自分で調べるべきところ
すっかり甘えてしまいました。
本当にありがとうございました。