Zimbraの監査ログをクリアしてディスク容量を安全に解放する方法

まず、実際に何を取り除く必要があるのかを決めることから始めましょう。

ディスク容量が不足しているZimbraサーバーでは、ログのクリーンアップが急務に感じられるかもしれませんが、ログは/opt/zimbra/log/audit.log単なる使い捨ての診断出力ではありません。Zimbraは認証イベントや管理アクティビティの監査証跡としてログを記録します。つまり、最適なクリーンアップ方法は、すぐに必要な容量、履歴証拠、または長期的な保存対策のいずれが必要かによって異なります。

最も安全なデフォルト設定は、アクティブaudit.logファイルをそのままにして、ローテーションされた古いコピーを優先的に処理することです。社内保持ポリシー、法的保留、またはコンプライアンス要件の対象となる場合は、ファイルを削除する前に、それらのファイルを別のファイルシステムにアーカイブしてください。アクティブファイル自体が異常に大きくなった場合は、クリアすることもできますが、これは緊急措置として扱うべきです。なぜなら、クリアすると現在の監査履歴が削除され、コピー中にサーバーが書き込みを続けると、わずかな競合状態が発生する可能性があるからです。

Zimbraの公式ログドキュメントでは、audit.logの下にを配置し、や/opt/zimbra/logなどのファイルのローテーションを担当するコンポーネントとしてLog4jについて説明しています。他のZimbraログでは、代わりにオペレーティングシステムの構成が使用される場合があるため、ディレクトリ内のすべてのファイルが同じメカニズムに従うとは限りません。公式のZimbraログファイルリファレンスとZimbraログローテーションノートを参照してください。audit.logmailbox.loglogrotate

行動を起こす前に、清掃方法を比較検討してください。

アプローチ	ディスク容量が回復しました	監査履歴は保持されます	オペレーショナルリスク	最適なフィット
古いローテーション済み監査ログを削除する	多くの世代が存在する場合、高くなる	いいえ、事前にバックアップを取っておかない限りは。	ファイル名を最初に確認すれば低くなります	ほとんどの日常的な清掃作業
古い回転ログを圧縮する	中程度から高程度	はい	低	地域史を必要とするシステム
古いログを別の保管場所に移動	Zimbraファイルシステムの上位	はい	低～中程度	コンプライアンスまたは長期保存
アクティブな audit.log を切り詰める	即時、潜在的に大きな	最初にコピーされない限りはダメです	より高い	緊急時のスペース復旧のみ
剪定または保持の動作を変更する	再発を防ぎます	ポリシーによります	設定ミスがあった場合は修正してください	繰り返される成長の問題

ステップ1：何かを削除する前に問題を測定する

まず、監査ログが実際に負荷の原因であることを確認してください。以下のコマンドを実行してくださいroot。

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*

最初のコマンドは、ファイルシステムの使用状況を表示します/opt。2番目のコマンドは、Zimbraログ全体のフットプリントを表示します。3番目のコマンドは、アクティブな監査ファイルとローテーションされた世代を表示します。監査ファイルがファイルシステムのごく一部を占めているだけであれば、それらを削除しても根本的な問題は解決しない可能性があります。メールボックスストア、バックアップ、データベースファイル、または別のログファミリーが代わりに領域を消費している可能性があるためです。

動作を変更する前に、インストールされているバージョンを記録しておいてください。

su - zimbra -c 'zmcontrol -v'

これは重要な点です。なぜなら、Zimbraのドキュメントは複数の製品世代にまたがっており、Log4jの構文、生成される設定、およびプルーニングジョブは異なる場合があるからです。古いWikiの例から保持値をコピーして、それが現在のデフォルト値であると決めつけないでください。

クリーンアップ前にZimbraログとaudit.logのディスク使用量を測定するために使用されたdf、du、lsコマンドを表示するターミナル画面

削除対象を決定する前に、ファイルシステムの使用状況、Zimbraログの総サイズ、および個々の監査ログの生成状況を確認してください。

ステップ2：このサーバーがどのようにログをローテーションおよび削除しているかを確認します。

Zimbra では、関連する 2 つのメカニズムについて説明しています。1 つは、ファイル ( ) を含むファイル用の Log4j audit.log、もう 1 つは他のいくつかの Zimbra ログ用のオペレーティングシステムの機能logrotateです。また、Zimbra 独自の crontab にログメンテナンスタスクが含まれている場合があることも記載されています。推測するのではなく、ライブ構成を確認してください。

su - zimbra
crontab -l
exit

