ホームサーバーではDockerのログ用にどれくらいの容量を確保すべきですか？

Dockerログ用に上限のないプールを1つ確保しないでください。コンテナごとにローテーションを設定し、ホストの空き容量下限を別に維持します。実用的な開始点は通常のコンテナで30-100MBとし、トラブルシューティングに必要な期間が長いサービスにのみ、より大きな上限を設定します。

必要な総容量は、コンテナごとの上限にコンテナ数を掛けた値に加え、デーモン、journald、アプリケーション、クラッシュ、テンポラリログの容量を足したものです。適切な予約容量には、ログ急増時にもイメージの取得、更新、コンテナの再起動を動作させ続けられる余裕も必要です。この違いによって、測定方法、安全マージン、停止条件が決まります。この違いによって、測定方法、安全マージン、停止条件が決まります。

各ログ生成元から予算を組み立てる

Dockerのロギングドライバー、コンテナ数、ログレート、保持期間、ボリューム内に書き込まれるアプリケーションログを一覧化します。標準出力のローテーションでは、アプリケーションが別途作成するログファイルは制限されません。

`json-file`では、`max-size=10m`と`max-file=3`により、保持されるファイルはコンテナごとに約30MBに制限されます。`local`ドライバーは圧縮と上限付きローテーションを追加しますが、変更したデフォルト設定を適用するには、既存のコンテナを再作成する必要がある場合があります。

イメージ、書き込み可能レイヤー、パッケージ更新、緊急診断用に、システムディスクの空き容量を追加で確保します。ログ予算によって`/var/lib/docker`の最後の使用可能な容量まで消費しないでください。

サイズだけでなく、レートと空き容量を監視する

コンテナごとのバイト数、1時間あたりの増加量、ローテーションイベント、ファイルシステムの空きバイト数、inode使用量を追跡します。突然のレート変化は、ディスクが満杯になる前にクラッシュループを示すことがよくあります。

再起動や更新の処理に必要な余裕を残せるよう、警告とクリティカルのしきい値を早めに設定します。小容量のシステムディスクでは、割合だけでなく、5-10GBの固定運用予備容量の方が意味を持つ場合があります。

以下の表を使って、観測した動作を上限値に反映します。

重要な証拠を失わずにローテーションを適用する

デーモンのデフォルト設定と、重要度の高いサービス向けの明示的な例外を設定し、設定を反映するためにコンテナを再作成または再デプロイします。コンテナのインスペクションで、アクティブなドライバーとオプションを確認します。

セキュリティログや監査ログをローカルのローテーション後も保持する必要がある場合は、別の永続的な保存先に転送します。通常のデバッグ出力をシステムディスクに無期限で保持しないでください。

ZimaSpaceのDockerディスク増加のワークフローでは、ログをレイヤーやボリュームから分離します。

RunBook Academyのログローテーション分析では、`max-size`と`max-file`によって予測可能な上限を作成する方法を説明しています。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ログの多いコンテナを強制的に検証する

テストコンテナで制御されたログ出力を生成し、ファイルがローテーションされる様子を確認します。設定したファイル数に達したときに古いファイルが削除され、コンテナが動作し続けることを確認します。

Dockerとホストを再起動してから、確認を繰り返します。運用予備容量が消費される前にアラートが発報されること、またドライバーの外部にあるアプリケーションログにも別途上限が設定されていることを確認します。

最悪時の合計ログ容量が予算内に収まり、再起動後もローテーションが機能する場合に進めます。いずれかのコンテナが無制限に増加する場合、ローテーションが有効でない場合、または空き容量がシステムの予備容量を下回る場合は、停止して設定を修正します。