現在、zabbix 3.0.8 を利用しております。

アラート発報後、受信したzabbixアラートのメールを
見ると本文の最後がかける事象が発生しました。
文字数の問題やマクロ関数の定義など
疑いましたが何をやっても最後の行が
欠けます。。

こちらについてご教示頂けますと助かります。
後日、エンドユーザにて近々納品の予定がありまして
大変困っております。
お力を頂けますと幸いです。

■欠けたときのアクションのメッセージ文

Date: {EVENT.RECOVERY.DATE}.{EVENT.RECOVERY.TIME}
Service: {TRIGGER.NAME}
Hostgroup: xxxx
Host: {HOST.NAME}
Address: {HOST.IP}
Status: {TRIGGER.STATUS}

■受信したメールのメッセージ文

Date: 2018.06.14.16:43:23
Service: web-test01 is unavailable by ICMP
Hostgroup: xxxx
Host: web-test01
Address: xxx.xxx.xxx.xxx
Statu 　　←　このようにかけます。

初めまして
掲題の件について質問いたします。

zabbixバージョン：3.4.4　Revision 74338
監視対象：HP P2000 G3 FC

【アイテムの設定】
タイプ：SSHエージェント
キー：ssh.run
ホストインターフェース：IPアドレス:22
認証方式：パスワード
ユーザー名：入力済
パスワード：入力済
実行するスクリプト：show events
データ型：ログ
更新間隔：30s

Cannot read data from SSH serverとなり、データの取得ができない
他のPCからtera termにてsshで接続して、show eventsを実行できたので、監視対象へのssh接続はできると考えています。
show eventsを実行したときにとれるログをzabbixで監視したいと考えております。

よろしくお願いいたします。

お世話になっております。

V3.0.16を使用しております。

自作シェルスクリプト内でzabbixAPIを使ってtriggerのステータス変更を行なった直後、(Sleepなどは明示的に指定せず、約1秒後に)zabbixAgentやミドルウェアのプロセスを停止しています。
zabbixAPIによるトリガーのステータス変更はDBにも即時反映されることはMariaDBにSQLを投げて確認しています。

しかし、DBに反映されているものの、zabbixServer側に反映されていないようで、障害通知が送られてしまいます。
`zabbix_server -R config_cache_reload` をAPIコール直後に叩いたり、zabbix_server.confのConfigUpdateFrequencyを1秒にしても、障害として検知されてしまいます。

主に障害として検知されてしまうのはzabbixAgentのagent.ping().nodata()のnodata関数なので、timerプロセスに設定が即時反映されていないのだと思います。
timerプロセスにDBの値を即時反映することは可能でしょうか？またはそもそもtimerプロセスが原因ではないですか？

よろしくお願いします。

Zabbix 3.4.10 を使用しています。
定期的に障害の数をメールで通知するために、擬似的なトリガーを作成しました。
トリガーに対するアクションのメール本文で次のマクロを使用しました。
{TRIGGER.EVENTS.PROBLEM.UNACK}

障害の数は通知されてくるのですが、擬似的なトリガーも障害の数に含まれてしまいます。
復旧時のみメール通知を行うようにしても同様に障害の数に含まれてしまいます。
実際の障害の数（何も起こっていなければ0）が通知されるのが理想ですが、
標準機能での実現は難しいでしょうか。

■環境
Zabbix Version：2.4.3 (バージョン上げてないので古いですが…)

でWEB監視を実施しています。
サイトの作りが甘く、503応答が多いサイトなので、トリガー条件を緩くして対応しています。

トリガー条件: {test_website:web.test.fail[{$URL}].count(#2,0,"gt")}=2 and {test_website:web.test.rspcode[{$URL},{$URL}].last()}<>503

Webシナリオの応答コードは200を設定しています。

上記の条件の意図は、直近の2回の結果が2回とも失敗のステップが1つ以上あり、かつ、最終的な応答コードが503でない場合に発報する想定です。
しかし、以下の条件の時に意図せずに発報し、直後(1秒しない間)に復旧しています。

最新　200応答
1回前　503応答
2回前　503応答

count関数が最新の監視結果を見ずにその前の監視状態で判断しているように見えました。
トリガーの書き方が間違っているのでしょうか。