はじめに

Dockerコンテナを本番環境で運用する際、ログ管理とリソースモニタリングは欠かせない要素です。アプリケーションの障害調査、パフォーマンス分析、キャパシティプランニングなど、あらゆる運用作業の基盤となります。

本記事では、Dockerのログ管理とモニタリングについて体系的に解説します。ログドライバーの設定、docker logsコマンドの活用、CPU/メモリのリソース制限、docker statsによるリアルタイム監視など、本番環境で必須となる実践的な手法を紹介します。この記事を読み終えると、以下のことができるようになります。

  • Dockerのログ管理の仕組みを理解できる
  • 適切なログドライバーを選定・設定できる
  • docker logsコマンドで効率的にログを調査できる
  • コンテナのCPU/メモリ使用量を制限できる
  • docker statsでリアルタイムにリソースを監視できる

前提として、Dockerの基本コマンドを習得済みであることを想定しています。まだ基本操作を押さえていない場合は、Docker基本コマンド完全ガイドを参照してください。

Dockerのログ管理の基本

Dockerコンテナのログ管理は、アプリケーションの健全性を把握し、問題発生時に迅速に原因を特定するための重要な基盤です。

コンテナログの仕組み

Dockerでは、コンテナ内のプロセスが標準出力(STDOUT)と標準エラー出力(STDERR)に出力した内容がログとして収集されます。

flowchart LR
    subgraph Container["コンテナ"]
        App["アプリケーション"]
        STDOUT["STDOUT"]
        STDERR["STDERR"]
        App --> STDOUT
        App --> STDERR
    end
    STDOUT --> LogDriver["ログドライバー"]
    STDERR --> LogDriver
    LogDriver --> Storage["保存先"]

この仕組みを理解することで、適切なログ管理戦略を立てられます。

ログ管理の重要性

本番環境でログ管理が重要な理由を以下にまとめます。

目的 説明
障害調査 エラー発生時に原因を特定し、迅速な復旧を実現
パフォーマンス分析 応答時間やスループットの傾向を把握
セキュリティ監査 不正アクセスや異常な挙動を検知
コンプライアンス 監査ログの保持要件への対応
デバッグ 開発・テスト環境での問題解決

デフォルトのログ動作

Dockerはデフォルトでjson-fileログドライバーを使用します。このドライバーは、ログをJSON形式でホストのファイルシステムに保存します。

1
2
# 現在のログドライバーを確認
docker info --format '{{.LoggingDriver}}'

実行結果としてjson-fileと表示されれば、デフォルト設定が適用されています。

ログドライバーの種類と設定

Dockerは複数のログドライバーをサポートしており、用途に応じて適切なドライバーを選択できます。

主要なログドライバー

Dockerがサポートする主なログドライバーを以下にまとめます。

ログドライバー 説明 主な用途
json-file JSON形式でローカル保存(デフォルト) 開発環境、小規模運用
local 最適化されたローカル保存形式 本番環境推奨
none ログを記録しない ログ不要なコンテナ
syslog syslogデーモンに送信 Linux環境での集中管理
journald systemd journalに送信 systemd環境
fluentd Fluentdに送信 ログ収集基盤との連携
awslogs Amazon CloudWatch Logsに送信 AWS環境
gcplogs Google Cloud Loggingに送信 GCP環境
splunk Splunkに送信 エンタープライズログ分析

json-fileドライバーの設定

デフォルトのjson-fileドライバーでは、ログローテーションが行われないため、ディスク容量が枯渇するリスクがあります。本番環境では必ずログサイズとファイル数を制限してください。

コンテナ起動時にログオプションを指定する方法は以下のとおりです。

1
2
3
4
5
6
# ログサイズとファイル数を制限してコンテナを起動
docker run -d \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  --name myapp \
  nginx
オプション 説明 推奨値
max-size 1ファイルあたりの最大サイズ 10m〜100m
max-file ローテーションで保持するファイル数 3〜5

localドライバーの活用

localドライバーは、json-fileよりも効率的なファイル形式を使用し、デフォルトでログローテーションが有効になっています。本番環境ではこちらの使用が推奨されます。

1
2
3
4
5
6
7
# localドライバーを指定してコンテナを起動
docker run -d \
  --log-driver local \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  --name myapp \
  nginx

デーモン全体のログ設定

すべてのコンテナに適用されるデフォルト設定を変更するには、Dockerデーモンの設定ファイルを編集します。

Linux環境の場合、/etc/docker/daemon.jsonを編集します。

