web-dev-qa-db-ja.com

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

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

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

logsmonitoringtail
9
Manoj N V

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

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

これは、追跡されたファイルのサイズがとにかく重要ではないことを意味します。

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

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

6
Stéphane Gimenez

（パイプではなく）通常のファイルで呼び出された場合、GNUテールとOpenBSDテール（-n +Nで呼び出されない限り）の両方がファイルの最後をシークしてから機能しますSolarisが同じことをするかどうかはわかりませんが、それは合理的なアプローチなので、ほとんどのユニスが同じことをすることを期待しています。したがって、ファイルのサイズはパフォーマンスとは無関係です。

5
Gilles 'SO- stop being evil'

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

Grepに送信する代わりに、execのscreen機能を使用します。これは、通常、すべての出力を表示するためです（完全なトレースバックと問題に関連するメッセージの場合）。例えば、

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

ワード例外が検出されるたびに端末からビープ音（またはフラッシュ）を鳴らすため。

2
Arcege