2

リモート UNIX ホストで急速に成長するログファイルを読み取る方法を探しています。
ログファイルはときどきログスイッチを取得します (たとえば、再び 0 バイトから始まります)。ログファイルをリモート ホストで直接処理できない理由は、プロセッサがホストに過度の負荷をかけているためです。これは発生してはなりません。そのため、2 つの異なるホストで処理と読み取りを行う必要があります。

私は Java の世界にいるわけではないので、これを実現する最善の方法についてアドバイスを求めたいと思います。

これまでの私の考え:
ローカル ログ ファイル プロセッサ (localhost) にリモート ホストへの logfilereader (java バイナリ) を scp させ、それを (ローカル ログ ファイル プロセッサによって開始された ssh 接続を介して) 開始します。次に、logfilereader はログファイルの読み取り/追跡を開始し、それを TCP ストリームとして提供します (その後、ローカル ログファイル プロセッサで読み取ることができます)。

もっとエレガントな javastyle アプローチがあると確信しています。ヒントをありがとう。

4

2 に答える 2

9

リモートホストでsshを実行できる場合は、使用できます

ssh <remote host> "tail -f <remote log file name>" > <local log file name>

これにより、リモート ログ ファイル名に書き込まれたものはすべてローカル ファイル名にリダイレクトされます。リモート ファイルが消去されると、リモート ファイルが切り捨てられたことを示すメッセージが表示されます。

于 2012-10-16T09:52:22.320 に答える
1

ログ ファイルをオンラインで読む必要がある場合 (つまり、メッセージが届いたときに)、メッセージをファイルに書き込む代わりに (またはそれに加えて) TCP 経由でメッセージを提供する方法を検討することをお勧めします。

リモート アプリがロギング フレームワークを使用している場合、これは通常、構成のほんの数行です。

これにより、データをディスクに書き込む必要がなくなるため、リモート ホストの負荷も軽減されます。しかし、これは通常、リモート プロセスがディスクに頻繁にアクセスして作業を行う場合にのみ問題になります。リモート プロセスがデータベースと頻繁にやり取りする場合、ログ メッセージがネットワーク リソースの DB クエリと競合するため、逆効果になる可能性があります。

良い面としては、これにより、各ログ メッセージを最大 1 回処理することが容易になります (ローカル リスナーを再起動すると、一部が失われる可能性があります)。

それが不可能な場合は、tail -f <logfile>経由して実行してくださいssh（Vicentが他の回答で提案したように）。を使用したくない場合は、Java 用の SSH ライブラリについてこの質問を参照してくださいProcessBuilder。

ファイルを読むときの難しい作業は、各ログ メッセージを 1 回だけ処理することです (つまり、ログ メッセージを見逃さず、2 回処理しないようにします)。ログ ローテーションの仕組みと、リモート プロセスがログ ファイルを作成する方法によっては、切り替え時にいくつかのメッセージが失われる可能性があります。

オンライン処理が必要ない場合 (つまり、昨日のメッセージを見るだけで十分な場合) はrsync、リモート フォルダをコピーしてみてください。rsync重複転送を回避するのに非常に優れており、ssh. これにより、処理可能なすべてのログ ファイルのローカル コピーが作成されます。もちろん、rsyncアクティブなログ ファイルを処理するにはコストがかかりすぎるため、このファイルを調べることはできません (したがって、これはオンライン処理が必要ない場合にのみ可能であるという制限があります)。

最後のヒント: 役に立たないログ メッセージを送信しないようにしてください。ログ ファイルを転送する前に、非常に単純なスクリプトを使用してログ ファイルをフィルタリングすることで、多くの場合、負荷を何度も減らすことができます。

于 2012-10-16T13:44:11.473 に答える