こういうことですよね？

23:58:40 処理Aの続きのログ → app.log.20170323 に追記
23:59:20 アイテムの値取得・・・app.log.20170323 の続きを読む
00:00:00 app.log.20170324 が作成される
00:00:15 処理Bの最初のログ → app.log.20170324 に書き込む
00:00:20 アイテムの値取得・・・app.log.20170324 を最初から読む
00:00:40 処理Aの続きのログ → app.log.20170323 に追記
00:01:20 アイテムの値取得・・・app.log.20170323 を最初から読んでしまう
00:01:25 処理Bの続きのログ → app.log.20170324 に追記
00:02:20 アイテムの値取得・・・app.log.20170324 を最初から読んでしまう

それで、00:20:00 には app.log.20170323 は app.log.20170323.gz になるのでログ監視の対象にはならなくなると。

この場合、ローテーション後にまた処理Aのログが出たらどうなるんですか？
また app.log.20170323 が作られてそれが監視対象になる？

思いつきですが、これでどうにかなりませんかね（試してはいません）。
・app.log.latest というファイルを作り、これを logrt ではなく log を使って監視する。
　このファイルは最新（※）のファイルのハードリンク。
・手動で app.log.20170323 のハードリンクとして app.log.latest を作る。
・00:20 に app.log.20170323 を圧縮するとき、ついでに app.log.latest を削除して、
　それから改めて app.log.20170324 のハードリンクとして app.log.latest を作る。

この場合、00:20 までは処理Bのログは検知できないので（00:20 の次のログ取得時にまとめて出ることになるのかな）、それが許容できるかどうか。

※自分で「これを最新ということにする」と決めるのです。
例えば、上の例と違って「00:00 を過ぎたら app.log.20170323 はもう見ないぞ」と決めるなら、00:00 の時点で app.log.latest を app.log.20170324 のハードリンクにするのです（00:20 はこれまで通りの圧縮だけ）。