Dockerロギングとは？可視性を向上させ、コンテナのトラブルシューティングを迅速化する（2026年）

Dockerログは stdout (NAIST) と stderr 実行中のコンテナからのストリームをログドライバがキャプチャし、ローカルファイルなどの宛先に送信します。 syslogまたはリモートサービス。それらはdocker logsで読み取ることができます。デフォルトでは、Docker はそれらを JSON ファイルとして保存します。 /var/lib/docker/containers/<container-id>/.

この記事では、コンテナが障害を起こしたり、ディスク容量が不足したり、検索が必要なログが生成されたりした場合に重要となるコマンド、フラグ、ファイルパス、ログ管理の選択肢について説明します。

Dockerコンテナとは何ですか？

Dockerコンテナは、アプリケーションコードと実行に必要なすべての依存関係を含むパッケージ化されたソフトウェア単位であり、互換性のあるランタイムを備えたあらゆる環境でプログラムが一貫して動作します。

コンテナはアプリケーションをホストから分離するため、ラップトップでテストしたコードはステージング環境と本番環境で全く同じように動作します。 

DockerコンテナはLinuxとWindowsの両方で動作します。オープンソース ドッカーエンジン 2013年に発売され、この種のパッケージングの標準フォーマットとなった。

Dockerイメージとは何ですか？

Dockerイメージは、コンテナの作成と実行に必要なコード、ライブラリ、システムツール、設定などを含む読み取り専用のテンプレートです。イメージを実行することでコンテナを作成できます。

イメージは設計図のようなもので、コンテナは実行中のインスタンスです。イメージはチーム内で非公開で共有することも、Docker Hubで公開することもできます。

Dockerのログ記録とは何ですか？

Docker ロギングとは、コンテナ化されたアプリケーションの出力、具体的には stdout (NAIST) と stderr ストリームを作成し、その出力をログドライバを通して、保存、検索、読み取り、分析が可能な宛先にルーティングします。

ログには、アプリケーションが実行している処理内容（処理されたリクエスト、発生したエラー、実行されたクエリ、開始および停止されたプロセスなど）が表示されます。ログがなければ、障害が発生したコンテナはブラックボックスとなってしまいます。

Dockerのログ記録が従来のログ記録と異なる理由

従来のアプリケーションは、安定したサーバー上の予測可能なファイルにログを書き込みます。一方、Dockerコンテナは通常、永続的なファイルではなく、標準出力と標準エラー出力にログを書き込みます。コンテナは短命で、ファイルではなくストリームに書き込み、単一のアプリケーションが複数のコンテナで同時に実行されることがよくあります。

コンテナのログ記録を難しくする3つの要因：

1. コンテナは一時的なものです。 コンテナが停止または削除されると、コンテナ内に書き込まれたログはすべて失われます。履歴データが必要な場合は、コンテナが終了する前にログを削除する必要があります。
2. ログは複数のレイヤーから生成されます。 アプリケーションログ、コンテナランタイムログ、ホストレベルのデーモンログはすべてデバッグにおいて重要ですが、それらのフォーマットが共通していることはほとんどありません。
3. 規模が大きくなると問題も変わる。 数百行のログを出力するコンテナが10個であれば管理可能だが、数百万行を出力するコンテナが1000個となると、データパイプラインの問題となる。

Dockerコンテナのログとは何ですか？

コンテナログは stdout (NAIST) と stderr コンテナ内で実行されているプロセスの出力。Dockerはこれらのストリームをキャプチャし、保存するか、設定されているログドライバに転送します。

以下のコマンドで表示できます。

• docker logs <container>: 単一コンテナのログを表示します
• docker service logs <service>Docker Swarmサービス内のすべてのコンテナのログを表示します。

docker logs コマンド: 完全リファレンス

docker logs コンテナのログを取得します。Docker Engine 20.10以降では、Dockerがコマンドラインアクセス用のログのローカルキャッシュを保持しているため、ほとんどのログドライバで動作します。

その基本的な構文は次のとおりです。

