logrotateを使用したrsyslog：rsyslogとcopytruncateのリロード

デフォルトのrsyslogおよびlogrotateユーティリティを使用して、Ubuntu 14で作業しています。

デフォルトのrsyslog logrotate構成で/etc/logrotate.d/rsyslogは、次のように表示されます。

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

私が理解していることから、現在のログを移動するのではなく、すべてのログローテーションシナリオでcopytruncateを使用することをお勧めしますが、開いているファイルハンドラーを持つプロセスが書き込みを続けることができるようにログを切り捨てます。

では、代わりにrsyslogのリロード機能を使用したデフォルトの構成はどうしてですか？

質問に答えるには、最初にリロードとコピートランケートの異なるトレードオフを理解する必要があります。

• reload：古いログファイルの名前が変更され、そのログに書き込むプロセスに（Unixシグナルを介して）通知されて、ログファイルが再作成されます。これは、最速でオーバーヘッドの少ない方法です。名前変更/移動操作は非常に高速で、実行時間が一定です。さらに、これはほとんどアトミックな操作です。つまり、移動/リロード中に（ほとんど）ログエントリが失われることはありません。一方、ログファイルをリロードして再度開くことができるプロセスが必要です。Rsyslogはそのようなプロセスであるため、デフォルトのlogrotate構成はリロードメソッドを使用します。rsyslogアップストリームでは、このモードをrsyslogで使用することを強くお勧めします。
• copytruncate：古いログファイルはアーカイブファイルにコピーされ、古いログ行を「削除」するために切り捨てられます。切り捨て操作は非常に高速ですが、コピーは非常に長くなる場合があります（ログファイルの大きさによって異なります）。さらに、コピー操作（低速である可能性がある）と切り捨ての間にログエントリが失われる可能性があります。これらの理由により、copytruncateは、ログファイルの再読み込みと再作成が可能なサービスにはデフォルトでは使用されません。一方、サーバーがログファイルをリロード/再作成できない場合、copytruncateが最も安全な方法です。つまり、サービスレベルのサポートは必要ありません。rsyslogアップストリームプロジェクトは、このモードの使用を強くお勧めします。

rsyslogの著者として言えば、copytruncateは実際には非常に、非常に悪い選択です。それは本質的に際どいものであり、それを使用すると、ログデータが失われることがほぼ保証されます。ファイルが頻繁に書き込まれるほど、失われます。そして、これは最後の行の一部ではなく、ローテーションが発生したときのシステムの正確なタイミングと状態に応じて、数百行になることがあります。

ファイルが移動され、新しいiノード（ファイル）が作成されると、rsyslogは以前のファイルを追跡し、処理を完了します。この場合、損失はありません。保証されます（ファイルシステムをアンマウントする場合を除く...）。

「reopenOnTruncate」について：個人的にはreopenOnTruncateが他の点でも、特にNFSなどで際立っていることを見てきました。しばらく前に、私はその機能を完全に削除しましたが、後で同様の機能をマージするよう説得しました。非常に負荷の高いシステムで問題が発生することを知っているので、おそらく「実験」のままです。「copytruncate」は、ログファイルを処理するための単なるまともなモードではありません。

現在、imfile（ETA 8.34または8.35）のリファクタリングに取り組んでいます。リファクタリングされたバージョンは、おそらくAPIの競合による偶発的な再送信を防ぐことができますが、データ損失を防ぐことはできません-これは概念的に不可能です。

これは、プロセスがログを書き込む方法に完全に依存します。
copytruncateログメッセージは、例えば（ファイルに追加された場合にのみ、動作しますwhatever >> logfile。
それは例えば（出力をリダイレクトしているときといませんwhatever > logfile）。

バージョン8.16以降、rsyslogにはreopenOnTruncatecopytruncteの問題を処理するimfile オプションがあります。

具体的には、rsyslogについては、物事をそのままにしておくほうがおそらく理にかなっています。

基本的な理由は、rsyslogの出力ハンドルが使用できなくなった場合に使用できる内部キューがあることです。

リロードにより、a）rsyslogが独自のログファイルを再作成し、b）キューに入れられたイベントが作成時にファイルにフラッシュされます。

copytruncateは害を及ぼさないかもしれませんが（部分的に書き込まれた行が切り捨てられることを心配しますが）、コピー/削除/リロードは整合性の観点から「安全」だと思う傾向があります。

@ fakerで述べたように、rsyslogはファイルが使用できなくなった状況を処理できるため、copytruncateを使用する説得力のある理由はありません。

そして、@ SelivanovPavelが言及したように、rsyslogは実際にコピーの切り捨てを適切に処理するために特定の設定を必要とします。

そのため、このreloadアプローチを使用するためにデフォルト構成からの偏差が少ないために、それを維持します。