はじめに
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形式でホストのファイルシステムに保存します。
|
|
実行結果として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ドライバーでは、ログローテーションが行われないため、ディスク容量が枯渇するリスクがあります。本番環境では必ずログサイズとファイル数を制限してください。
コンテナ起動時にログオプションを指定する方法は以下のとおりです。
|
|
| オプション | 説明 | 推奨値 |
|---|---|---|
| max-size | 1ファイルあたりの最大サイズ | 10m〜100m |
| max-file | ローテーションで保持するファイル数 | 3〜5 |
localドライバーの活用
localドライバーは、json-fileよりも効率的なファイル形式を使用し、デフォルトでログローテーションが有効になっています。本番環境ではこちらの使用が推奨されます。
|
|
デーモン全体のログ設定
すべてのコンテナに適用されるデフォルト設定を変更するには、Dockerデーモンの設定ファイルを編集します。
Linux環境の場合、/etc/docker/daemon.jsonを編集します。
|
|
**Windows/Mac(Docker Desktop)**の場合は、Docker DesktopのSettings → Docker Engine から同様の設定を追加できます。
設定変更後、Dockerデーモンを再起動します。
|
|
なお、設定変更は新規作成されるコンテナにのみ適用されます。既存のコンテナには影響しません。
コンテナのログドライバー確認
特定のコンテナで使用されているログドライバーを確認するには、docker inspectを使用します。
|
|
docker logsコマンドの活用
docker logsコマンドは、コンテナのログを確認するための基本ツールです。様々なオプションを活用することで、効率的なログ調査が可能になります。
基本的な使い方
コンテナのログを表示する基本コマンドは以下のとおりです。
|
|
主要なオプション
docker logsの主要オプションを以下にまとめます。
| オプション | 省略形 | 説明 |
|---|---|---|
| –follow | -f | リアルタイムでログを追跡 |
| –tail | -n | 末尾から指定行数を表示 |
| –timestamps | -t | タイムスタンプを表示 |
| –since | - | 指定時刻以降のログを表示 |
| –until | - | 指定時刻以前のログを表示 |
| –details | - | ログの追加属性を表示 |
実践的なログ調査例
日常的なログ調査で使用する実践的な例を紹介します。
直近のログをリアルタイムで監視
|
|
タイムスタンプ付きでログを確認
|
|
特定時間帯のログを抽出
|
|
ログをファイルに保存
|
|
ログの検索と絞り込み
|
|
複数コンテナのログ管理
Docker Composeを使用している場合、複数コンテナのログを一括で確認できます。
|
|
ログドライバーとdocker logsの関係
docker logsコマンドは、すべてのログドライバーで使用できるわけではありません。
| ログドライバー | docker logs対応 |
|---|---|
| json-file | 対応 |
| local | 対応 |
| journald | 対応 |
| none | 非対応 |
| syslog | 非対応 |
| fluentd | 非対応 |
| awslogs | 非対応 |
リモートログドライバー(fluentd、awslogsなど)を使用しつつdocker logsも使いたい場合は、デュアルロギング機能を有効にします。
|
|
コンテナのリソース制限(CPU/メモリ)
コンテナはデフォルトでホストのリソースを無制限に使用できます。本番環境では、特定のコンテナがリソースを占有して他のコンテナやホストに影響を与えることを防ぐため、適切なリソース制限が必要です。
メモリ制限
メモリ制限により、コンテナが使用できるメモリ量の上限を設定できます。
メモリ制限の設定
|
|
| オプション | 説明 | 例 |
|---|---|---|
| –memory, -m | メモリ上限 | 512m, 1g |
| –memory-swap | メモリ+スワップの合計上限 | 1g |
| –memory-reservation | ソフトリミット(推奨値) | 256m |
| –oom-kill-disable | OOM Killerを無効化 | - |
メモリ不足時の挙動
コンテナがメモリ上限に達すると、LinuxカーネルのOOM(Out Of Memory)Killerがプロセスを強制終了します。
|
|
OOM Killerを無効化する場合は、必ずメモリ制限を設定してください。設定しないとホストのメモリが枯渇する危険があります。
CPU制限
CPU制限により、コンテナが使用できるCPUリソースを制御できます。
CPU制限の設定
|
|
| オプション | 説明 | 例 |
|---|---|---|
| –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セクションを使用します。
|
|
| 設定 | 説明 |
|---|---|
| limits | ハードリミット(上限) |
| reservations | ソフトリミット(予約・保証) |
実行中コンテナのリソース制限変更
実行中のコンテナのリソース制限を変更するには、docker updateコマンドを使用します。
|
|
リソース制限の確認
設定したリソース制限を確認するには、docker inspectを使用します。
|
|
docker statsによるモニタリング
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の便利なオプションを紹介します。
|
|
出力フォーマットのカスタマイズ
--formatオプションを使用して、出力内容をカスタマイズできます。
|
|
利用可能なプレースホルダーは以下のとおりです。
| プレースホルダー | 説明 |
|---|---|
| .Container | コンテナ名またはID |
| .Name | コンテナ名 |
| .ID | コンテナID |
| .CPUPerc | CPU使用率 |
| .MemUsage | メモリ使用量 |
| .MemPerc | メモリ使用率 |
| .NetIO | ネットワークI/O |
| .BlockIO | ブロックI/O |
| .PIDs | プロセス数 |
JSON形式での出力
|
|
監視スクリプトの作成
定期的にリソース使用状況を記録するスクリプトの例を紹介します。
|
|
アラートの設定例
メモリ使用率が閾値を超えた場合に通知するスクリプトの例を紹介します。
|
|
Docker Composeでのリソース監視
Docker Composeで管理しているサービスのリソース監視も可能です。
|
|
高度なモニタリング手法
より本格的な運用では、docker statsだけでなく、専用のモニタリングツールを導入することを検討してください。
cAdvisorの活用
GoogleのcAdvisor(Container Advisor)は、コンテナのリソース使用状況を詳細に分析できるツールです。
|
|
ブラウザで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-sizeとmax-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を組み合わせた自動化について学ぶことをお勧めします。