docker logs [OPTIONS] CONTAINER

コンテナ名またはコンテナIDのどちらでも使用できます。短いIDでも問題ありません。完全なハッシュ値は必要ありません。

一般的なコマンド例

以下は、よく使われるDockerコマンドの例です。 

コンテナから利用可能なすべてのログを読み取るには、次のコマンドを使用します。

docker logs web-app

ログをリアルタイムで追跡するには（例： tail -f）、 使用：

docker logs -f web-app

最後の100行だけを表示したい場合は、以下を使用してください。

docker logs --tail 100 web-app

過去30分間のログを表示するには、以下を使用します。

docker logs --since 30m web-app

2つのタイムスタンプ間のログを表示するには、以下を使用します。

docker logs --since 2026-04-17T09:00:00 --until 2026-04-17T10:00:00 web-app

すべての行にタイムスタンプを含めるには、以下を使用します。

docker logs -t web-app

ログを追跡し、履歴の最後の50行のみを保持するには、以下を使用します。

docker logs -f --tail 50 web-app

docker logs フラグ: 完全な表

「フラグ」とは、コマンドラインに渡すことができるオプションのパラメータを指します。 docker logs ログの取得方法と表示方法を制御するコマンド。 

リアルタイムログストリーミング

docker logs -f コンテナのログストリームに端末を接続し、新しい行が到着するたびに表示します。コンテナ版のtailコマンドです。 -f ログファイルに記載されています。

デプロイメントの監視、ライブリクエストのデバッグ、または修正後にエラーが再発しなくなったことを確認する際に使用します。

以下に、その実用的な用途をいくつか紹介します。

1. Docker Compose環境で実行されているすべてのサービスのログを監視するには、以下を実行します。

docker compose logs -f

2. 特定のサービスからのログのみが必要な場合（例： ウェブ サービス）、使用方法:

docker compose logs -f web

3. コンテナの最後の100行のログを表示するには、新しいログが届くたびに監視を続けてください。

docker logs -f --tail 100 web-app

知っておくべき限界

docker logs -f 以下の制限事項があります。 

• バッファはメモリ上に存在します。ログの量が非常に多い場合、行が端末に到達するまでに遅延が発生する可能性があります。
• docker logs -f ホストをまたいでテールしません。マルチホストまたはスケーリングされたワークロードの場合は、ログアグリゲーターを使用します（流暢、ロキ、エルク）の代わりに走る -f 各ホスト上で。
• コンテナが停止すると、新しいログは生成されず、ストリームは終了します。新しいインスタンスからのログを確認するには、コマンドを再実行する必要があります。

Dockerログのフィルタリングと検索

Docker はログのクエリ言語を提供していません。時間でフィルタリングするには、 --since (NAIST) と --until容量を制限する --tail出力をパイプで grep パターンマッチングのため。

以下は、インシデント発生時に最も頻繁に使用するパターンです。

時間で絞り込む

1. 過去1時間のログのみを表示したい場合は、以下を使用してください。

docker logs --since 1h web-app

2. 開始時刻と終了時刻を設定して、特定の期間のログを確認するには、以下を使用します。

docker logs --since "2026-04-17T09:00:00Z" --until "2026-04-17T09:15:00" web-app

3. 過去5分間のログを取得し、新しいログが表示されるたびに監視したい場合は、以下を使用してください。

docker logs -f --since 5m web-app

grepでエラーを検索する

grepを使ってエラーを検索すると、コンテナログ内の問題を素早く見つけることができます。以下に、その簡単な方法をいくつか紹介します。

1. すべてのエラーを見つける

ログ内のすべてのエラーを見つけるには、以下を使用します。

docker logs web-app 2>&1 | grep -i error

その 2>&1 stderr を stdout にマージするので grep 両方のストリームを認識できます。これがないと、標準エラー出力に書き込まれたエラーを見逃してしまいます。

2. 文脈を考慮した大文字小文字を区別しない検索

