Docker ログ: Docker コンテナではログはどのように機能しますか?
ログ記録は、パフォーマンスの非効率性やアーキテクチャ構造など、アプリケーションに関する貴重な洞察を得るために不可欠です。しかし、信頼性が高く、柔軟性があり、軽量なログ記録ソリューションを作成するのは簡単なことではありません。そこで Docker が役立ちます。
Docker コンテナは、軽量でポータブルな自己完結型のアプリケーション環境を作成するのに最適な方法です。また、IT チームは、あらゆる環境で実行できる一時的かつポータブルなログ ソリューションを作成することもできます。ログはパフォーマンスにとって非常に重要な側面であるため、トラブルシューティングや監査のために信頼性の高いログ管理を必要とする複雑なマルチ コンテナ セットアップでは、Docker デュアル ログがより効果的です。
Docker デュアルログ コンテナ ログを 2 つの異なる場所で同時にキャプチャできます。このアプローチにより、分散環境全体で一貫したログ データを維持することで、ログの冗長性、コンプライアンスの向上、オペレーティング システム (Windows、Linux など) の監視可能性の強化が保証されます。
このガイドでは、インフラストラクチャを最適化するための Docker デュアル ログ機能の実装に重点を置いて、Docker ログの基本について説明します。
Dockerコンテナーは、コードとそのすべての依存関係をラップするソフトウェアの標準ユニットであるため、プログラムをある環境から別の環境に迅速かつ確実に移動できます。
LinuxおよびWindowsベースのアプリケーションで利用可能なコンテナ化されたソフトウェアは、インフラストラクチャに関係なく常に同じように実行されます。
コンテナーは、その環境からソフトウェアをカプセル化し、開発やステージングなどの環境間の違いにかかわらず、一貫して実行されるようにします。
Dockerコンテナテクノロジーがオープンソースとして導入されました ドッカーエンジン 2013インチ
Dockerイメージは、コード、システムツール、システムライブラリ、設定など、アプリケーションの実行に必要なすべてのものを含む、軽量でスタンドアロンの実行可能ソフトウェアパッケージです。
つまり、イメージは読み取り専用のテンプレートであり、Dockerプラットフォームで動作できるコンテナーを構築するための手順が含まれています。 これは、他のDockerユーザーとプライベートまたはオープンに使用できるプログラムとプリセットサーバー環境をパッケージ化する簡単な方法を提供します。
Docker ログ記録とは、コンテナ化されたアプリケーションによって生成されたログをキャプチャして管理するプロセスを指します。ログはシステムの動作に関する重要な洞察を提供し、問題のトラブルシューティング、パフォーマンスの監視、アプリケーション ログの全体的な健全性の確保に役立ちます。
監視ソリューションと組み合わせることで、コンテナ化された環境の完全な可視性を維持できるため、問題をより迅速に解決し、信頼性を確保できます。他のデータ インサイトを使用して、履歴データを調べて傾向を見つけ、潜在的な問題を予測できます。
Docker ログは重要なシステム動作の洞察をキャプチャし、コンテナ化された環境でのトラブルシューティング、パフォーマンスの監視、アプリケーションの正常性の確保を可能にします。
Dockerコンテナログは、一言で言えば、実行中のコンテナのコンソール出力です。 特に、コンテナ内で実行されるstdoutストリームとstderrストリームを提供します。
前に述べたように、Dockerロギングは他の場所でのロギングと同じではありません。 Dockerのstdoutストリームとstderrストリームに書き込まれるものはすべて、暗黙的にドライバーに転送され、ログにアクセスしてファイルに書き込むことができます。
ログはコンソールでも表示できます。 Docker logsコマンドは、現在実行中のコンテナーから送信された情報を表示します。 docker service logsコマンドは、サービスのすべてのコンテナーメンバーによる情報を表示します。
Dockerロギングドライバーはコンテナーからデータを収集し、分析のためにアクセスできるようにします。
コンテナーの起動時に追加のログドライバーオプションが指定されていない場合、Dockerはデフォルトでjson-fileドライバーを使用します。 これに関するいくつかの重要な注意事項:
Dockerには、さまざまなサービス(ログサービス、ログシッパー、ログシッパーなど)にログを送信するためのログドライバーも含まれています。 ログ分析プラットフォーム。 利用可能なDockerロギングドライバーはたくさんあります。 いくつかの例を以下に示します。
ただし、いくつかの代替ロギングドライバオプションがあります。 Dockerロギングドキュメント。
Dockerでは、ロギングドライバープラグインも使用できるため、Dockerロギングドライバーを作成して、 Dockerハブ。 同時に、DockerHubでアクセス可能な任意のプラグインを使用できます。
Dockerロギングドライバーをすべてのコンテナーのデフォルトとして構成するには、log-driverの値をdaemon.json構成ファイルのロギングドライバーの名前に設定します。
この例では、デフォルトのロギングドライバーをローカルドライバーに設定します。
{
“log-driver”: “local”
}もうXNUMXつのオプションは、コンテナーごとにドライバーを構成することです。 コンテナーを初期化するときに、–log-driverフラグを使用して、Dockerデーモンのデフォルトとは異なるロギングドライバーを指定できます。
以下のコードは、ローカルのDockerロギングドライバーを使用してAlpineコンテナーを起動します。
docker run -it –log-driver local alpine ashdocker infoコマンドは、Dockerデーモンの現在のデフォルトのロギングドライバーを提供します。
リモートロギングドライバーを使用したDockerログ
以前は、Docker logsコマンドは、ローカル、json-file、またはジャーナル化されたログドライバーを利用するコンテナーをサポートするログドライバーでのみ使用できました。 ただし、多くのサードパーティのDockerロギングドライバーは、Dockerログからローカルでログを読み取ることを有効にしませんでした。
ログデータを自動的かつ一貫して収集しようとすると、多くの問題が発生しました。 ログ情報は、サードパーティのソリューションで必要な形式でのみアクセスおよび表示できました。
Docker Engine 20.10以降では、Dockerログを使用して、有効になっているロギングドライバーまたはプラグインとは関係なくコンテナーログを読み取ることができます。
デュアルロギングでは、構成を変更する必要はありません。 選択したDockerロギングドライバーがログの読み取りをサポートしていない場合、Docker Engine20.10は後でデフォルトでダブルロギングを許可します。
Dockerは、コンテナーログをデフォルトの場所/ var / lib / docker /に保持します。 各コンテナには、そのID(一般的に表示される短いIDではなく完全なID)に固有のログがあり、次のようにアクセスできます。
/var/lib/docker/containers/ID/ID-json.log
docker run -it –log-driver local alpine ashDockerロギング配信モードは、コンテナーが他のタスクに対してロギングのバランスをとる、または優先する方法を指します。 使用可能なDockerロギング配信モードは、ブロッキングと非ブロッキングです。 選択したDockerロギングドライバーに関係なく、両方のオプションを適用できます。
ブロッキングモードでは、メッセージをドライバーに配信する必要があるときはいつでもプログラムが中断されます。
ブロッキングモードの利点は、アプリケーションのパフォーマンスに遅れが生じる可能性がある場合でも、すべてのログがロギングドライバーに転送されることです。 この意味で、このモードはパフォーマンスよりもロギングを優先します。
選択したDockerロギングドライバーに応じて、アプリケーションのレイテンシーは異なる場合があります。 たとえば、ローカルファイルシステムに書き込むjson-fileドライバーは、ログを迅速に生成し、ブロックしたり、大幅な遅延を引き起こしたりする可能性はほとんどありません。
逆に、コンテナーがリモートの場所に接続する必要があるDockerロギングドライバーは、コンテナーを長期間ブロックする可能性があり、その結果、レイテンシーが増加します。
Dockerのデフォルトモードはブロッキングです。
ほとんどの使用状況では、ブロッキングモードのjson-fileロギングドライバーをお勧めします。 前述のように、ドライバーはローカルファイルに書き込むため、高速です。 したがって、一般的に、ブロックして使用するのが安全です。
ブロッキングモードは、コンテナで使用可能なRAMの大部分を必要とするメモリを大量に消費するプログラムにも使用する必要があります。 その理由は、ネットワークの問題などの問題が原因でドライバーがエンドポイントにログを配信できない場合、非ブロッキングモードの場合、バッファーに使用できる十分なメモリがない可能性があるためです。
非ブロッキングDockerログ配信モードは、ログを提供するためにプログラムを実行することを妨げません。 ログが宛先に送信されるのを待つ代わりに、コンテナはログをメモリ内のバッファに保存します。
非ブロッキングDockerログ配信モードが望ましいオプションのように見えますが、一部のログエントリが失われる可能性もあります。 ログが保存されるメモリバッファの容量には限りがあるため、いっぱいになる可能性があります。
さらに、コンテナが壊れた場合、バッファから解放される前にログが失われる可能性があります。
log-optsアイテムをdaemon.jsonファイルに追加することで、新しいコンテナーに対するDockerのデフォルトのブロックモードをオーバーライドできます。 上記のメモリバッファ容量を表すmax-buffer-sizeも、デフォルトの1MBから変更される場合があります。
{
“log-driver”: “local”,
“log-opts”: {
“mode”: “non-blocking”
}
}また、単一のコンテナーでlog-optsを提供できます。 次の例では、非ブロッキングログ出力と4MBのバッファーを備えたAlpineコンテナーを作成します。
docker run -it –log-opt mode=non-blocking –log-opt max-buffer-size=4m alpineアプリケーションに大きなI / O要求があり、大量のログを生成する場合は、非ブロッキングモードでjson-fileドライバーを使用することを検討してください。
ログをローカルに書き込むのは高速であるため、バッファがすぐにいっぱいになる可能性はほとんどありません。 プログラムがログの急増を引き起こさない場合、この構成はパフォーマンスを妨げることなくすべてのログを処理する必要があります。
パフォーマンスがロギングよりも優先されるが、ログにローカルファイルシステムを使用できないアプリケーション(ミッションクリティカルなアプリケーションなど)の場合、信頼できるバッファに十分なRAMを提供し、非ブロッキングモードを使用できます。 この設定により、ログによってパフォーマンスが妨げられないようにする必要がありますが、コンテナーはほとんどのログデータを処理する必要があります。
Docker のようなコンテナ化された環境でのログ記録は、コンテナの一時的かつ分散的な性質のため、従来のシステムよりも複雑です。Docker コンテナは、多くの場合異なる形式の複数のログ ストリームを生成するため、標準的なログ分析ツールの効果が低下し、単一の自己完結型アプリケーションと比較してデバッグが困難になります。
この複雑さの一因となっているのは、Docker コンテナの 2 つの重要な特性です。
Docker デュアル ログでは、ログを 2 つの異なる場所に同時に送信します。このアプローチにより、ログ データが冗長的に保存され、データ損失のリスクが軽減され、分析用の複数のソースが提供されます。デュアル ログは、コンプライアンスと稼働時間が重要な環境で特に役立ちます。
デュアル ロギングは、複数のシステムにわたって重要なログ データを保持することにより、複雑なコンテナー化されたアプリケーションにセーフティ ネットを提供します。
Docker デュアル ロギングは、コンプライアンス、セキュリティ、システムの信頼性を向上させるために、さまざまな業界で広く実装されています。Docker デュアル ロギングを実装することで、データを保護し、規制要件を満たし、インフラストラクチャを最適化できます。以下は、組織がデュアル ロギングからどのようなメリットを得ているかを示す実際の例です。
Docker エンジンでデュアル ログを実装するには、複数のログ ドライバーを使用するようにコンテナを構成する必要があります。たとえば、ログはローカル JSON ファイルと AWS CloudWatch などのリモート ログ サービスの両方にルーティングできます。簡単な構成ファイルの例を次に示します。
bash
copy code
docker run -d \
--log-driver=json-file \
--log-driver=fluentd \
--log-opt fluentd-address=localhost:24224 \
your-container-image特定のログ ドライバーとその他の設定は、特定の構成によって異なります。組織のインフラストラクチャを調べて、ドライバー名とログ サーバーのアドレスを確認してください。
この設定により、ログはローカルに保存されると同時に、集中ログ管理サービスにも送信されます。 Kubernetesを使用する パブリッククラウド環境を管理および監視するには、 LogicMonitorコレクター クラウド監視の向上のため。
Dockerプラットフォームは、デーモンのログを生成して保存します。 ホストのオペレーティングシステムに応じて、デーモンログはシステムのログサービスまたはログファイルに書き込まれます。
コンテナログのみを収集した場合は、サービスの状態に関する洞察を得ることができます。 一方、Dockerプラットフォーム全体の状態を通知する必要があります。デーモンログは、マイクロサービスアーキテクチャ全体の概要を提供するため、そのために存在します。
コンテナが予期せずシャットダウンしたと想定します。 ログイベントをキャプチャする前にコンテナが終了するため、dockerlogsコマンドまたはアプリケーションベースのログフレームワークを使用して根本的な原因を特定することはできません。
代わりに、コンテナ名またはIDを含むイベントのデーモンログをフィルタリングし、タイムスタンプで並べ替えることができます。これにより、コンテナの発生から破壊までの寿命の時系列を確立できます。
デーモンログには、ホストのステータスに関する役立つ情報も含まれています。 ホストカーネルが特定の機能をサポートしていない場合、またはホストセットアップが最適でない場合、Dockerデーモンは初期化プロセス中にそれを記録します。
オペレーティングシステムの設定と使用するDockerログサブシステムによっては、ログが次のようになる場合があります。 多くの場所のXNUMXつに保管。 Linuxでは、journalctlレコードを確認できます。
sudo journalctl -xu docker.serviceログデータは、使用する前に評価する必要があります。 ログデータを分析すると、干し草の山の中の針を探していることになります。
通常、数千行の通常のログエントリの中でエラーが発生したXNUMX行を探しています。 ログの実際の値を決定するには、堅固な分析プラットフォームが必要です。 ログ収集および分析ツールは重要です。 ここにいくつかのオプションがあります。
Fluentdは、Docker以外のサービスを含む完全なスタックをログに記録するための一般的なオープンソースソリューションです。 これは、データの収集と消費を統合して、データの使用率と理解を向上させることができるデータコレクターです。
ELKは、最も広く使用されているオープンソースのログデータ分析ソリューションです。 これは一連のツールです。ElasticSearch ログデータを保存するため、 ログスタッシュ ログデータを処理するため、および 木場 グラフィカルユーザーインターフェイスを介してデータを表示するため。
ELKは、大規模な開発者コミュニティによって維持されている堅固なプラットフォームを提供し、無料であるため、Dockerログ分析の優れたソリューションです。
オープンソースの代替手段では、スタックを個別に構築および管理する必要があります。これには、必要なリソースを割り当て、ツールへのアクセス性が高く、スケーラブルなインフラストラクチャに格納されていることを確認する必要があります。 また、かなりの量のITリソースが必要になる可能性があります。
ここで、より高度なログ分析プラットフォームが大きな利点を提供します。 たとえば、次のようなツール ログインテリジェンスと集約のためのLogicMonitorのSaaSプラットフォーム チームは、単一の統合されたクラウドベースのプラットフォームで、コンテキスト化され接続されたログとメトリックにすばやくアクセスできます。
これらの高度なテクノロジーは、機械学習の力を活用して、企業がトラブルシューティングを減らし、IT運用を合理化し、リスクを低減しながら制御を強化できるようにします。
Docker デュアル ログには多くの利点があります。ただし、最大限に活用するには、信頼性の高いログ環境を構築するためのベスト プラクティスを実装する必要があります。まずは、以下のベスト プラクティスを使用してください。
ログが 2 か所に保存されると、分析はより複雑になります。Fluentd や ELK などのログ集約ツールを使用して両方のソースからログを収集および分析すると、システムの動作を包括的に把握できます。この二重のアプローチにより、問題を迅速に検出して解決する能力が大幅に向上します。
Docker はさまざまなログ ドライバーをサポートしており、それぞれが異なるユース ケースに適しています。デュアル ログを実装する際には、ドライバーを組み合わせて使用することで、環境全体で最良の結果を得ることができます。一般的なドライバーには次のものがあります。
Docker デュアル ログを最大限に活用するには、強力なログ管理ツールとの統合が不可欠です。これらの一般的なツールは、ログの集約、分析、視覚化のための高度な機能を提供することで、Docker デュアル ログを強化します。
Docker デュアル ログは、コンテナ化された環境で信頼性の高い冗長ログ管理を実現するための強力な戦略です。デュアル ログを実装すると、システムの回復力が強化され、トラブルシューティング機能が向上し、コンプライアンス要件をより簡単に満たすことができます。コンテナ化されたアプリケーションの複雑さと規模が拡大し続けるにつれて、効率的なインフラストラクチャを維持するためにデュアル ログを実装することが重要になります。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。