症状

docker logs <container> を実行してもログが表示されない、または空の出力になる。

結論：まずこれを確認

  1. アプリケーションが stdout/stderr に出力しているか確認する
  2. ログドライバーが json-file または journald になっているか確認する
  3. コンテナが実際に起動して動作しているか確認する

トラブルシューティングフロー

    flowchart TD
    A[docker logs が空] --> B{コンテナは起動している?}
    B -->|No| C[docker ps -a で状態確認]
    B -->|Yes| D{ログドライバーは json-file?}
    D -->|No| E[ログドライバーを確認]
    D -->|Yes| F{アプリは stdout に出力?}
    F -->|No| G[アプリのログ設定を確認]
    F -->|Yes| H{ログローテーションで消えた?}
    H -->|Yes| I[ログ設定を見直す]
    H -->|No| J[docker inspect で詳細確認]
    C --> K[コンテナを起動/再作成]
    E --> L[対応ドライバーに変更]
    G --> M[stdout/stderr に出力するよう修正]

よくある原因

  • アプリケーションがファイルにログを出力している - stdout/stderr ではなく /var/log/ などに書いている
  • ログドライバーが none に設定されている - ログが一切保存されない設定
  • ログドライバーが syslog や fluentd など外部送信型 - docker logs では取得できない
  • アプリケーションがバッファリングしている - Python など一部言語でバッファが溜まるまで出力されない
  • コンテナがすぐに終了している - 起動直後にクラッシュしてログが残らない
  • ログローテーションで古いログが削除された - max-size / max-file 設定による
  • コンテナを --rm で起動して削除済み - コンテナ削除と同時にログも消える

確認手順

ステップ1: コンテナの状態を確認する

    docker ps -a --filter "name=対象コンテナ名"

🔍 チェックポイント: STATUS が Up になっているか、Exited の場合は終了コードを確認

終了コードの意味：

  • 0: 正常終了
  • 1: アプリケーションエラー
  • 137: OOM Killer または docker kill
  • 139: セグメンテーションフォルト

ステップ2: ログドライバーを確認する

    docker inspect --format='{{.HostConfig.LogConfig.Type}}' 対象コンテナ名

🔍 チェックポイント: json-file または journald なら docker logs で取得可能

対応しないログドライバー：

  • none - ログを保存しない
  • syslog - syslog に送信
  • fluentd - Fluentd に送信
  • awslogs - CloudWatch に送信
  • gcplogs - Google Cloud Logging に送信

ステップ3: アプリケーションの出力先を確認する

コンテナ内に入ってログファイルの有無を確認する：

    docker exec -it 対象コンテナ名 sh -c "ls -la /var/log/"

🔍 チェックポイント: ログファイルが存在する場合、アプリが stdout ではなくファイルに出力している

ステップ4: バッファリングを確認する（Python の場合）

Python アプリケーションの場合、以下のいずれかで unbuffered モードにする：

    # 環境変数で設定
docker run -e PYTHONUNBUFFERED=1 イメージ名

# または python コマンドに -u オプション
python -u app.py

🔍 チェックポイント: 環境変数 PYTHONUNBUFFERED が設定されているか確認

    docker inspect --format='{{.Config.Env}}' 対象コンテナ名

ステップ5: ログの保存場所を直接確認する

    # ログファイルのパスを確認
docker inspect --format='{{.LogPath}}' 対象コンテナ名

# ログファイルの中身を直接確認（root権限が必要な場合あり）
sudo cat $(docker inspect --format='{{.LogPath}}' 対象コンテナ名)

🔍 チェックポイント: ファイルが存在し、中身があるか確認

ステップ6: リアルタイムでログを監視する

    docker logs -f 対象コンテナ名

🔍 チェックポイント: アプリケーションを操作して新しいログが流れるか確認

NG行動（やってはいけないこと）

  • コンテナを削除して再作成する前にログを確認しない - 原因特定の手がかりを失う
  • ログドライバーを確認せずにログがないと判断する - 外部送信型の場合は別の場所を確認する必要がある
  • docker logs の出力がないからアプリが動いていないと判断する - ログ出力先がファイルの可能性がある
  • 本番環境で安易にログドライバーを変更する - 既存のログ収集パイプラインが壊れる可能性がある

よくある質問（FAQ）

Q1: ログドライバーを json-file に変更するにはどうする？

A: コンテナ作成時に --log-driver オプションで指定する。既存コンテナのログドライバーは変更できないため、再作成が必要。

    docker run --log-driver=json-file --log-opt max-size=10m イメージ名

Q2: 過去のログが消えてしまった。復元できる？

A: ログローテーションで削除されたログは復元できない。今後は max-size と max-file オプションを適切に設定する。

    docker run --log-opt max-size=50m --log-opt max-file=5 イメージ名

Q3: docker-compose で起動したコンテナのログドライバーを確認するには？

A: docker-compose.yml の logging セクションを確認するか、docker inspect で確認する。

    docker inspect --format='{{.HostConfig.LogConfig}}' コンテナ名

関連するエラー・症状

  • （関連記事準備中）
  • （関連記事準備中）
  • （関連記事準備中）

解決しない場合

  • Docker 公式ドキュメント - ログドライバー設定
  • 確認すべきログファイル：
    • Docker デーモンログ: /var/log/docker.log または journalctl -u docker
    • コンテナのログファイル: docker inspect --format='{{.LogPath}}' コンテナ名
  • 次に調べるキーワード: docker logging driver, container stdout redirect, application log configuration