大文字小文字を区別しない検索を実行したり、近くの行を表示してより分かりやすいコンテキストを確認したりすることもできます。

docker logs web-app 2>&1 | grep -i -C 3 "timeout"

その -C 3 各マッチの前後に3行ずつ表示されるため、スタックトレースが読みやすくなります。

3. ノイズを除去する

ログには不要なメッセージが含まれている場合があります。特定の行（例えば、ヘルスチェックログ）を削除するには、次のようにフィルタリングできます。

docker logs web-app 2>&1 | grep -v "health-check"

フィルターを組み合わせる

複数のフィルターを組み合わせてログを絞り込み、分析を容易にすることもできます。以下に簡単な例をいくつか示します。

1. 過去1時間のエラーを確認するには、次のように時間フィルタリングとgrepを組み合わせます。

docker logs --since 1h web-app 2>&1 | grep -i error

2. 後でログのコピーを保存するには、次のようなファイルに保存します。 

docker logs --since "2026-04-17T09:00:00Z" --until "2026-04-17T10:00:00Z" web-app > incident.log 2>&1

実際のトラブルシューティングシナリオ

こうした状況への対処方法をよりよく理解していただくために、いくつかのトラブルシューティング事例をご紹介します。 

シナリオ1：コンテナが起動直後に終了する

コンテナが終了してからアタッチしようとしても、コンテナが削除されていなければ、停止したコンテナのログは引き続き利用可能です。

docker logs <container-id>

既に削除されている場合は、デーモンログ（下記のデーモンログのセクションを参照）で、そのコンテナ名に関連付けられたイベントまたはエラーを確認してください。

シナリオ2：短命なジョブコンテナ、クリーンアップ前にログが必要

走らずに --rm そしてその後点検する：

docker run --name batch-job myimage:latest

docker logs batch-job

docker rm batch-job

シナリオ3：チケットのログをファイルにエクスポートする

docker logs --timestamps web-app > web-app-$(date +%F).log 2>&1

シナリオ4：時間経過に伴うエラーの相関関係を調べる

タイムスタンプ付きのログを取得し、検索します。

docker logs -t web-app 2>&1 | grep -E "2026-04-17T09:(0[5-9]|1[0-5])"

これは、出力にタイムスタンプが含まれていることを前提として、2026年4月17日の09:05から09:15の間にタイムスタンプが付けられたすべての行と一致します。

Dockerロギングドライバとは何ですか？

ロギングドライバは、コンテナの出力が標準出力（stdout）と標準エラー出力（stderr）を出た後にどこに出力されるかを決定するコンポーネントです。Dockerには約12種類のドライバが付属しており、プラグインベースのドライバを使用したり、Docker Hubからサードパーティ製のロギングドライバをインストールしたりすることもできます。

ドライバーを指定しない場合、Docker は json-file デフォルトでは

3つの行動 json-file 知っておくと良いこと：

1. デフォルトでは回転なし: 通信量の多いコンテナは、ホストのディスク容量がなくなるまでディスク容量を消費し続けます。
2. これは後方互換性のためのデフォルト設定です。 古いバージョンのDockerや一部のKubernetesランタイムでは、これを前提としています。
3. その local ドライバーの方が通常は良い選択肢です。 ログをローテーションし、より効率的なディスク上のフォーマットを使用します。

一般的なDockerログドライバの比較

以下は、最も一般的なDockerログドライバの比較表です。

このリスト以外の情報については、公式 Dockerロギングドライバのドキュメント.

ドライバー構成

Dockerデーモン全体のデフォルトドライバを設定するには、 /etc/docker/daemon.json:

{

  "log-driver": "local"

}

編集後にデーモンを再起動します。単一コンテナのデフォルトを上書きするには、 --log-driver:

docker run -it --log-driver local alpine ash

アクティブなデフォルト設定を確認するには、以下を使用してください。

docker info

リモートロギングドライバーを使用したDockerログ

