いくつか気になった点がありましたので書き込みさせていただきます。

dondocさん
>アイテムのログには、障害として検知するログが1つは出力されているのですが、
>30秒おきにイベントで障害として検知しているログが存在してないという意味です。
>
>例：
>17:00:00　error　←障害として検知(アイテムにログが存在する)
>17:00:30 ←障害として検知(※ログが存在しない)
(略)
>17:06:00 ←障害復旧

条件式にnodataが含まれる場合、指定した時間内にヒストリがあるかどうかを30秒ごとに自動的にチェックします。
この場合、17:00:00に取得したヒストリを検証してますが、それ以降、新規のヒストリがなくても検証し続けます。
17:00:30のイベントは、”最後のヒストリに文字列が含まれている” かつ ”nodataの指定時間内にヒストリがある”
ため、障害としてイベント生成されています。
17:06:00で”最後のヒストリに文字列が含まれている” しかし ”nodataの指定時間内にヒストリがない”
ため、復旧と判断されています。(ちなみに、それ以降も継続して30秒ごとにチェックはされ続けます。)

>nodata関数は指定した期間にDBにデータが書き込まれるかどうかを見ている関数ですが、
>障害と判定されたデータかどうかも評価してしまうのでしょうか？

ヒストリ(データ)はあくまで監視結果であって、”障害と判定されたデータかどうか”という情報は持っていません。
ヒストリをトリガーで判定し、条件式に合致したら障害イベントを生成します。
nodataは対象アイテムの最後のヒストリのタイムスタンプ(zabbixnに取得した時間)を比較するだけです。

yk_taikoさん
>◆30秒ごとに判定する理由
>nodata などの時間系関数を使用した場合は「毎分0秒と30秒」のタイミングでトリガー判定が走ります。

nodata などの判定タイミングは、(最後にヒストリを取得して、トリガーが検証されてから)30秒ごとになるので、
”毎分0秒、30秒” ではありません。
（ 仮に、10:00:15に、ヒストリが更新され、その後変化がない場合、
　　10:00:15→10:00:45→10:01:15…
　　に検証されることになります。)

Yasumi-sha さん
>「障害イベントを継続して生成する」を入れていると、条件に合致した回数だけトリガーは動作します。
>ここはnodataを使っていても同じです。それが30秒ごとになるだけで。

障害イベントを生成するかどうかなので、チェックにかかわらずトリガーによる判定は、ヒストリが更新されたタイミング(& nodataの30秒ごと)で行われます。
条件式に一致した場合、チェックが入っていると、トリガーの状態が”障害”でも ”障害イベントを生成”しますが、
チェックが入っていなければ、”障害イベント”は生成されません(トリガーの状態は障害を維持)

仮に、短時間に100件エラーログが書き込まれ、その後追加がなくなった場合、「障害イベントを継続して生成する」と
最初に100件に対して、都度障害イベントが発生し、その後はnodataのパラメータの範囲で30秒ごとに1件障害イベントが発生します。
(時間内に何件ヒストリがあっても、対象は最後のヒストリのみで、トリガーは30秒に1回しか動かないので、イベントも1件/30s のみです。)

>トリガーは永遠に障害状態になるのは、「障害イベントを継続して生成する」を入れない状態でnodataを使わない場合です。
復旧判定には[~継続して生成~]は関係しませんね。
今回の設定ですと、ヒストリが更新されると必ずiregexp側が正となるので、nodataを使わない場合、トリガーは永遠に障害状態になります。
(3.4なら手動復旧が可能)

最後に、自分だったら、
・同じアラートが連続して出力された場合もひとつの障害として検知　　→エラーログを取りこぼさない
・障害対象のメッセージが出力してから300秒間メッセージがなければ復旧
を実現するのであれば、

障害イベントを継続して生成させ、
・nodata関数で復旧判断させる(余分な通知はごめんなさい)。
・余分な通知は出ない代わりに、トリガーは障害のまま。
の二者択一の判断を仰いで、

それとは別に障害・復旧が対になるようなログがあれば、個別にアイテム・トリガーを設定しますかね。
ログ監視用にホストを分けるというのもありでしょうか。