grep -n "audit.log" /opt/zimbra/conf/log4j.properties
grep -n "audit.log" /opt/zimbra/conf/log4j.properties.in

これらのファイルのいずれかに、ご使用のリリースで想定される設定が含まれていない場合は、古い例を無理やり適用するのではなく、周辺のログ設定を確認してください。生成されたファイルは、サービスの再起動後や設定の再生成後に上書きされる場合もあります。Zimbraのログに関する注記では、生成されたプロパティファイルへの一時的な編集と、対応する.inテンプレートで行われた永続的な変更を明確に区別しています。

監査ログの量が予想以上に多いサーバーについては、追加のログ記録が意図的に有効になっていないか確認してください。Zimbra 10.0.6 リリースノートには、zimbra_additional_loggingローカル構成属性に関する説明があり、これを使用すると、認証失敗イベントやその他の有用な認証イベントをログに追加できますaudit.log。容量を節約するためだけに、有用なセキュリティログを無効にしないでください。ログの量が正当な場合は、通常、保持、圧縮、または集中ログストレージの方が適切な解決策です。Zimbra 10.0.6 の公式リリースノートを参照してください。

Zimbra Log4j設定ファイル内のzimbraユーザーのcrontabとaudit.log参照の確認画面を表示するターミナル

保持期間やローテーションの動作を変更する前に、サーバーの実際のcrontabとLog4jの設定を確認してください。

ステップ3：ローテーションされたログを優先的にアーカイブまたは削除する

ほとんどの管理者にとって、古いローテーション済み監査ログは最初に確認すべき対象です。find削除する前に、レポート専用モードで使用してください。以下の例は、30日以上前のローテーション済み監査ログの一覧です。30日はあくまでも目安であり、Zimbraが規定する保持期間ではありません。

find /opt/zimbra/log -maxdepth 1 -type f -name 'audit.log.*' -mtime +30 -print

それらのファイルが不要になった場合は、レビュー済みのローテーション済みファイルのみを削除してください。それらを保持する必要がある場合は、まず別のファイルシステムにコピーまたはアーカイブしてください。Zimbraパーティションがほぼ満杯の場合は、別のマウントを使用することが重要です。同じ満杯のファイルシステム上に圧縮アーカイブを作成すると、一時的にさらに多くの容量を消費する可能性があるためです。

mkdir -p /mnt/backup/zimbra-audit-logs
cp --preserve=mode,ownership,timestamps   /opt/zimbra/log/audit.log.OLD_GENERATION   /mnt/backup/zimbra-audit-logs/

確認したファイル名に対して、この手順を繰り返してください。ソースを削除する前にバックアップを確認してください。のような広範囲なパターンは避けてください。rm -f /opt/zimbra/log/audit.log*このパターンはアクティブなファイルにも一致します。

古いログをローカルに保持しつつ、ファイルサイズを削減したい場合は、ローテーションされたファイルのみを圧縮してください。

gzip /opt/zimbra/log/audit.log.OLD_GENERATION

圧縮が有効かどうかは、現在のログローテーション設定によって異なります。一部のデプロイメントでは、メンテナンスの一環として既に過去のログが圧縮されている場合があります。新たなレイヤーを追加する前に、実際にどのような圧縮が行われているのかを確認してください。

Zimbraの履歴ログに関するガイダンスでは、監査ログには機密データが含まれる可能性があると警告しています。アーカイブは、ライブログと同じアクセス制御で扱ってください。Zimbraの公式ログガイダンスを参照してください。

古いローテーションされた Zimbra 監査ログと、削除前に使用されていた別のバックアップディレクトリを一覧表示する find コマンドを表示するターミナル

まず古いローテーション済みファイルを一覧表示し、必要な履歴を別のストレージにコピーしてから、レビュー済みの世代を削除します。

アクティブな audit.log を切り詰めることが正当化される場合

ローテーションされたファイルが問題ではなく、アクティブなファイルaudit.log自体が重要な領域を消費している場合は、切り捨てによってすぐに領域を解放できます。ただし、切り捨ては最も明確なトレードオフを伴うオプションでもあります。つまり、ファイルが切り捨てられると、現在の監査履歴は削除されます。

より安全な緊急時の手順としては、mailboxdを一時的に停止し、アクティブなファイルを別のファイルシステムにコピーし、元のファイルをその場で切り詰めて所有権とアクセス許可を保持し、mailboxdを再度起動することです。

su - zimbra -c 'zmmailboxdctl stop'