Docker Engine 20.10より前は、 docker logs ローカルにログを保存するドライバーでのみ動作しました。 json-file, journald. もしあなたが fluentd, awslogsまたは別のリモートドライバの場合、ログがローカルに利用できなかったため、コマンドはエラーを返しました。

Docker Engine 20.10では、組み込みのデュアルロギング機能によりこの問題が解決されました。リモートドライバがアクティブな場合でも、DockerはCLIが読み取れるローカルキャッシュにログを書き込みます。設定は不要です。

Dockerのログはどこに保存されますか？（プラットフォーム別のファイル保存場所）

Linuxでは、Dockerはコンテナログを /var/lib/docker/containers/<container-id>/<container-id>-json.logmacOS と Windows では、Docker Desktop は VM 内で実行されるため、ホスト上のそのパスには存在しません。ルートレス Docker は、以下のパスを使用します。 $HOME （通常は ~/.local/share/docker/containers/).

デフォルトのLinuxパス

デフォルトのLinuxパスは /var/lib/docker/containers/<full-container-id>/<full-container-id>-json.logしかし、ディレクトリ構造は次のようになります。

/var/lib/docker/

└── containers/

    ├── 3a1f8e9b2c4d.../

    │   ├── 3a1f8e9b2c4d...-json.log

    │   ├── config.v2.json

    │   ├── hostconfig.json

    │   └── hostname

    └── 7b2c9d3e5f1a.../

        ├── 7b2c9d3e5f1a...-json.log

        └── ...

コンテナの完全なIDは、 docker inspect --format '{{.Id}}' <container>.

プラットフォーム別のパス

注意： Docker Desktopを使用する場合、Dockerデーモンは仮想マシン内で実行されます。そのため、通常は、その仮想マシンに接続しない限り、MacまたはWindowsシステムからログファイルに直接アクセスすることはできません。したがって、日常業務では、 docker logsAPIを介して読み込み、どこでも同じように動作します。

Dockerのログ配信モード：ブロッキングとノンブロッキング

ブロッキングモードでは、ログドライバの処理能力が追いつかない場合に、アプリケーションのログ書き込みがブロックされます。ノンブロッキングモードでは、ログはメモリにバッファリングされます。ブロッキングモードでは、遅延は発生しますが、確実な配信が保証されます。ノンブロッキングモードでは、確実な配信が保証されますが、パフォーマンスは保証されません。

ブロッキングモード（対応ドライバーのデフォルト設定）

すべてのログ書き込みは、ドライバがメッセージを受け入れるまで待機します。ドライバが高速な場合（ json-file ローカルに書き込みを行う場合、待機時間は目に見えません。ドライバが遅い場合（ネットワーク障害中にリモートサービスにデータを送信しているネットワークベースのドライバなど）、アプリケーションは一時停止します。

ノンブロッキングモード

コンテナはログをメモリ内のリングバッファに書き込み、実行を継続します。バックグラウンドワーカーがバッファの内容をドライバに出力します。ワーカーがバッファを出力しきれない場合、新しいログ行は破棄されます。

非ブロッキングモードの設定方法は以下のとおりです。 daemon.json:

{

  "log-driver": "local",

  "log-opts": {

    "mode": "non-blocking",

    "max-buffer-size": "4m"

  }

}

または容器1個あたり：

docker run -it --log-opt mode=non-blocking --log-opt max-buffer-size=4m alpine

どのモードをいつ使用するか

状況に応じてモードを選択してください。 

マルチコンテナおよびオーケストレーションのログ記録

コンテナが1つなら簡単です。5台のホストにまたがる50個のコンテナとなると話は別です。大規模になると、オーケストレーション対応のツールが必要になります。 docker logs 実行されているホストのみを認識する。

ドッカーの作成

Docker Compose は、1 つ以上の Compose ファイル (一般的には docker-compose.yml) 一般的な Compose プロジェクトには、Web サーバー、データベース、キャッシュ、バックグラウンド ワーカーなどが含まれる可能性があり、これらはすべて、互いに通信する別々のコンテナとして実行されます。

