syslogなのに復旧メールが飛んできてしまった。

Centos7
zabbix_server (Zabbix) 3.0.7

ご質問
messages.logの監視を行っております。
今までは、トラブルなく順調に稼働していたのですが、今回次のような事象が発生いたしました。
ご教授頂きたくよろしくお願いいたします。

①下記のメールが2017.05.10 12:04:24に発報されまして、こちらは正常な動作だと思います。
 今までも同様なメッセージが発報されております。
====================================
Zabbix監視アラート
====================================
<障害検知状況>
  ・障害発生日時:2017.05.10 12:04:24
  ・対象ホスト:ab-c-d-efghij1
  ・監視項目:[LOG] Syslog Warning Check
  ・監視キー: log[/var/log/messages,@xx_zzz_SYSLOG_WAR_REGEXP,,,skip]
  ・ステータス:PROBLEM
  ・障害情報:May 10 12:04:23 ab-c-d-efghij1 server: 重大: The web application [/mm/come/ws] appears to have started a thread named [logback-1] but has failed to stop it. This is very likely to create a memory leak.
  ・重要度:Warning

②本日、下記の障害復旧メールが通知されました、今まではmessages.logで発生したものは、復旧検知など起こり得るわけが無いと思っていたのですがこのような発報がありました。
====================================
Zabbix監視アラート
====================================
<復旧検知状況>
  ・障害発生日時:2017.05.10 12:04:24
  ・障害復旧日時:2017.05.12 12:08:24
  ・対象ホスト:ab-c-d-efghij1
  ・監視項目:[LOG] Syslog Warning Check
  ・ステータス:PROBLEM
  ・復旧情報:May 12 12:08:24 ab-c-d-efghij1 server: 重大: The web application [/mm/come/ws] appears to have started a thread named [logback-1] but has failed to stop it. This is very likely to create a memory leak.
  ・重要度:Warning

※補足説明
補足①
@xx_zzz_SYSLOG_WAR_REGEXP=
([eE][rR][rR])|([cC][rR][iI][tT])|([wW][aA][rR])|([fF][aA][iI][lL])|([rR][eE][mM][oO][vV][eE][dD])|link status definitely down
結果が真

補足②
障害イベントを継続して生成 ☑あり

補足③
・本日対象サーバをメンテナンスモードに設定している最中に発生しております。
・データ収集あり

Q1.なぜmessages.log監視なのに復旧メールが発報されたのでしょうか
Q2.メンテナンスモード時間帯なのに何故?
  同時間内で発生したアラートは発報されていません。

コメント表示オプション

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

Q1
条件式に含まれているアイテム側の設定は
log[/var/log/messages,@xx_zzz_SYSLOG_WAR_REGEXP,,,skip]
となっているとのことですが、トリガーの条件式では、このアイテムを含む条件式を
どのように設定されているでしょうか?

Q2
メンテナンス期間中には、新規に発生した障害発生のメールは通知されませんが
メンテナンス期間突入前に発動していたトリガーアクションの流れの一環として、
復旧が発生した場合に、回復の通知処理が実行される仕様となっていたはずです
(メンテナンス期間中にログアイテムの最新値として追加収集された値が、
 トリガー条件式で「回復」と判定され、回復通知がされた)

★Q2回答の補足
しかし、回復メール本文中に記載のあるログ文字列は、「(略)has failed to stop(略)」と
なっているように見え、これは「回復」の条件を満たさないかもしれません(Q1の条件式次第)

1.「回復」の条件を満たすログが追加収集され
 1.「回復」の通知処理を実行する流れに移行したあと
  1.さらに追加のログが収集され(これは障害発生の条件を満たすものだが、メンテナンス期間中のため通知されず)
   1.「回復」通知処理のなかで「最新のログ収集値」がメールに記載された

これについては、アクションのメール本文部へ指定するマクロが
「{ITEM.LASTVALUE<1-9>}」を利用している場合に発生します
トリガーアクションの発動時(発動条件を満たした瞬間の値)を記載したい場合には
「{ITEM.LASTVALUE<1-9>}」の代わりに「{ITEM.VALUE<1-9>}」を
利用すると良いかもしれません

ユーザー Apollon1006 の写真

fripper さん
早速のコメントありがとうございます。
取り急ぎお礼まで