cp --preserve=all /opt/zimbra/log/audit.log   /mnt/backup/audit.log.$(date +%Y%m%d-%H%M%S)

truncate -s 0 /opt/zimbra/log/audit.log

su - zimbra -c 'zmmailboxdctl start'

この方法はメールボックスサービスのダウンタイムを引き起こすため、すべての環境に適しているわけではありません。mailboxdを停止せずにライブファイルをコピーするとダウンタイムは回避できますが、コピー後かつ切り捨て前に書き込まれたエントリが失われる可能性がある競合状態が発生します。ディスク負荷がそれほど高くない場合は、ローテーションされたファイルをクリーンアップし、保持期間を修正する方が望ましいです。

アクティブログを最初の対応手段として使用しないでくださいrm。ディレクトリエントリが削除された後でも、プロセスは開いているファイルディスクリプタを通して書き込みを続ける可能性があるため、期待されるディスク容量がすぐに解放されない場合があります。緊急のクリアが本当に必要な場合は、既存のinodeを切り詰める方が予測しやすいです。

ステップ4：ディスクの復旧と継続的なログ記録の両方を確認する

クリーンアップ後、エラーがないことを前提とするのではなく、結果を確認してください。

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*
tail -n 20 /opt/zimbra/log/audit.log
su - zimbra -c 'zmcontrol status'

良好な結果には、次の3つの兆候があります。目的のファイルシステムの空き容量が増加しているaudit.logこと、新しいイベントが引き続き発生し、関連するZimbraサービスが引き続き実行されていること。空き容量が急激に減少しているdfにもかかわらず、ファイルシステムが満杯であると報告される場合はdu、さらにデータを削除する前に、実行中のプロセスによってまだ開かれたままになっている削除済みファイルがないか確認してください。

ターミナルには、クリーンアップ後のディスク使用量、最近のZimbra audit.logエントリ、およびZimbraサービスのステータスチェックが表示されます。

クリーンアップ後、回復した容量、最近の監査活動、およびサービスの状態を確認します。

ログが増加した理由に基づいて、長期的な解決策を選択してください。

成長は正常だが、保持期間が長すぎる場合

保持または削除プロセスを調整する際は、必要な履歴期間を文書化してからにしてください。既存のZimbra crontabとLog4jの設定を確認し、バージョンに応じた最小限の変更のみを行ってください。元の設定のコピーを保持し、次回のローテーションで期待どおりのファイルが作成されることをテストしてください。

認証ノイズが音量を上げている場合

単に削除するよりも、原因を調査する方が迅速です。ログイン試行の繰り返し、クライアントの設定ミス、監視プローブ、または意図的に拡張された認証ログなどは、すべて監査ログの量を増加させる可能性があります。監査ログはaudit.logセキュリティ調査に役立つため、証拠を隠蔽するよりも、根本的なノイズを減らす方が通常は良いでしょう。

監査履歴を数か月分保持する必要がある場合

ログを保持用に設計されたストレージに移動または送信します。集中ログ、オブジェクトストレージ、または専用のログファイルシステムにより、コンプライアンス履歴がメールプラットフォームに必要な容量から分離されます。Zimbra のログファイルドキュメントでは、集中ログの候補について明示的に説明していますaudit.log。

やってはいけないこと

未確認のワイルドカードを使用して削除しないでくださいaudit.log*。
リリースごとにアクティブな監査ログを制御すると想定しないでください/etc/logrotate.d/zimbra。Zimbra は Log4j をローテーションメカニズムとして文書化していますaudit.log。
十分な一時領域があることを確認しない限り、ほぼ満杯状態のファイルシステムに圧縮またはアーカイブしないでください。
組織的、法的、またはセキュリティ上の要件を確認せずに、データ保持期間を短縮しないでください。
ZimbraがテンプレートからLog4jファイルを再生成するかどうかを理解せずに、生成されたLog4jファイルを永続的に編集しないでください。

最終確認

古いローテーション済みログが主な消費要因である場合、望ましい結果は単純です。アクティブな監査ログはそのまま維持され、履歴ファイルはポリシーに従ってアーカイブまたは削除され、ファイルシステムは正常に動作するのに十分な空き容量を確保します。すぐに再び空き容量が減り始めた場合は、クリーンアップを解決策とみなすのをやめ、書き込みレート、認証アクティビティ、ローテーション構成、およびその他のログ設定を調査してください。一度限りのクリーンアップか、繰り返し発生する増加かというこの違いこそが、実際に問題が解決したかどうかを判断する基準となります。