1
2
3
4
5
6
7
{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

**Windows/Mac(Docker Desktop)**の場合は、Docker DesktopのSettings → Docker Engine から同様の設定を追加できます。

設定変更後、Dockerデーモンを再起動します。

1
2
# Linux環境の場合
sudo systemctl restart docker

なお、設定変更は新規作成されるコンテナにのみ適用されます。既存のコンテナには影響しません。

コンテナのログドライバー確認

特定のコンテナで使用されているログドライバーを確認するには、docker inspectを使用します。

1
2
# コンテナのログドライバーを確認
docker inspect -f '{{.HostConfig.LogConfig.Type}}' myapp

docker logsコマンドの活用

docker logsコマンドは、コンテナのログを確認するための基本ツールです。様々なオプションを活用することで、効率的なログ調査が可能になります。

基本的な使い方

コンテナのログを表示する基本コマンドは以下のとおりです。

1
2
3
4
5
# コンテナのログを表示
docker logs myapp

# コンテナIDでも指定可能
docker logs abc123def456

主要なオプション

docker logsの主要オプションを以下にまとめます。

オプション 省略形 説明
–follow -f リアルタイムでログを追跡
–tail -n 末尾から指定行数を表示
–timestamps -t タイムスタンプを表示
–since - 指定時刻以降のログを表示
–until - 指定時刻以前のログを表示
–details - ログの追加属性を表示

実践的なログ調査例

日常的なログ調査で使用する実践的な例を紹介します。

直近のログをリアルタイムで監視

1
2
# 末尾100行を表示し、以降をリアルタイム追跡
docker logs -f --tail 100 myapp

タイムスタンプ付きでログを確認

1
2
# タイムスタンプを付けて表示
docker logs -t myapp

特定時間帯のログを抽出

1
2
3
4
5
6
7
8
# 過去30分間のログを表示
docker logs --since 30m myapp

# 特定の日時以降のログを表示
docker logs --since "2026-01-01T10:00:00" myapp

# 特定の期間のログを表示
docker logs --since "2026-01-01T09:00:00" --until "2026-01-01T10:00:00" myapp

ログをファイルに保存

1
2
3
4
5
# ログをファイルに出力
docker logs myapp > /var/log/myapp.log 2>&1

# タイムスタンプ付きでファイルに保存
docker logs -t myapp > /var/log/myapp_with_timestamp.log 2>&1

ログの検索と絞り込み

1
2
3
4
5
6
7
8
# エラーログのみ抽出
docker logs myapp 2>&1 | grep -i error

# 特定のキーワードを含む行を抽出
docker logs myapp 2>&1 | grep "connection refused"

# 行数をカウント
docker logs myapp 2>&1 | grep -c "ERROR"

複数コンテナのログ管理

Docker Composeを使用している場合、複数コンテナのログを一括で確認できます。

1
2
3
4
5
6
7
8
# 全サービスのログを表示
docker compose logs

# 特定サービスのログをリアルタイム追跡
docker compose logs -f web db

# 各サービスの直近20行を表示
docker compose logs --tail 20

ログドライバーとdocker logsの関係

docker logsコマンドは、すべてのログドライバーで使用できるわけではありません。

ログドライバー docker logs対応
json-file 対応
local 対応
journald 対応
none 非対応
syslog 非対応
fluentd 非対応
awslogs 非対応

リモートログドライバー(fluentd、awslogsなど)を使用しつつdocker logsも使いたい場合は、デュアルロギング機能を有効にします。

1
2
3
4
5
6
7
8
9
{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-address": "localhost:24224"
  },
  "features": {
    "buildkit": true
  }
}

コンテナのリソース制限(CPU/メモリ)

コンテナはデフォルトでホストのリソースを無制限に使用できます。本番環境では、特定のコンテナがリソースを占有して他のコンテナやホストに影響を与えることを防ぐため、適切なリソース制限が必要です。

メモリ制限

メモリ制限により、コンテナが使用できるメモリ量の上限を設定できます。

メモリ制限の設定

1
2
3
4
5
6
7
8
# メモリを512MBに制限
docker run -d --memory=512m --name myapp nginx

# メモリ512MB、スワップを含めて1GBに制限
docker run -d --memory=512m --memory-swap=1g --name myapp nginx

# スワップを無効化(メモリのみ使用)
docker run -d --memory=512m --memory-swap=512m --name myapp nginx
オプション 説明
–memory, -m メモリ上限 512m, 1g
–memory-swap メモリ+スワップの合計上限 1g
–memory-reservation ソフトリミット(推奨値) 256m
–oom-kill-disable OOM Killerを無効化 -

メモリ不足時の挙動

コンテナがメモリ上限に達すると、LinuxカーネルのOOM(Out Of Memory)Killerがプロセスを強制終了します。

1
2
# OOM Killerを無効化する場合(注意して使用)
docker run -d --memory=512m --oom-kill-disable --name myapp nginx

OOM Killerを無効化する場合は、必ずメモリ制限を設定してください。設定しないとホストのメモリが枯渇する危険があります。

CPU制限

CPU制限により、コンテナが使用できるCPUリソースを制御できます。

