インフラ作業支援ラボInfra Support Lab ← ガイド一覧← 戻る
トップ > ガイド > Dockerログ確認・容量対策
実務ガイド｜更新日：2026年10月26日

Dockerのログ確認とローテーション｜docker logs・ログ肥大化対策

Dockerのログが出ない・ログ容量が増え続ける場合に、ログの取得先と保存方式を調べ、ローテーション設定を設計する運用ガイドです。ログ削除前にアプリとdaemonの保持方法を切り分けます。

この記事の目的

docker logsとDocker Engineのログ保存方式の違い、既存コンテナへの設定反映条件を理解します。

最初にやること

docker logsで直近ログを確認し、docker inspectで対象コンテナのログドライバーを調べます。

注意：Dockerが管理するログファイルを稼働中に直接削除・truncateしないでください。web01などのコンテナ名、Composeサービス名・ポートは例です。Docker context・ホスト・保存先を実環境で確認してください。
Docker

Dockerの基本操作ガイド

コンテナの状態確認、起動・停止、接続先の基本操作へ戻ります。

記事を読む →Docker

Dockerコンテナ起動失敗

Exited・Restarting・OOMKilledなどの終了原因を切り分けます。

記事を読む →Docker

Docker Compose設定と安全な反映

対象と原因を絞り、変更前後の確認手順へ進みます。

記事を読む →

1. docker logsでログを見る

docker ps -a # 直近100行と日時 docker logs --tail 100 --timestamps web01 # 過去30分間 docker logs --since 30m web01 # リアルタイム監視（Ctrl+Cで終了） docker logs --follow --tail 30 web01

コンテナ名は実環境へ置き換えます。docker logsは通常stdout/stderrに出たログを扱います。アプリが内部ファイルのみにログを書いている場合、何も表示されないことがあります。

2. ログドライバーを確認

# 対象コンテナのログ設定 docker inspect --format '{{.HostConfig.LogConfig.Type}}' web01 # daemonの既定ドライバー docker info --format '{{.LoggingDriver}}' # Dockerオブジェクトの使用容量 docker system df # データ保存ルートの参照 docker info --format '{{.DockerRootDir}}'
ドライバー特徴注意
json-fileJSON形式のログを保存ローテーション設定が必要な場合がある
localDocker管理の効率的なログ形式既定でローテーション制限あり
noneDocker側で収集しない別のログ経路が必要

ログドライバーによってはdocker logsが使えないか、読み出しキャッシュの制約があります。Docker Root Dirが/var/lib/docker以外の構成もあります。

3. json-fileの保存上限設定例

以下は/etc/docker/daemon.jsonの設定例です。既存設定・構成管理・保持要件と照らしてから変更します。