Composeスタックをデバッグしているときは、 docker logs コンテナを一つずつ確認していくのは時間がかかります。コンテナの一覧を作成し、それぞれのIDをコピーして、個別にチェックする必要があるからです。 

Composeは、プロジェクト全体に作用する独自のログ記録コマンドによってこの問題を解決します。

# To see logs from all services in the project:

docker compose logs

# To follow logs from all services in real time:

docker compose logs -f

# To see only the last 200 lines from a specific service (here, 'web'):

docker compose logs --tail 200 web

# To follow logs from multiple specific services:

docker compose logs -f web worker

各行にサービス名をプレフィックスとして付けます（例： web_1 | or worker_1 |これにより、サービス間のタイムラインが読みやすくなります。リクエストがウェブサービスからワーカーに移動して失敗した場合、ターミナルのタブを切り替えることなく、単一のストリームでサービス間を移動する様子を確認できます。

Kubernetes

Kubernetes コンテナを実行するが、ログモデルが異なる。

• kubectl logs <pod> kubelet から読み取り、kubelet はコンテナランタイム (多くの場合 containerd（Dockerデーモンを直接操作するわけではありません）。
• ログのローテーションは、Dockerのログドライバではなく、kubeletレベルで行われます。
• ノードレベルのエージェントパターン（Fluent Bit、Vector、Promtailなど）は、クラスタからログを送信する標準的な方法です。

通常のDockerからKubernetesに移行する場合、ログドライバの設定は引き継がれないことに注意してください。ログの設定は、ノードレベルとクラスタレベルで個別に行う必要があります。

スケーリングの課題

規模を拡大していくと、次の3つの問題が浮上します。

1. ボリューム： 1000個のコンテナは1時間あたりギガバイトのデータを生成する可能性がある。ローカルディスクはそれを長期的に保持することはできない。
2. 相関： 1つのユーザーリクエストが10個のサービスにまたがる場合があります。共有トレースIDがなければ、そのリクエストを追跡することはできません。
3. 保持： コンプライアンス規則によっては、90日または365日分のログの保存が義務付けられる場合があります。ホストごとのログローテーションにより、それよりもずっと前にログが削除されます。

これら3つの問題を解決するには、ホストからログを中央ストレージに送信することです。多くのお客様が、この段階で専用のオブザーバビリティプラットフォームの導入を検討し始めます。コンテナログを仮想マシン、クラウドサービス、ネットワーク機器からのメトリクスと併せて管理する場合、それらを独自に統合する作業は、エンジニアリングに費やす時間に見合わなくなります。

Dockerログのクリア、ローテーション、およびサイズ管理

docker logs 削除コマンドはありません。ログをクリアするには、基となる JSON ファイルを切り詰めるか、コンテナを削除して再作成するか、ログが無制限に増えないようにローテーションを設定する必要があります。 

ログサイズが重要な理由：ディスク容量のリスク

その json-file ドライバーは書き込みます /var/lib/docker/containers/<id>/<id>-json.log デフォルトではサイズ制限がありません。デバッグ出力を印刷する単一のコンテナでも、数日で100GBのディスクがいっぱいになる可能性があります。パーティションがいっぱいになると、Dockerの操作が失敗し始め、コンテナは書き込み、イメージのプル、ログの書き込みができなくなります。

現在のログサイズを確認してください：

sudo du -ch /var/lib/docker/containers/*/*-json.log | sort -h

ログローテーションの設定

それを行う方法は次のとおりです：

回転をグローバルに設定する /etc/docker/daemon.json:

{

  "log-driver": "json-file",

  "log-opts": {

    "max-size": "10m",

    "max-file": "3"

  }

}

これにより、各ログのサイズが10MBに制限され、コンテナごとに3つのローテーションファイルが保持されます（コンテナあたり合計約30MB）。保存後、Dockerデーモンを再起動してください。または、コンテナごとにローテーションを設定することもできます。

docker run -d \

  --log-opt max-size=10m \

  --log-opt max-file=3 \

  myapp:latest

その local ドライバーは追加の設定なしで自動的に回転します。これが、デフォルトとして推奨する理由の1つです。 json-file.

安全にログをクリアする

単一コンテナのログファイルをクリアするには（root権限が必要。コンテナは引き続き実行される）、以下のコマンドを使用します。

sudo truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container>)

切り捨ては一般的に安全です。ファイルディスクリプタは有効なままで、Docker は新しい行の書き込みを続けます。 rm そのコンテナが再起動するまで、そのコンテナのログ記録は中断されます。

ホスト上のすべてのコンテナログをクリアするには、以下を使用します。

sudo sh -c "truncate -s 0 /var/lib/docker/containers/*/*-json.log"

コンテナを完全に削除するには（ログも削除します）、以下を使用します。

docker rm -f <container>

クリーンアップを自動化する

ローテーションが設定されていないホストの場合、cronジョブを使用してログの制限を維持できます。

# /etc/cron.daily/docker-log-trim

#!/bin/sh

find /var/lib/docker/containers -name "*-json.log" -size +100M -exec truncate -s 0 {} \;

よりよい： ローテーションを適切に設定し、手動でのログ切り捨てを避けてください。

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

　　 docker logs 何も返さない、出力が不完全、またはエラーが発生する場合、原因はほぼ常に次の4つのいずれかです。 

1. 伐採作業員
2. 書き込み前に終了したコンテナ
3. 標準出力ではなくファイルにログを出力するアプリケーション
4. まだフラッシュされていないバッファリングされた出力

ログは表示されません

あなたは走る docker logs <container> そして何も返ってこない。これは通常、次の2つのいずれかを意味します。コンテナのログ記録が無効になっているか、アプリケーションがDockerから見えない場所にログを書き込んでいるかのどちらかです。 

両方のチェック項目を順番に確認してください。

1. まずアクティブなドライバーを確認してください。

docker inspect --format '{{.HostConfig.LogConfig.Type}}' <container>

もし noneそのコンテナではログ記録が無効になっています。削除 --log-driver=none 実行コマンドから。

2. プロセスが書き込む内容を確認する。 

Docker は stdout と stderr のみをキャプチャします。アプリケーションがコンテナ内のファイルにログを書き込む場合 (たとえば、従来のサーバー環境を想定している古いアプリケーションでよく見られるパターン)、 /var/log/app.log or /app/logs/server.logDocker はこれらの行をキャプチャしません。 

ログファイルは存在しますが、コンテナが削除されると消えてしまう一時ファイルシステムの中に閉じ込められています。

この問題を解決するには、2つの方法があります。

• アプリケーションを再設定して、標準出力にログを出力するようにします。 これは長期的な解決策であり、Docker が設計されているパターンです。ほとんどの最新のフレームワークは、環境変数または設定変更によってこれをサポートしています。たとえば、nginx は、ログを次の場所に記録するように設定できます。 /dev/stdout、そしてほとんどのログライブラリ（Log4j、Winston、Pythonの logging モジュール）はコンソールハンドラをサポートします。
• ログファイルをボリュームを使用してホストにマウントします。 アプリケーションを変更できない場合は、ログディレクトリをバインドマウントして、ファイルがコンテナ外でも保持されるようにします。 docker run -v /host/logs:/var/log/app myappこれらのファイルを監視したり送信したりするには、別途プロセスが必要になりますが、少なくともアクセスできるようになります。

ログが遅延または不完全です

Pythonや一部のJVM（Java仮想マシン）アプリケーションは、端末への書き込みが行われていないことを検出すると、標準出力をバッファリングします。コンテナは実行されますが、バッファがクリアされるまでログが表示されない場合があります。

Pythonを使用してこれを修正するには、以下を実行してください。

docker run -e PYTHONUNBUFFERED=1 myapp

または追加 python -u コマンドに対して。Node.jsの場合、通常はログを1行ずつフラッシュしますが、ライブラリによってはバッファリングを行う場合があります。お使いのライブラリでバッファリングが行われていない場合は、フラッシュオプションについてドキュメントを確認してください。

コンテナは即座に退出します

コンテナがログを読み取る前に存在する場合は、以下を実行してください。

docker logs <container-id>

ログはコンテナが存在する限り残ります。 --rmコンテナとそのログは既に削除されています。 --rm デバッグ用。

エラー：「設定されたログドライバは読み取りをサポートしていません」

あなたは、次のようなリモートドライバを備えた 20.10 より古い Docker Engine を使用しています fluentd or awslogsDockerをアップグレードするか（20.10以降ではデュアルロギングが組み込まれています）、代わりにリモートの宛先でログを読み取ります。

ユースケースに合わないログ記録ドライバ

If docker logs 動作はしますが、音量が大きすぎます。おそらく json-file 回転なし。 local または追加 max-size (NAIST) と max-file ログの増加を制限するために、ドライバオプションを使用してください。

デーモンログとは何ですか？

デーモンログには、Dockerエンジン自体の動作（コンテナの起動と停止、イメージのプル、ネットワークの作成、プラグインのロード、Docker自体からのエラーなど）が記録されます。これらはコンテナログとは別個のものであり、ホストオペレーティングシステムによって保存および管理されます。

コンテナログにはアプリケーションの動作が記録されます。デーモンログにはDockerの動作（または失敗）が記録されます。コンテナが何も書き込む前に終了した場合、通常、デーモンログがその理由を示す唯一の記録となります。

デーモンログの場所

それらは、オペレーティングシステムや設定によって異なる場所に保存されます。

注意： 最新のLinuxでは、sudo journalctl -xu docker.service を実行してください。

Dockerのデュアルロギングを理解する

Docker デュアルログ コンテナの出力を一度に2つの宛先（通常はローカルファイルとリモートアグリゲーター）に送信します。一方の宛先が失敗しても、もう一方にはデータが残っています。Docker Engine 20.10では、ログをローカルにキャッシュする組み込み機能にもこの用語が内部的に使用されているため、docker logsはリモートドライバでも動作します。

同じ名前だが、意味は2つ異なる。

1. 組み込みのデュアルログ機能またはローカルログキャッシュ（20.10以降）： Dockerは、設定されたドライバとともにローカルキャッシュに自動的に書き込むため、 docker logs どのドライバからでも読み取ることができます。設定は不要です。
2. ユーザー設定可能なデュアルログ機能： 冗長性、監査、または地域的なコンプライアンスのために、2つの宛先に書き込むログパイプラインを設定します。

ユーザー設定可能なデュアルロギングの利点

ユーザーが設定可能なデュアルログ機能の最も一般的な利点には、以下のようなものがあります。

• 冗長性： リモートアグリゲーターへのネットワーク障害が発生しても、ローカルコピーが同時に書き込まれていれば、ログデータは失われません。
• コンプライアンス： 一部の規制では、ローカルでの保管とオフサイトでのバックアップが義務付けられています。1つのパイプラインと2つの送信先があれば、両方に対応できます。
• より迅速なトリアージ： ホスト上のログはすぐに利用可能で、 grep インシデント発生時。集約されたログは、ホスト間の状況を把握するのに役立ちます。

Dockerのデュアルロギングの実践例

ITチームはDockerをデュアルログで使用しています。

• 電子商取引、 GDPR、 (NAIST) と CCPA コンプライアンス： ログは迅速なデバッグのためにローカルに保存され、保持監査のために地域のクラウドストレージに送信されます。
• 金融業務： ログはオンプレミスのSIEMとクラウドアーカイブにミラーリングされます。SIEMが侵害された場合でも、アーカイブは影響を受けません。
• SaaSの信頼性： ホストごとのデバッグ用ローカルログと、オンコールエンジニアがフリート全体をダッシュ​​ボードで確認するための集中ログ。

デュアルロギングの実装方法

Docker自体では、1つのコンテナに2つのドライバを設定することはできません。標準的なパターンは次のとおりです。

1. ローカルに書き込む 1 つの Docker ロギング ドライバを使用します (json-file or local).
2. ホスト上でログシッパーを実行し、それらのファイルを監視し、リモートの宛先に転送します。

集中型ログ記録アーキテクチャ：エージェント、ドライバー、それともサイドカー？

ホストからコンテナログを取得する一般的な方法は3つあります。 

1. ログファイルを読み取るノードレベルのエージェント
2. 直接プッシュするDockerログドライバー
3. アプリケーションごとのサイドカーコンテナ 

それぞれにトレードオフがあります。 

ハイブリッド環境のお客様との協業経験から、ノードレベルのエージェントパターンが最も多くの場合に採用されています。操作が簡単で、コンテナの再起動後も動作し、ベアメタル、仮想マシン、Kubernetesのいずれの環境でも安定して動作します。

ノードレベルエージェント（ほとんどのチームに推奨）

各ホスト上で単一のエージェント（Fluent Bit、Vector、Promtail、Filebeat）が実行されます。これは、通常以下のコンテナログファイルを監視し、 /var/lib/docker/containers/*/*-json.log そして中央倉庫へ転送される。

ロギングドライバ

Dockerのログドライバは、ログを宛先（Fluentd、AWS CloudWatch、Graylog）に直接プッシュします。

サイドカーコンテナ

アプリコンテナと並行して、共有ボリュームからログを監視する2つ目のコンテナが稼働する。

それぞれをいつ使用するか

以下のいずれかを使用すべき状況は以下のとおりです。 

• 多数のコンテナを実行するVMまたはベアメタルホストのデフォルトオプションとして、ノードレベルのエージェントを使用します。
• 小規模な環境、または可能な限りシンプルな設定が必要な場合は、ログ記録ドライバを使用してください。
• Kubernetesワークロードが出荷前にポッドごとのログ変換を必要とする場合は、サイドカーを使用してください。

Dockerロギングのベストプラクティス

次のベストプラクティスに従ってください。 

• ログは標準出力と標準エラー出力に出力し、コンテナ内のファイルには出力しないでください。コンテナが削除されるとファイルは消えてしまうためです。ストリームはDockerによってキャプチャされます。
• 可能な限り構造化ログ（JSON）を使用してください。自由形式のテキストログは人間にとっては問題ありませんが、パーサーやダッシュボードには構造が必要です。
• 初日からログローテーションを有効にしてください。 max-size (NAIST) と max-file すべての制作ホストへ。
• 好む local ドライバーオーバー json-file デフォルト設定のままにしておく理由がない限りは。
• ホストからログを転送してください。本番環境のワークロードはすべて中央ストレージに転送する必要があります。
• ログにサービス名、環境、バージョンをタグ付けします。これにより、複数のサービス群全体にわたる検索が可能になります。
• ログパイプライン自体を監視します。ホスト上のディスク使用量、シッパーのキュー深度、アグリゲーターでの取り込み速度を追跡します。
• ログ転送を暗号化してください。特に信頼できないネットワーク上では、送信者と集約者の間でTLSを使用してください。

LM EnvisionでDockerログからより多くの情報を引き出す

Dockerのログは役立ちますが、それだけでは全体像の一部しか把握できません。コンテナのトラブルシューティングを効果的に行うには、ログのアクティビティをインフラストラクチャの状態、パフォーマンス指標、アラート、および最近の変更点と関連付ける必要があります。

LMエンビジョン それらの文脈をまとめる。 

LogicMonitorは、ログ、メトリクス、イベントを単一のプラットフォームに統合することで、検出から解決までのプロセスを迅速化します。Dockerログを個別のトラブルシューティング手順として扱うのではなく、運用状況全体の一部として分析できます。

つまり、ツールを切り替える時間が減り、自信を持って問題解決に取り組める時間が増えるということです。手動でのDockerログの確認にとどまらず、LogicMonitorを使えば、コンテナデータを環境全体にわたる実用的なインサイトに変換できます。

よくあるご質問