CPU制限の設定

1
2
3
4
5
6
7
8
# CPUを1.5コア分に制限
docker run -d --cpus=1.5 --name myapp nginx

# 特定のCPUコアのみ使用(0番と1番のコア)
docker run -d --cpuset-cpus="0,1" --name myapp nginx

# CPU共有の重み付け(デフォルト1024)
docker run -d --cpu-shares=512 --name myapp nginx
オプション 説明
–cpus 使用可能なCPU数 0.5, 1.5, 2
–cpuset-cpus 使用するCPUコアを指定 “0,1”, “0-3”
–cpu-shares 相対的なCPU配分(デフォルト1024) 512, 2048

–cpusと–cpu-sharesの違い

CPU制限の動作イメージ

--cpus=1.5 の場合(ハードリミット)
┌─────────────────────────────────────┐
│  コンテナは最大1.5コア分のCPUを使用   │
│  他のコンテナの状況に関係なく制限      │
└─────────────────────────────────────┘

--cpu-shares=512 の場合(ソフトリミット・相対値)
┌─────────────────────────────────────┐
│  CPUリソースが競合した場合のみ適用    │
│  デフォルト(1024)の半分の配分       │
│  リソースに余裕があれば上限なし       │
└─────────────────────────────────────┘

Docker Composeでのリソース制限

Docker Composeでリソース制限を設定する場合は、deploy.resourcesセクションを使用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
services:
  web:
    image: nginx
    deploy:
      resources:
        limits:
          cpus: '1.5'
          memory: 512M
        reservations:
          cpus: '0.5'
          memory: 256M
設定 説明
limits ハードリミット(上限)
reservations ソフトリミット(予約・保証)

実行中コンテナのリソース制限変更

実行中のコンテナのリソース制限を変更するには、docker updateコマンドを使用します。

1
2
3
4
5
6
7
8
# メモリ制限を変更
docker update --memory=1g myapp

# CPU制限を変更
docker update --cpus=2 myapp

# 複数の設定を同時に変更
docker update --memory=1g --cpus=2 myapp

リソース制限の確認

設定したリソース制限を確認するには、docker inspectを使用します。

1
2
3
4
5
6
7
8
# メモリ制限を確認(バイト単位で表示)
docker inspect -f '{{.HostConfig.Memory}}' myapp

# CPU制限を確認
docker inspect -f '{{.HostConfig.NanoCpus}}' myapp

# 詳細な設定を確認
docker inspect myapp | jq '.[0].HostConfig | {Memory, MemorySwap, NanoCpus, CpuShares}'

docker statsによるモニタリング

docker statsコマンドは、実行中のコンテナのリソース使用状況をリアルタイムで監視するための強力なツールです。

基本的な使い方

すべての実行中コンテナのリソース使用状況を表示します。

1
2
# 全コンテナのリソース使用状況をリアルタイム表示
docker stats

実行結果の例は以下のとおりです。

CONTAINER ID   NAME      CPU %   MEM USAGE / LIMIT     MEM %   NET I/O         BLOCK I/O       PIDS
b95a83497c91   web       0.28%   5.6MiB / 512MiB       1.09%   916B / 0B       147kB / 0B      9
67b2525d8ad1   db        2.15%   256MiB / 1GiB         25.0%   2.48kB / 1kB    4.11MB / 2MB    45
e5c383697914   cache     0.05%   64MiB / 256MiB        25.0%   71.2kB / 0B     770kB / 0B      4

表示項目の説明

docker statsで表示される各項目の意味を理解しておくことが重要です。

項目 説明
CONTAINER ID コンテナID
NAME コンテナ名
CPU % ホストCPUに対する使用率
MEM USAGE / LIMIT メモリ使用量 / 上限
MEM % メモリ使用率
NET I/O ネットワーク受信量 / 送信量
BLOCK I/O ディスク読み込み / 書き込み
PIDS プロセス/スレッド数

主要なオプション

docker statsの便利なオプションを紹介します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 特定のコンテナのみ監視
docker stats web db cache

# 一度だけ取得(ストリーミングなし)
docker stats --no-stream

# 全コンテナ(停止中も含む)を表示
docker stats --all

# コンテナIDを省略せずに表示
docker stats --no-trunc

出力フォーマットのカスタマイズ

--formatオプションを使用して、出力内容をカスタマイズできます。

1
2
# カスタムフォーマットで表示
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

利用可能なプレースホルダーは以下のとおりです。

プレースホルダー 説明
.Container コンテナ名またはID
.Name コンテナ名
.ID コンテナID
.CPUPerc CPU使用率
.MemUsage メモリ使用量
.MemPerc メモリ使用率
.NetIO ネットワークI/O
.BlockIO ブロックI/O
.PIDs プロセス数

JSON形式での出力

