web-dev-qa-db-ja.com

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

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

デフォルトのrsyslogでは、logrotate /etc/logrotate.d/rsyslog config以下が表示されます。

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

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

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

rsysloglogrotate
16
Mattan

あなたの質問に答えるには、最初にreloadとcopytruncateの異なるトレードオフを理解する必要があります：

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

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

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

「reopenOnTruncate」について：私は個人的に、reopenOnTruncateが他の点でも、特にNFSなどで際どいものであることを確認しました。少し前にその機能を完全に削除しましたが、後で同様の機能をマージすることに納得しました。非常に負荷の高いシステムで人々が問題に遭遇することを知っているので、おそらく永久に「実験的」にとどまります。 「copytruncate」は、ログファイルを操作するための適切なモードではありません。

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

17
Rainer Gerhards

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

2
faker

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

1
Selivanov Pavel

具体的には、rsyslogの場合は、そのままにしておく方が理にかなっています。

基本的な理由は、rsyslogには出力キューが使用できなくなった場合に使用できる内部キューがあるためです。

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

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

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

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

したがって、reloadアプローチを使用することで、デフォルト構成からの偏差が少なくて済む場合にのみ、私はそれを維持します。

0
iwaseatenbyagrue