{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

log-optsでは値を文字列として書きます。daemon設定変更は、基本的に変更後に作成するコンテナに適用され、既存コンテナが自動的に新しいログ設定へ変更されるわけではありません。

注意：Docker daemonの再起動やコンテナ再作成は業務影響があります。保存すべきログ、取得経路、更新手順を決めてから行います。

4. 症状から確認先を選ぶ

症状次の確認
ログが空アプリのstdout/stderr、ログ設定、コンテナの稼働状態を調べる
ログが多い出力量、繰り返す異常、保持期間・ローテーション条件を調べる
ホストの空きがないNo space left on deviceの原因確認
コンテナが再起動を繰り返す起動失敗とRestartingの調査
journalが増えているsystemd journalの容量調査

5. 手動削除を避ける理由

危険：Dockerが管理する*-json.logをrmで消したり手動でtruncateしたりする運用は推奨しません。ログ管理との不整合や証跡喪失のリスクがあります。

ログの保持期間・集中ログ送信先・容量監視と組み合わせ、設定適用後はテストコンテナのログ取得とローテーションを確認します。

関連する確認手順：Volume・永続データの確認。

6. ログの観測結果ごとの次の行動

ログが空、ログが増えすぎる、読み出せないという症状では対処が異なります。アプリがstdout/stderrへ出しているか、Dockerのログドライバーが何かを最初に確認します。

docker context show docker inspect --format '{{json .HostConfig.LogConfig}}' web01 docker info --format '{{.LoggingDriver}}' docker logs --tail 10 --timestamps web01 df -h
# 出力例（想定・実測ではありません） {"Type":"json-file","Config":{"max-size":"10m","max-file":"3"}}
確認した結果次にすること
json-fileで上限未設定必要な保管期間・監査要件を確認し、ローテーション上限と外部保管先を設計する
json-fileで上限設定済み上限値とログ生成量、ホスト空き容量を確認。容量不足が続くなら別の消費源を調べる
local既定のローテーションとアプリのログ取得手段を確認。機械的にjson-fileへ切り替えない
noneやdocker logsが空アプリのstdout/stderr・ログ集約先・driverの読み出し可否を照合する
ホスト容量不足ディスク容量とinodeの調査へ進み、Dockerが管理するログを手動削除しない

7. ログ設定の安全な変更判定

daemon全体の既定値を変える前に、ログ保持要件と既存コンテナの個別設定を調べます。既存コンテナへdaemonの新しい既定ログ設定が自動適用されるわけではありません。daemon.jsonの編集やdaemon再起動を、容量不足への無条件な対処として案内しません。

# 参照のみ：対象の接続先と実効設定を確認 docker context show docker info --format '{{.LoggingDriver}}' docker inspect --format '{{json .HostConfig.LogConfig}}' web01 # ホストの一般的な構成で、既存ファイルがあるときだけ実施 # python3 -m json.tool /etc/docker/daemon.json > /dev/null # 対応するDocker Engineのdaemonホスト上で候補ファイルを検証 # dockerd --validate --config-file /path/to/candidate-daemon.json
結果次の判断
候補JSONが不正・daemon設定が競合反映を中止。候補ファイルと起動オプションの不整合を管理者が修正
候補設定は妥当だが既存コンテナが旧設定正常な可能性。新規コンテナだけに反映される条件を確認し、既存サービス再作成は別変更として計画
ログが取得できない／外部へ送信されないログドライバー・転送先・アプリ出力を確認し、監査ログの欠落がないか検証
daemon設定変更後に起動障害既存設定の管理元へ戻し、daemonログ・接続可否・サービス公開範囲を再確認。復旧操作は管理者承認下で実施

検証用コンテナのローテーション結果だけでは、本番ホストの保持期間やログ転送の正常性までは保証されません。dockerdによる構成検証はdaemonホスト側で実行するもので、リモートDocker CLI経由の検証ではありません。

8. 検証用コンテナで設定反映と保存上限を確かめる

次の操作は検証環境でのみ実行する例です。イメージ取得・コンテナ作成・ログ出力を伴うため、権限・空き容量・ネットワークを確認してください。Docker daemon全体の設定を先に変更する必要はありません。

# 承認された検証環境でのみ新しいコンテナを作成 docker run --name audit-log-rotation-test --log-driver json-file --log-opt max-size=10k --log-opt max-file=2 busybox:1.37 sh -c 'i=0; while [ "$i" -lt 2000 ]; do echo "audit log $i"; i=$((i+1)); done' # 作成した検証コンテナの設定値と出力を参照 docker inspect --format '{{json .HostConfig.LogConfig}}' audit-log-rotation-test docker logs --tail 5 audit-log-rotation-test # 出力した2000行のうち、何行が保持されているか確認（検証専用） docker logs audit-log-rotation-test | wc -l

ローテーションが発生していれば、設定した保存上限のため過去の全2000行は保持されません。ただし、行数だけでバイト単位の上限や他のドライバーの挙動を証明することはできません。コマンドが失敗した場合は標準エラーも確認し、Docker管理下のログファイルを手動削除せず、保管要件に従って検証します。

# 設定表示例（想定・実測ではありません） {"Type":"json-file","Config":{"max-size":"10k","max-file":"2"}}
結果完了条件・対処
inspectに指定値が表示され、docker logsも参照できる検証コンテナへの設定適用は確認。保持制限の有効性と実際のディスク使用量を継続確認
既存サービスは以前の設定のまま正常な仕様上の挙動。業務影響・保存データ・イメージを確認してから再作成計画を立てる
期待ログが取得できない外部ログ集約・アプリ出力先・ドライバー仕様を見直し、変更をいったん止める
上限を設定しても容量が減らない別領域の消費、既存コンテナの古い設定、ログ生成量を確認する
切り戻し：設定管理元の旧ログ設定へ戻しても既存コンテナは自動で変わりません。再作成前のログ・永続データ・停止影響を必ず確認してください。専用テストコンテナの削除は、不要・対象名を確認した後に限ります。

公式・一次資料

関連手順を確認する

参照操作・変更操作・削除操作を区別し、作業前後に対象と正常性を記録します。

関連ガイドへ