1
2
3
4
5
# JSON形式で出力
docker stats --no-stream --format "{{ json . }}"

# 特定のコンテナをJSON形式で出力
docker stats nginx --no-stream --format "{{ json . }}"

監視スクリプトの作成

定期的にリソース使用状況を記録するスクリプトの例を紹介します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
#!/bin/bash
# monitor.sh - コンテナリソース監視スクリプト

LOG_FILE="/var/log/docker-stats.log"

while true; do
  echo "=== $(date '+%Y-%m-%d %H:%M:%S') ===" >> $LOG_FILE
  docker stats --no-stream --format \
    "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}" >> $LOG_FILE
  sleep 60
done

アラートの設定例

メモリ使用率が閾値を超えた場合に通知するスクリプトの例を紹介します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
#!/bin/bash
# alert.sh - メモリ使用率アラート

THRESHOLD=80

docker stats --no-stream --format "{{.Name}} {{.MemPerc}}" | while read name usage; do
  # パーセント記号を除去して数値化
  usage_num=$(echo $usage | tr -d '%')
  
  if (( $(echo "$usage_num > $THRESHOLD" | bc -l) )); then
    echo "警告: $name のメモリ使用率が ${usage}% に達しています"
    # ここに通知処理を追加(Slack、メールなど)
  fi
done

Docker Composeでのリソース監視

Docker Composeで管理しているサービスのリソース監視も可能です。

1
2
3
4
5
# Composeプロジェクトのコンテナを監視
docker compose ps -q | xargs docker stats

# サービス名で監視
docker stats $(docker compose ps -q web)

高度なモニタリング手法

より本格的な運用では、docker statsだけでなく、専用のモニタリングツールを導入することを検討してください。

cAdvisorの活用

GoogleのcAdvisor(Container Advisor)は、コンテナのリソース使用状況を詳細に分析できるツールです。

1
2
3
4
5
6
7
8
9
# cAdvisorを起動
docker run -d \
  --name=cadvisor \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --publish=8080:8080 \
  gcr.io/cadvisor/cadvisor:latest

ブラウザでhttp://localhost:8080にアクセスすると、Webベースのダッシュボードでリソース使用状況を確認できます。

監視スタックの構成例

本番環境では、以下のような監視スタックの構成が一般的です。

本番環境の監視スタック構成例

┌─────────────────────────────────────────────────────────┐
│                    可視化・分析                          │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐    │
│  │  Grafana    │  │   Kibana    │  │   Splunk    │    │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘    │
│         │                │                │            │
│         ▼                ▼                ▼            │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐    │
│  │ Prometheus  │  │Elasticsearch│  │   Splunk    │    │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘    │
│         │                │                │            │
│         │         ┌──────┴──────┐         │            │
│         │         │   Fluentd   │         │            │
│         │         └──────┬──────┘         │            │
│         │                │                │            │
│  ┌──────┴────────────────┴────────────────┴──────┐    │
│  │              Docker Containers                 │    │
│  │  ┌────┐  ┌────┐  ┌────┐  ┌────┐  ┌────┐      │    │
│  │  │App1│  │App2│  │ DB │  │Cache│  │ ... │      │    │
│  │  └────┘  └────┘  └────┘  └────┘  └────┘      │    │
│  └────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────┘
コンポーネント 役割
Prometheus メトリクス収集・保存
Grafana ダッシュボード・可視化
Fluentd ログ収集・転送
Elasticsearch ログ検索・分析
Kibana ログ可視化

まとめ

本記事では、Docker環境のログ管理とモニタリングについて解説しました。

ログ管理のポイント

  • デフォルトのjson-fileドライバーではログローテーションが行われないため、本番環境ではmax-sizemax-fileオプションを設定するか、localドライバーを使用する
  • docker logsコマンドの--follow--since--tailオプションを活用して効率的にログを調査する
  • 大規模環境では、Fluentdなどのログ収集基盤との連携を検討する

リソース制限のポイント

  • コンテナのメモリ制限は--memoryオプションで設定し、OOMによる予期せぬ停止に備える
  • CPU制限は--cpusでハードリミット、--cpu-sharesで相対的な配分を設定する
  • Docker Composeではdeploy.resourcesセクションで宣言的に管理する

モニタリングのポイント

  • docker statsでリアルタイムにリソース使用状況を監視する
  • --formatオプションで出力をカスタマイズし、監視スクリプトに組み込む
  • 本番環境ではPrometheus + Grafanaなどの専用ツールの導入を検討する

適切なログ管理とモニタリングを実施することで、障害の早期発見、迅速な原因究明、そしてキャパシティプランニングが可能になります。

次のステップとして、CI/CDパイプラインでのDocker活用で、GitHub ActionsとDockerを組み合わせた自動化について学ぶことをお勧めします。

参考リンク