ログ記録は、パフォーマンスの非効率性やアーキテクチャ構造など、アプリケーションに関する貴重な洞察を得るために不可欠です。しかし、信頼性が高く、柔軟性があり、軽量なログ記録ソリューションを作成するのは簡単なことではありません。そこで Docker が役立ちます。
Docker コンテナは、軽量でポータブルな自己完結型のアプリケーション環境を作成するのに最適な方法です。また、IT チームは、あらゆる環境で実行できる一時的かつポータブルなログ ソリューションを作成することもできます。ログはパフォーマンスにとって非常に重要な側面であるため、トラブルシューティングや監査のために信頼性の高いログ管理を必要とする複雑なマルチ コンテナ セットアップでは、Docker デュアル ログがより効果的です。
Docker デュアルログ コンテナ ログを 2 つの異なる場所で同時にキャプチャできます。このアプローチにより、分散環境全体で一貫したログ データを維持することで、ログの冗長性、コンプライアンスの向上、オペレーティング システム (Windows、Linux など) の監視可能性の強化が保証されます。
このガイドでは、インフラストラクチャを最適化するための Docker デュアル ログ機能の実装に重点を置いて、Docker ログの基本について説明します。
主要な取り組み




Docker コンテナとは何ですか?
Dockerコンテナーは、コードとそのすべての依存関係をラップするソフトウェアの標準ユニットであるため、プログラムをある環境から別の環境に迅速かつ確実に移動できます。
LinuxおよびWindowsベースのアプリケーションで利用可能なコンテナ化されたソフトウェアは、インフラストラクチャに関係なく常に同じように実行されます。
コンテナーは、その環境からソフトウェアをカプセル化し、開発やステージングなどの環境間の違いにかかわらず、一貫して実行されるようにします。
Dockerコンテナテクノロジーがオープンソースとして導入されました ドッカーエンジン 2013インチ
Docker イメージとは何ですか?
Dockerイメージは、コード、システムツール、システムライブラリ、設定など、アプリケーションの実行に必要なすべてのものを含む、軽量でスタンドアロンの実行可能ソフトウェアパッケージです。
つまり、イメージは読み取り専用のテンプレートであり、Dockerプラットフォームで動作できるコンテナーを構築するための手順が含まれています。 これは、他のDockerユーザーとプライベートまたはオープンに使用できるプログラムとプリセットサーバー環境をパッケージ化する簡単な方法を提供します。
Docker ロギングとは何ですか?
Docker ログ記録とは、コンテナ化されたアプリケーションによって生成されたログをキャプチャして管理するプロセスを指します。ログはシステムの動作に関する重要な洞察を提供し、問題のトラブルシューティング、パフォーマンスの監視、アプリケーション ログの全体的な健全性の確保に役立ちます。
監視ソリューションと組み合わせることで、コンテナ化された環境の完全な可視性を維持できるため、問題をより迅速に解決し、信頼性を確保できます。他のデータ インサイトを使用して、履歴データを調べて傾向を見つけ、潜在的な問題を予測できます。
Docker ログは重要なシステム動作の洞察をキャプチャし、コンテナ化された環境でのトラブルシューティング、パフォーマンスの監視、アプリケーションの正常性の確保を可能にします。
Dockerコンテナログ
コンテナログとは何ですか?
Dockerコンテナログは、一言で言えば、実行中のコンテナのコンソール出力です。 特に、コンテナ内で実行されるstdoutストリームとstderrストリームを提供します。
前に述べたように、Dockerロギングは他の場所でのロギングと同じではありません。 Dockerのstdoutストリームとstderrストリームに書き込まれるものはすべて、暗黙的にドライバーに転送され、ログにアクセスしてファイルに書き込むことができます。
ログはコンソールでも表示できます。 Docker logsコマンドは、現在実行中のコンテナーから送信された情報を表示します。 docker service logsコマンドは、サービスのすべてのコンテナーメンバーによる情報を表示します。
Docker ロギング ドライバーとは何ですか?
Dockerロギングドライバーはコンテナーからデータを収集し、分析のためにアクセスできるようにします。
コンテナーの起動時に追加のログドライバーオプションが指定されていない場合、Dockerはデフォルトでjson-fileドライバーを使用します。 これに関するいくつかの重要な注意事項:
- デフォルトでは、ログローテーションは実行されません。 その結果、json-fileロギングドライバーを使用して保持されるログファイルは、大量の出力を生成するコンテナー用に大量のディスクスペースを消費する可能性があり、ディスクスペースの枯渇につながる可能性があります。
- Dockerは、json-fileロギングドライバーを(ログローテーションなしで)デフォルトとして保持し、古いバージョンのDockerとの下位互換性を維持します。 DockerはKubernetesランタイムとして使用されます.
- この ローカルドライバー ログを自動的にローテーションし、より効率的なファイル形式を利用するため、これが望ましいです。
Dockerには、さまざまなサービス(ログサービス、ログシッパー、ログシッパーなど)にログを送信するためのログドライバーも含まれています。 ログ分析プラットフォーム。 利用可能なDockerロギングドライバーはたくさんあります。 いくつかの例を以下に示します。
- syslog —アプリケーションとインフラストラクチャをログに記録するための長年にわたって広く使用されている標準。
- ジャーナル —Syslogの非構造化出力の構造化された代替。
- 流暢 —統合ログレイヤー用のオープンソースデータコレクター。
- awslog — AWSCloudWatchロギングドライバー。 AWSでアプリをホストする場合、これは素晴らしい選択です。
ただし、いくつかの代替ロギングドライバオプションがあります。 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 ash
docker infoコマンドは、Dockerデーモンの現在のデフォルトのロギングドライバーを提供します。
リモートロギングドライバーを使用したDockerログ
以前は、Docker logsコマンドは、ローカル、json-file、またはジャーナル化されたログドライバーを利用するコンテナーをサポートするログドライバーでのみ使用できました。 ただし、多くのサードパーティのDockerロギングドライバーは、Dockerログからローカルでログを読み取ることを有効にしませんでした。
ログデータを自動的かつ一貫して収集しようとすると、多くの問題が発生しました。 ログ情報は、サードパーティのソリューションで必要な形式でのみアクセスおよび表示できました。
Docker Engine 20.10以降では、Dockerログを使用して、有効になっているロギングドライバーまたはプラグインとは関係なくコンテナーログを読み取ることができます。
デュアルロギングでは、構成を変更する必要はありません。 選択したDockerロギングドライバーがログの読み取りをサポートしていない場合、Docker Engine20.10は後でデフォルトでダブルロギングを許可します。
Docker ログはどこに保存されますか?
Dockerは、コンテナーログをデフォルトの場所/ var / lib / docker /に保持します。 各コンテナには、そのID(一般的に表示される短いIDではなく完全なID)に固有のログがあり、次のようにアクセスできます。
/var/lib/docker/containers/ID/ID-json.log
docker run -it –log-driver local alpine ash
Docker ログ配信モードとは何ですか?
Dockerロギング配信モードは、コンテナーが他のタスクに対してロギングのバランスをとる、または優先する方法を指します。 使用可能な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 コンテナは、多くの場合異なる形式の複数のログ ストリームを生成するため、標準的なログ分析ツールの効果が低下し、単一の自己完結型アプリケーションと比較してデバッグが困難になります。
この複雑さの一因となっているのは、Docker コンテナの 2 つの重要な特性です。
- 一時コンテナ: Docker コンテナは短命に設計されているため、いつでも停止または破棄できます。この場合、コンテナ内に保存されているログはすべて失われます。データの損失を防ぐには、ログを収集して永続的な集中場所に保存するログ アグリゲータを使用することが重要です。集中ログ ソリューションを使用してログ データを集約し、データ ボリュームを使用してホスト デバイスに永続的なデータを保存できます。
- 複数のログ記録レイヤー: Docker ログには、個々のコンテナとホスト システムからのログ エントリが含まれます。これらのマルチレベル ログを管理するには、すべてのレベルとログ形式からデータを効果的に収集して分析し、重要な情報が漏れないようにできる特殊なツールが必要です。コンテナは大量のログ データを生成する場合もあり、従来のログ分析ツールでは膨大な量のデータを処理するのに苦労する可能性があります。
Docker デュアルログの理解
Docker デュアル ログでは、ログを 2 つの異なる場所に同時に送信します。このアプローチにより、ログ データが冗長的に保存され、データ損失のリスクが軽減され、分析用の複数のソースが提供されます。デュアル ログは、コンプライアンスと稼働時間が重要な環境で特に役立ちます。
Dockerデュアルログの利点
- 冗長性: デュアル ログにより、1 つのログ システムに障害が発生してもログ メッセージが保持され、サービス障害が発生した場合でもログが継続されます。
- 強化されたトラブルシューティング: ログが 2 か所で利用できるため、データを相互参照することで問題をより効果的に診断できます。
- コンプライアンス: 厳格なデータ保持および監査要件を持つ業界では、デュアル ログ記録により、複数のシステムにわたって信頼性の高いログ ストレージが提供され、これらの義務を満たすことができます。
デュアル ロギングは、複数のシステムにわたって重要なログ データを保持することにより、複雑なコンテナー化されたアプリケーションにセーフティ ネットを提供します。
Docker デュアルログの動作
Docker デュアル ロギングは、コンプライアンス、セキュリティ、システムの信頼性を向上させるために、さまざまな業界で広く実装されています。Docker デュアル ロギングを実装することで、データを保護し、規制要件を満たし、インフラストラクチャを最適化できます。以下は、組織がデュアル ロギングからどのようなメリットを得ているかを示す実際の例です。
- 電子商取引コンプライアンス: 世界的な電子商取引企業は、デュアル ログを使用してログ ファイルをローカルとクラウドの両方に保存し、規制コンプライアンス (GDPR や CCPA など) と監査への準備を確保することで、データ保持法に準拠しています。
- 金融機関のセキュリティ: 金融会社は、デュアル ログを使用して、ログを安全なオンプレミス システムとクラウド システムにルーティングし、疑わしいアクティビティを迅速に検出し、フォレンジック分析を支援し、データ損失を最小限に抑えることで、セキュリティを強化しています。
- SaaS の稼働時間と信頼性: SaaS プロバイダーは、デュアル ログ機能を活用してローカル サイトとリモート サイトのログを監視し、問題をより迅速に解決してダウンタイムを最小限に抑え、分散システム全体のデバッグを行って高いサービス可用性を確保します。
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プラットフォームは、デーモンのログを生成して保存します。 ホストのオペレーティングシステムに応じて、デーモンログはシステムのログサービスまたはログファイルに書き込まれます。
コンテナログのみを収集した場合は、サービスの状態に関する洞察を得ることができます。 一方、Dockerプラットフォーム全体の状態を通知する必要があります。デーモンログは、マイクロサービスアーキテクチャ全体の概要を提供するため、そのために存在します。
コンテナが予期せずシャットダウンしたと想定します。 ログイベントをキャプチャする前にコンテナが終了するため、dockerlogsコマンドまたはアプリケーションベースのログフレームワークを使用して根本的な原因を特定することはできません。
代わりに、コンテナ名またはIDを含むイベントのデーモンログをフィルタリングし、タイムスタンプで並べ替えることができます。これにより、コンテナの発生から破壊までの寿命の時系列を確立できます。
デーモンログには、ホストのステータスに関する役立つ情報も含まれています。 ホストカーネルが特定の機能をサポートしていない場合、またはホストセットアップが最適でない場合、Dockerデーモンは初期化プロセス中にそれを記録します。
オペレーティングシステムの設定と使用するDockerログサブシステムによっては、ログが次のようになる場合があります。 多くの場所のXNUMXつに保管。 Linuxでは、journalctlレコードを確認できます。
sudo journalctl -xu docker.service
Dockerログの分析
ログデータは、使用する前に評価する必要があります。 ログデータを分析すると、干し草の山の中の針を探していることになります。
通常、数千行の通常のログエントリの中でエラーが発生したXNUMX行を探しています。 ログの実際の値を決定するには、堅固な分析プラットフォームが必要です。 ログ収集および分析ツールは重要です。 ここにいくつかのオプションがあります。
流暢
Fluentdは、Docker以外のサービスを含む完全なスタックをログに記録するための一般的なオープンソースソリューションです。 これは、データの収集と消費を統合して、データの使用率と理解を向上させることができるデータコレクターです。
ELK
ELKは、最も広く使用されているオープンソースのログデータ分析ソリューションです。 これは一連のツールです。ElasticSearch ログデータを保存するため、 ログスタッシュ ログデータを処理するため、および 木場 グラフィカルユーザーインターフェイスを介してデータを表示するため。
ELKは、大規模な開発者コミュニティによって維持されている堅固なプラットフォームを提供し、無料であるため、Dockerログ分析の優れたソリューションです。
高度なログ分析ツール
オープンソースの代替手段では、スタックを個別に構築および管理する必要があります。これには、必要なリソースを割り当て、ツールへのアクセス性が高く、スケーラブルなインフラストラクチャに格納されていることを確認する必要があります。 また、かなりの量のITリソースが必要になる可能性があります。
ここで、より高度なログ分析プラットフォームが大きな利点を提供します。 たとえば、次のようなツール ログインテリジェンスと集約のためのLogicMonitorのSaaSプラットフォーム チームは、単一の統合されたクラウドベースのプラットフォームで、コンテキスト化され接続されたログとメトリックにすばやくアクセスできます。
これらの高度なテクノロジーは、機械学習の力を活用して、企業がトラブルシューティングを減らし、IT運用を合理化し、リスクを低減しながら制御を強化できるようにします。
Docker デュアルログのベストプラクティス
Docker デュアル ログには多くの利点があります。ただし、最大限に活用するには、信頼性の高いログ環境を構築するためのベスト プラクティスを実装する必要があります。まずは、以下のベスト プラクティスを使用してください。
- ログのパフォーマンスを監視します。 CPU 使用率やネットワーク帯域幅などのメトリックを収集して、コンテナーに対するデュアル ログのパフォーマンスへの影響を定期的に確認し、必要に応じて構成を調整します。
- ログのセキュリティを確保する: 暗号化と安全なアクセス制御を使用する ログの送信 遠隔地にアクセスし、制御が規制に準拠していることを確認します。
- ログ管理を自動化: デバイスからのログを管理、確認、アーカイブするための自動化プロセスを実装する ログの取り込み ストレージの問題を防ぐためです。
デュアルログ設定での Docker ログの分析
ログが 2 か所に保存されると、分析はより複雑になります。Fluentd や ELK などのログ集約ツールを使用して両方のソースからログを収集および分析すると、システムの動作を包括的に把握できます。この二重のアプローチにより、問題を迅速に検出して解決する能力が大幅に向上します。
Docker ログ ドライバーの概要
Docker はさまざまなログ ドライバーをサポートしており、それぞれが異なるユース ケースに適しています。デュアル ログを実装する際には、ドライバーを組み合わせて使用することで、環境全体で最良の結果を得ることができます。一般的なドライバーには次のものがあります。
- jsonファイル: ログをJSON形式でローカルファイルシステムに保存します
- 流暢に: ログをFluentdサービスに送信し、集中ログ記録に最適です。
- awsログ: ログをAWS CloudWatchに送信し、クラウドベースの監視に適しています。
- ゲルフ: GrayWatch および Logstash エンドポイントに Graylog 拡張ログ形式でログを送信します。
Docker デュアルログ用のツールと統合
Docker デュアル ログを最大限に活用するには、強力なログ管理ツールとの統合が不可欠です。これらの一般的なツールは、ログの集約、分析、視覚化のための高度な機能を提供することで、Docker デュアル ログを強化します。
- ELK スタック: Elasticsearch、Logstash、Kibana で構成されたオープンソース ソリューションで、ログ データの収集、検索、視覚化に最適です。
- Splunk: 大規模環境に適した包括的なログ分析とリアルタイム監視機能を提供するプラットフォーム。
- グレイログ: 集中ログ記録を可能にし、さまざまなデータ ソースをサポートする柔軟なオープン ソース ログ管理ツールです。
まとめ
Docker デュアル ログは、コンテナ化された環境で信頼性の高い冗長ログ管理を実現するための強力な戦略です。デュアル ログを実装すると、システムの回復力が強化され、トラブルシューティング機能が向上し、コンプライアンス要件をより簡単に満たすことができます。コンテナ化されたアプリケーションの複雑さと規模が拡大し続けるにつれて、効率的なインフラストラクチャを維持するためにデュアル ログを実装することが重要になります。
私たちのブログを購読する
このような記事をあなたの受信箱に直接お届けします