バグ報告として挙げてよいのか微妙なところなのですが
以下のような現象が発生しているので報告します。

アクティブチェックを利用した log[] のチェックにおいて
発生する症状です。
特に、以下のような特徴をもつファイルを対象にチェックを
行った場合に、症状が起こりやすいです。
また、DB 側のパフォーマンスが低い場合等にも発生しやすい
です。

・既存のログファイルで、チェック開始時点で既に
　ファイルサイズが大きいもの
・一定時間内でのログ出力量が非常に多いもの

＜症状＞
簡潔に症状だけを記載します

・history_log テーブルに同一内容の行データが
　複数登録されてしまい、DB が不必要に巨大化する。
・ログファイルの同一部分を、複数回処理しているので、
　無駄な処理が発生している

何が起こっているのか、何が原因なのか、という
部分を解析しました
長文ですが以下に示します

＜前提＞
１）agent 側では、一定時間おきに対象ログファイルを
　　チェックしている
　　server への送信処理が正常完了した行の先頭位置を
　　示すファイルポインタ値をメモリ上に保持している

　　チェックのタイミングでは、ファイルポインタが
　　示す位置から読み進めて、送信対象のデータが
　　100 行分溜まるか、もしくは、ログファイルの末尾に
　　到達したら、送信対象のデータを server 側へ
　　まとめて送信している

　　server 側から「正常受信完了」の応答があると、
　　ファイルポインタの値を更新して、次のチェック
　　処理に備える

２）server 側では、agent 側からログ情報を受信すると、
　　１行毎に対して以下の処理を行う
　　　・アイテム(items)への最新行データ・更新時刻登録
　　　・ヒストリ(history_log)への最新行データ登録
　　　・トリガー条件(triggers/functions)のチェック
　　　・イベントの生成(events)

　　受信した全ての行について、全処理が完了したら、
　　agent 側へ「正常受信完了」の応答を返して、
　　処理完了となる

＜処理の流れ＞
agent 側から server 側へ大量のログ情報(100行分)が一括
して送信され、server 側がそれを処理するのに多くの時間を
必要とする。
その間、agent 側が「完了待ち」しているのだが、時間内に
server 側が応答を返すことができず、タイムアウトとなる。

server 側で行われている各行データに対する処理は、
100 行分をまとめて受信した場合であっても、１行分ずつ
評価・登録されている
　　　（到着データの少なくとも一部は DB に登録完了
　　　　している状態になっている）

送信がタイムアウトとなった場合、agent 側は、メモリ上に
保持しているファイルポインタ値が更新されない
よって、次のチェックタイミングになった時点では、ログ上の
同じ部分がチェックされてしまう
その結果として、前回のチェックと全く同一部分をチェック
した結果の行データが、server 側へ再度送信される

server 側では、同じ部分をチェックした行データであっても
それを知る術はなく、それぞれの受信データでは、
「チェック実施時刻」が異なっているために、
毎回、新しいデータとして history_log に登録してしまう