大きなログファイルでtail -fを使用しても問題ありませんか

大きなログファイル（1 GBに近い）でエラーを監視したいと思います。これをリアルタイムに近づけたい（数秒の遅延で十分）。私の計画はを使用することtail -f | grepです。0バイトから1 GBなど、長時間にわたって実行する場合に、このような方法を使用するとパフォーマンスの問題がありますか？そのようなモニタリングに使用される標準的な慣行はありますか？Solaris 10で使用可能な標準のUNIXコマンドを使用してこれを実行したいことに注意してください。

それが可能であれば、ファイルがロールオーバーしてしまい、整理するのにもう1つの問題があります:)。tail -F（--follow=name）を使用すること-Fは、私がこれを実行したいサーバーでサポートされていないため、私にとってはオプションではありません。私の計画は、この末尾を開始し、ファイルがロールオーバーされているかどうかをポーリングするスクリプトを使用することです。はいの場合、テールをキルして再起動します。より良いアプローチはありますか？

私のLinuxシステム（GNU coreutils 8.12）では、システムコールを使用してほとんどのファイルをすばやくスキップできることを（を使用してstrace）確認できました。tail -flseek

lseek(3, 0, SEEK_CUR)                   = 0
lseek(3, 0, SEEK_END)                   = 194086
lseek(3, 188416, SEEK_SET)              = 188416

これは、追跡されるファイルのサイズがいずれにしても問題にならないことを意味します。

システムに同じことが当てはまるかどうかを確認できます。（明らかに、そうであるはずです。）

—
^{1.念のため、文書化されていない---disable-inotifyでinotifyサポートを無効にしてみました。}

（パイプではなく）通常のファイルで呼び出された場合、GNUテールとOpenBSDテールの両方（で呼び出されない限り-n +N）はファイルの終わりまでシークし、逆方向に動作して、印刷を開始する行を見つけます。Solarisが同じことをするかどうかはわかりませんが、それは合理的なアプローチなので、ほとんどのunicesが同じことをすることを期待しています。したがって、ファイルのサイズはパフォーマンスには関係ありません。

私は毎日これをします。私は通常、テストサーバーと本番サーバーの数十個のログをを使用してスキャンしますtail -f logs/*.{log,err,out}。初期ロードは少し（グロブされるファイルの数によって異なります）ですが、その後、ストリーミングはリアルタイムになります。

grepに送信する代わりに、すべての出力を確認したいので（問題に関連する完全なトレースバックとメッセージのために）exec機能を使用しますscreen。例えば、

!:sed -n s/.*Exception.*/\007/p

例外という単語が見つかったときに、ターミナルでビープ音（またはフラッシュ）を発生させます。