Dockerのログでディスクを埋めない：json-fileとjournaldの上限
Dockerの既定のログドライバー（json-file）は、上限を書かないとコンテナの標準出力をすべてファイルに残し続ける。Docker公式のJSON File logging driverのページではmax-sizeの既定値が-1（無制限）で、Configure logging driversのページには「By default, no log-rotation is performed.」とある。n8nや外部APIを呼ぶ処理を何か月も動かすと、このファイルがディスクを埋めることがある。
上限は/etc/docker/daemon.jsonか、Composeのloggingで付ける。ただし、どちらも設定した後に作ったコンテナにしか効かない。設定を書いて満足せず、コンテナを作り直し、docker inspectで値が入ったかまで見る必要がある。
2026年10月19日に、Docker 25.0.16のホストでコンテナを動かし、上限の有無でログがどう残るかと、restartとup -dで設定が変わるかを確かめた。あわせて、Docker Hubのubuntu:24.04にsystemd（255.4-1ubuntu8.18）を入れ、journaldの設定ファイルを読んだ。
- 今の設定を見るdocker inspect の LogConfig に max-size が無ければ、そのコンテナのログは増え続ける
- 上限を書くdaemon.json の log-opts か、compose.yaml の logging に max-size と max-file を書く
- コンテナを作り直すdocker compose up -d --force-recreate。restart では設定が変わらない
確かめた環境と方法
- Docker Engine 25.0.16、Docker Compose v5.6.0。テストのコンテナは
ubuntu:24.04で、echoで3,000行（1行あたり約40字。json-fileは1行ごとに時刻などを付けたJSONで保存するので、ファイル上は1行100バイト前後になる）を出力させた - このホストのDockerには、既に既定の上限（
max-size: 20m、max-file: 3）が設定されていた。上限を何も書いていないDockerの値は、下の表のとおり公式ドキュメントのものを載せている - journaldは、
ubuntu:24.04へaptで入れたsystemdの/etc/systemd/journald.confと/usr/lib/systemd/journald.conf.d/を読んだ。実際のVPSでログが上限まで増えるところは試していない
VPS事業者のOSイメージやDocker入りのテンプレートで、daemon.jsonがどうなっているかは確かめていない。下の手順で、自分のVPSの値を先に見てほしい。
何も書かないときの上限
| 置き場所 | 既定の上限 | 出典 |
|---|---|---|
Dockerのjson-file（既定のドライバー） |
max-sizeは-1（無制限）、max-fileは1、圧縮なし |
Docker公式 JSON File logging driver |
Dockerのlocalドライバー |
max-sizeは20m、max-fileは5、圧縮あり |
Docker公式 Local file logging driver |
| journald（systemd 255） | SystemMaxUseはファイルシステムの10%で、4Gを超えない。SystemKeepFreeは15%で、同じく4Gまで |
journald.conf（systemd 255） |
localドライバーは既定で上限が付くが、ファイルはDocker専用の形式で、公式ドキュメントは他のツールで読まないよう書いている。ログ収集の仕組み（Fluent Bit・Vectorなど）がjson-fileのファイルを直接読んでいるなら、ドライバーは替えずにjson-fileのまま上限を付ける方が影響が小さい。
今のコンテナに上限があるかを見る
まず既定のドライバーを見る。
docker info --format '{{.LoggingDriver}}'次に、動いているコンテナごとの設定を見る。
docker inspect -f '{{.Name}} {{json .HostConfig.LogConfig}}' $(docker ps -q)検証のホストでは、オプションを付けずに作ったコンテナは{"Type":"json-file","Config":{"max-file":"3","max-size":"20m"}}と表示された。Dockerデーモン側の既定（daemon.jsonなど）が、コンテナを作った時点でConfigに写されていた。Configが{}でTypeがjson-fileなら、上限が無い。ログファイルの場所はdocker inspect -f '{{.LogPath}}' <コンテナ名>で分かり、sudo du -hでその大きさを見られる。
上限を付けたときに残る量
同じ3,000行を出すコンテナを、条件を変えて動かした結果は次のとおりだった。
| コンテナの作り方 | docker logsで見えた行数 |
最初に見えた行 |
|---|---|---|
オプションなし（ホストの既定 20m×3） |
3,000行 | 0行目 |
--log-opt max-size=10k --log-opt max-file=2 |
108行 | 2,892行目 |
--log-driver local（既定 20m×5） |
3,000行 | 0行目 |
max-size=10kのコンテナでは、古い行が消え、最後の108行だけが残った。上限を付けると、障害の後にdocker logsで遡れる範囲も短くなる。何日分を残したいかは、1日に出る量（docker inspect -f '{{.LogPath}}'で分かるファイルを、1日あけて2回duで測る）から決める。原因を調べるのに必要なログは、docker logsに頼らず、監視の仕組みやアプリ側のファイルに送っておく。
daemon.jsonで全体の既定を変える
/etc/docker/daemon.jsonに次のように書く（ファイルが無ければ作る。既に他の設定があれば、その中にlog-driverとlog-optsを足す）。
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}log-optsの値は、"3"のように文字列で書く。公式ドキュメントは「must be provided as strings」と書いている（数値で書いたときの動きは今回試していない）。書いたらsudo systemctl restart dockerで再起動する。再起動すると動いているコンテナも止まるので、更新の作業時間の中で行う。
この例の値（10MBを3つ）は、1コンテナあたり最大30MB程度で止める目安で、Dockerの推奨値ではない。上で測った1日の量に合わせて決める。
Composeのサービスごとに書く
Composeで動かしているなら、compose.yamlのサービスにloggingを書いておくと、daemon.jsonを触らずに済み、別のVPSへ移したときも同じ設定になる。
services:
app:
image: ubuntu:24.04
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"書いた後、コンテナを作り直す
daemon.jsonもComposeのloggingも、コンテナを作るときに読まれる。検証では、compose.yamlにloggingを足した後のコマンドで結果が分かれた。
| 実行したコマンド | コンテナID | LogConfigのmax-size |
|---|---|---|
docker compose restart |
変わらない | 20mのまま（足した設定は効かない） |
docker compose up -d |
新しいIDになった | 10mに変わった |
Composeはcompose.yamlの変更を見つけるとup -dでコンテナを作り直す。daemon.jsonだけを変えたときはcompose.yamlに変化が無く、up -dだけでは作り直されないことがある（今回は試していない）ので、docker compose up -d --force-recreateで確実に作り直す。どの変更がrestartで反映されないかはdocker compose restartで反映される変更にもまとめた。
作り直すとコンテナの中に書いたファイルは消える（ボリュームは残る）。作り直す前にボリュームのバックアップで戻せるかを確かめておく。作り直した後は、上のdocker inspectで値が入ったかを必ず見る。
journaldの容量を見る
ubuntu:24.04のコンテナにaptでsystemdを入れて確かめると、journald.confの上限はすべてコメントアウトされていて、既定値のまま動く設定だった。Storage=autoは/var/log/journalがあるとディスクに保存する設定で、このコンテナではディレクトリが作られていた。VPSのOSイメージは見ていないので、自分のVPSではls -d /var/log/journalで確かめる。また/usr/lib/systemd/journald.conf.d/syslog.confにForwardToSyslog=yesがあり、同じログをsyslogへも転送する設定になっている（rsyslogが受け取ってファイルに書くかは確かめていない）。
| 確かめること | コマンド |
|---|---|
| journaldが使っている容量 | journalctl --disk-usage |
| 今すぐ減らす | sudo journalctl --vacuum-size=500M（古いファイルから消す） |
| 上限を変える | /etc/systemd/journald.conf.d/size.confに[Journal]とSystemMaxUse=500Mを書き、sudo systemctl restart systemd-journald |
既定の上限はファイルシステムの10%（4Gまで）なので、25GBのディスクなら最大2.5GB前後まで使う計算になる（空きを15%残すSystemKeepFreeが先に効けば、それより少ない）。小さいディスクのVPSでは、ここも容量の見積もりの1行に入れておく。
参考資料（確認日: 2026年10月19日）
- Docker Docs: Configure logging drivers
- Docker Docs: JSON File logging driver
- Docker Docs: Local file logging driver
- Docker Docs: Compose file reference（services の logging）
- systemd 255: journald.conf
- docker info --format '{{.LoggingDriver}}' で、既定のログドライバーを見る
- docker inspect -f '{{json .HostConfig.LogConfig}}' <コンテナ名> で、動いているコンテナのmax-sizeとmax-fileを見る
- /etc/docker/daemon.json の log-opts に max-size と max-file を文字列で書き、Dockerを再起動する
- Composeで動かしているサービスは、compose.yaml の logging に同じ値を書く
- docker compose up -d --force-recreate でコンテナを作り直し、docker inspect で値が変わったかを確かめる
- journalctl --disk-usage で、journaldのログが使っている容量を見る