ログファイルサイズ比較の際、日にちを跨いだデータの比較を除外したい

現在下記の様に5分毎にログファイルのサイズ比較を行っています(午前0時にログロテート実施)。
({LogWatch:LogSize.last(#2)} - {LogWatch:LogSize.last(#1)} >= 0) and
(({LogWatch:LogSize.time(0)}<000000) or ({LogWatch:LogSize.time(0)}>001600))

これまでは24時間稼働だったので問題は無かったのですが、
夜間電力停止になる拠点の監視の場合、上記トリガーでは監視ホスト起動時に必ず監視通知が飛んでしまいます。
LogSizeから取得日付のみを比較し異なる場合監視を除外したいのですが、
どの様に書けば良いか分らず困っています。
よろしくお願いします。

コメント表示オプション

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

1.ZabbixとOSのバージョンを記載ください。
2.「夜間電力停止になる」が、どのようなパターンや規則で起きるのか教えてください。
3.たとえば監視対象AとBがあるとして、Bのみ「夜間電力停止になる」とした場合
  AとBは同じZabbixから、同じ監視テンプレートを使用して監視しておりますでしょうか。

ユーザー Masami Tanaka の写真

ご返信ありがとうございます。

> 1.ZabbixとOSのバージョンを記載ください。
zabbixバージョン:3.2.7
サーバOS:Linux(CentOS7.3)
監視ホストOS:Win7 エンベデッド

> 2.「夜間電力停止になる」が、どのようなパターンや規則で起きるのか教えてください。
拠点により20時頃電源停止になるところや23時頃に停止するところ等様々です。
また起動時刻は午前8時頃~10時頃と、どちらも人が電源を入り/切りして運用しています。

> 3.たとえば監視対象AとBがあるとして、Bのみ「夜間電力停止になる」とした場合
>   AとBは同じZabbixから、同じ監視テンプレートを使用して監視しておりますでしょうか。
監視拠点は数十ヶ所有り、全拠点同じ監視テンプレートから監視しています。

以上の環境です。
よろしくお願いします。

ユーザー Yasumi の写真

ありがとうございます。

現状私から提案できる内容ですが、トリガーで監視を制御するのではなく
アイテムの「監視間隔のカスタマイズ」を利用し、該当時間帯のみアイテム情報を取得しない方法です。
この方法を採用することで、複雑なトリガー設定をする必要がなくなります。

ただ、この場合、「ログファイルのサイズ」アイテムのみ
基本の監視テンプレートから除外して、ホストごとに個別の設定を入れる必要があります。
トリガー設定は既存のまま使いまわすことができると思われます。

ユーザー Masami Tanaka の写真

Yasumi様、ご返信ありがとうございます。

「監視間隔カスタマイズ」件情報ありがとうございます。
トリガーのカスタマイズに比べ柔軟に感じましたので利用したいと思ったのですが、
私の zabbix環境では登録したアイテムに「監視間隔カスタマイズ」項目が無いので調査したところ、
アイテムのタイプが「zabbixエージェント」ではなく「zabbixトラッパー」のアイテムであった為に、
利用出来ない仕様では無いかと感じています。

代替案としては、
① トリガーをカスタマイズする
② アイテムを「zabbixエージェント」で作り、ログサイズを vfs.file.size[file] 等で取得する

...など考えられます(取得するログサイズがWinアプリが吐くログで、ファイルOpen が出来ない場合、複数のファイルが発生する為、vfs.file.size[file] はそのままでは使えません)。
引き続き解決策の情報をお待ちしております。

ユーザー Yasumi の写真

トラッパーは「監視間隔のカスタマイズ」を使えないですね。

代替案1 トリガー依存関係 or トリガーへの抑止設定を使う
たとえば各ホストでアイテム「icmpping」を取得し、トリガーを設定していれば、
トリガー依存関係を使い、電源断(icmppingがdown)時に、ファイルサイズ監視をアクションさせない設定が考えられます。
ただし、この場合「icmpping」のアイテム取得間隔はファイルサイズのアイテム取得間隔より短いことなどが要求されます。

また、下記のように「icmpping」がUp(1)(ホスト起動時)にしかトリガーを動かさないという方法も考えられます。
({LogWatch:LogSize.last(#2)} - {LogWatch:LogSize.last(#1)} >= 0) and
(({LogWatch:LogSize.time(0)}<000000) or ({LogWatch:LogSize.time(0)}>001600)) and
({LogWatch:icmpping.last()}=1

※監視ホスト起動時に通知が飛んできているようなので、この対応が有効か微妙かもしれません。

代替案2 各ホストごとにトリガーを設定する
設定が個別化して煩雑ですが、こちらも一つの手です。

ユーザー Masami Tanaka の写真

Yasumi様、ご返信ありがとうございます。

情報ありがとうございます。

> また、下記のように「icmpping」がUp(1)(ホスト起動時)にしかトリガーを動かさないという方法も考えられます。
> ({LogWatch:LogSize.last(#2)} - {LogWatch:LogSize.last(#1)} >= 0) and
> (({LogWatch:LogSize.time(0)}<000000) or ({LogWatch:LogSize.time(0)}>001600)) and
> ({LogWatch:icmpping.last()}=1

「icmpping」を取得するトリガーは設定していませんでしたが、
ご指摘の様にこちらの値が接続した時刻から16分間は監視をスキップする方法を実現出来れば、
Winアプリログをロテート後にログサイズが減少してもLINE通知が飛ばない様に設定できる可能性が有ります。

例えば icmpping の「15分前、10分前、5分前、最新」の各値が全て疎通成功の場合のみ監視実行する等の条件を加えれば、
電源OFFから電源ONになって15分間は監視しない方法を上手く設定出来そうな気がしますが如何でしょうか?

よろしくお願いします。

ユーザー Yasumi の写真

{LogWatch:icmpping.count(#4,1,"eq")}=4

であれば、count関数を使うと良いかと思います。
内容としては、「直近4回のアイテム取得のうち、1(Up)と等しい値が4回カウント」されたらトリガー発報。

ユーザー Masami Tanaka の写真

Yasumi様、ご返信ありがとうございます。

> {LogWatch:icmpping.count(#4,1,"eq")}=4

icmpping監視アイテム追加後、トリガー条件に上記を加えたいと思います。
ありがとうございました。