ログファイルを一種の循環バッファーに変換する

皆さん、ログファイルを循環バッファーとして機能させる* nixソリューションはありますか？たとえば、最大1Gbのデータをログファイルに保存し、制限に達すると古いエントリを破棄するようにします。

まったく可能ですか？ログファイルを何らかの特別なデバイスに変換する必要があることを実現するために、私は信じています...

PS私はその他のログローテーションツールを知っていますが、これは私が必要とするものではありません。ログローテーションには大量のIOが必要で、通常は「ランタイム」ソリューションが必要なときに1日に1回発生します。

Linuxにはカーネルリングバッファーがあります。を使用dmesgして表示できます。

それともここにあなたがやりたいように見えるのLinuxカーネルモジュールです。

emlogとは何ですか？

emlogは、プロセスから最新の（そして最新の）出力に簡単にアクセスできるようにするLinuxカーネルモジュールです。必要なストレージが増大しないことを除いて、ログファイルの "tail -f"と同じように機能します。これは、完全なログファイルを保持するのに十分なメモリまたはディスクスペースがない組み込みシステムで役立ちますが、最新のデバッグメッセージが必要になる場合があります（たとえば、エラーが観察された後）。

emlogカーネルモジュールは、シンプルなキャラクターデバイスドライバーを実装します。ドライバーは、有限の循環バッファーを持つ名前付きパイプのように機能します。バッファのサイズは簡単に設定できます。より多くのデータがバッファに書き込まれると、最も古いデータが破棄されます。emlogデバイスから読み取るプロセスは、最初に既存のバッファーを読み取り、次に「tail -f」を使用してログファイルを監視するのと同様に、書き込まれたとおりに新しいテキストを表示します。（プロセスが新しいデータを待つためにブロックせずにログの現在の内容を取得する必要がある場合、非ブロック読み取りもサポートされます。）

私が考えることができる最も近いものはRRDToolsですが、おそらくあなたが探しているものではないでしょう。別の解決策は、ログファイルを監視することです（たとえば、毎秒またはinotifyを使用したLinuxで）。たとえば、次のようなスクリプトを作成します

while :; do
  if [[ $(stat -c %s $FILE) -gt 10000 ]]; then
    # rotate the log
  fi
  sleep 1
done

inotifyを使用：

while :; do
  if inotifywait [some options] $FILE; then
    # check size and rotate the file
  fi
done

djbのDaemontoolsからマルチログを使用できます。ログ出力をそこにパイプします。はい、ログのローテーションですが、ローテーションは単純です：

ln current $tai64nlocaltimestamp

ほぼすべての最新のLinuxファイルシステムで、これは非常に高速な操作です。必要なログファイルの数とサイズを指定できます。10 x 1024mbファイルを作成すると、1GBのリングバッファーができます。

自動ローテーションのため、マルチログインスタンスごとに1つのソースであることに注意してください。ただし、netcatを使用して簡単なラッパーを作成するか、手動で回避することができます。

FIFOパイプを作成し、そこからデータベースに挿入するスクリプトを使用してFIFOパイプを読み取ることができます。カウンターが1,000に達したら、データベースに挿入されているID番号を再起動します。もちろんサイズでは機能しませんが、例としてそれを使用したので、これは理論的な質問であると仮定しています。

興味深い質問; あなたは通常それをデザインとして見ません。私は、わずかに類似した手法を使用して履歴を記録するプログラムを持っていますが、バイナリ形式を使用しています。「ログファイル」には4つの部分があり、すべてマシンに依存しない形式でレイアウトされています。

1. マジックナンバーと、使用済みリストおよび空きリストのエントリの（最大）数、次の履歴エントリのシーケンス番号、使用済みリストの実際のエントリ数、空きリストの実際のエントリ数を含むヘッダー、およびファイルの長さ（それぞれ4バイト）。
2. 使用されるリスト。各エントリはオフセットと長さ（各エントリの各部分に4バイト）を提供します。
3. フリーリスト。各エントリは使用済みリストエントリに類似しています。
4. メインデータ。ヌルターミネータバイトで終了する連続したバイトセットで構成される各履歴レコード。

新しいレコードが割り当てられると、空きリストにスペースがある場合、そこにエントリが上書きされます（必ずしもすべてを使用するわけではありません。その場合、フラグメントは空きリストに残ります）。空きリストにスペースがない場合、最後に新しいスペースが割り当てられます。古いレコードが回転すると、そのスペースは空きリストに移動し、隣接する空きレコードと合体します。レコードを多数の行に分散できるように、SQLステートメントを処理するように設計されています。このコードは、指定された数のレコードで機能します。ファイル自体のサイズは制限されません（そうすることは難しくありませんが）。

メインコードの履歴コードは、2つのファイルhistory.cとhistory.hにあり、プログラムSQLCMDのソースから入手できます（Microsoftのバージョンではなく、Microsoftの10年以上前に存在していたバージョンです）。国際Informixのユーザーグループのソフトウェアアーカイブ。また、履歴ファイルダンププログラム（histdump.c）と履歴テスター（histt​​est.ec-ESQL / Cであると主張しますが、それ自体が実際にはCコードです;呼び出すサポート関数の1つはInformix ESQL / Cを使用しますライブラリ関数）。Informix ESQL / Cを使用せずに実験したい場合は、私に連絡してください-私のプロファイルを参照してください。設計環境の外でhistt​​estをコンパイルするために、いくつかの些細な変更が必要です。さらに、メイクファイルが必要です。

あなたの質問に対するペールのコメントに同意します。ログのローテーションはそれほど難しくありません。logrotateまたは別のスクリプトを設定して、ログファイルを定期的にチェックすることができます（必要に応じて、1分ごと）。ファイルのサイズが1GBに達したことが検出されると、名前の変更が実行されるだけで、ほとんどI / Oがかかりません。名前の変更中、プロセスはログファイルの書き込みを続けます。その後、ログローテーターはHUPをsyslogデーモンに送信できます（デーモンは syslogを介してログを記録していますか？そうでない場合、適切に記述されている場合はHUP信号をサポートする必要があります）。 。この時点で、元のパスで新しいファイルへの書き込みが開始され、回転したバージョンを削除できます。