Dockerコンテナーは、軽量でポータブルな自己完結型のアプリケーション環境を作成するための優れた方法です。
ロギングは、トラブルシューティング、パフォーマンスの問題の評価、およびアーキテクチャの動作の全体像を描くための貴重な情報を提供するため、すべてのアプリケーションにとって重要です。
この記事では、Dockerロギングを開始するために知っておく必要のあるすべてを網羅した完全なチュートリアルを紹介します。 また、コンテナ化されたアプリのログを最適化するためのいくつかの推奨プラクティスも提供します。
内容
- Dockerコンテナとは何ですか？
- Dockerイメージとは何ですか？
- Dockerコンテナ化されたアプリケーションをログに記録することの重要性
- Dockerロギングが従来のロギングと異なるのはなぜですか？
- Dockerコンテナログ
- Dockerデーモンログ
- Dockerログの分析
- Dockerロギングのベストプラクティス
- まとめ
Dockerコンテナとは何ですか？
Dockerコンテナーは、コードとそのすべての依存関係をラップするソフトウェアの標準ユニットであるため、プログラムをある環境から別の環境に迅速かつ確実に移動できます。
LinuxおよびWindowsベースのアプリケーションで利用可能なコンテナ化されたソフトウェアは、インフラストラクチャに関係なく常に同じように実行されます。
コンテナーは、その環境からソフトウェアをカプセル化し、開発やステージングなどの環境間の違いにかかわらず、一貫して実行されるようにします。
Dockerコンテナテクノロジーがオープンソースとして導入されました ドッカーエンジン 2013インチ
Dockerイメージとは何ですか？
Dockerイメージは、コード、システムツール、システムライブラリ、設定など、アプリケーションの実行に必要なすべてのものを含む、軽量でスタンドアロンの実行可能ソフトウェアパッケージです。
つまり、イメージは読み取り専用のテンプレートであり、Dockerプラットフォームで動作できるコンテナーを構築するための手順が含まれています。 これは、他のDockerユーザーとプライベートまたはオープンに使用できるプログラムとプリセットサーバー環境をパッケージ化する簡単な方法を提供します。
Dockerコンテナ化されたアプリケーションをログに記録することの重要性
コンテナ化されたアプリケーションを開発する場合、ロギングは間違いなく最も重要な考慮事項のXNUMXつです。 ログ管理により、チームは問題をより迅速にデバッグおよび解決できるため、問題の発見、バグの発見、および問題が再発しないようにすることが容易になります。
ソフトウェアスタックがハードウェア中心のインフラストラクチャからDocker化されたマイクロサービスベースのプログラムに進化するにつれて、多くの変化がありましたが、XNUMXつの定数はロギングの重要性でした。
可用性、遅延、XNUMX秒あたりの障害など、いくつかの基本的なメトリックだけではうまくいきません。 これらは、単一ノードで動作し、デバッグをほとんど必要としない従来のプログラムに適していました。
Dockerを使用する場合は、根本的な原因を広範囲にわたって調査する必要があります。優れたユーザーエクスペリエンスを提供するには、問題の修正にかかる時間が不可欠です。
コンテナ化されたアプリケーションは、ログに記録して便利に統合する必要があります。 A ログ分析ツール 次に、ログメッセージを使用して、アプリケーション全体のイベントの全体像を作成できます。
Dockerロギングが従来のロギングと異なるのはなぜですか？
コンテナ化されたアプリのログ記録に関する主な課題は、さまざまなログストリームを作成することです。 これらは、複数の形式の構造化、非構造化、およびプレーンテキストメッセージである可能性があります。
大量のログ出力が一定であるため、コンテナログの維持と分析の複雑さが増します。
また、開発チームがログイベントを識別、監視、およびマッピングして、それらを生成する適切なコンテナを使用することは困難であり、ログ処理が非常に遅く複雑になります。
ほとんどの標準的なログ分析ツールはコンテナ化されたログでは機能せず、XNUMXつのノードで実行されるモノリスアプリケーションと比較すると、デバッグはより困難になります。
このような複雑さは、Dockerコンテナが提供するステートレスコンテナ化アーキテクチャによるものです。これには、次のXNUMXつの特徴があります。
1.Dockerコンテナは永続的ではありません
Dockerコンテナーは設計上永続的ではありません。つまり、コンテナーを停止して破棄することができます。 同じイメージから新しいイメージを構築し、最小限のセットアップと構成で迅速に展開できます。
上記は、コンテナが終了すると、保存されたログがすべて破棄されることも意味します。
ログが消えないようにするには、ログアグリゲーターを使用してログを収集し、永続的に利用できる場所に保存する必要があります。
ログが蓄積されてディスク領域を消費する可能性があるため、Dockerホストにログを保持することは危険です。 そのため、ログを一元化された場所またはデータボリュームに保存することが不可欠です。
2.Dockerコンテナはマルチレベルです
Dockerロギングには、少なくともXNUMXつのレベルの集約があります。 XNUMXつ目はDockerコンテナーからのログに関連し、XNUMXつ目はホストサーバーのログ（システムログまたは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構成ファイルのロギングドライバーの名前に設定します。
この例では、デフォルトのロギングドライバーをローカルドライバーに設定します。
{
「ログドライバー」：「ローカル」
}
もうXNUMXつのオプションは、コンテナーごとにドライバーを構成することです。 コンテナーを初期化するときに、–log-driverフラグを使用して、Dockerデーモンのデフォルトとは異なるロギングドライバーを指定できます。
以下のコードは、ローカルのDockerロギングドライバーを使用してAlpineコンテナーを起動します。
docker run -it –log-driverローカルアルパインアッシュ
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ロギング配信モードとは何ですか？
Dockerロギング配信モードは、コンテナーが他のタスクに対してロギングのバランスをとる、または優先する方法を指します。 使用可能なDockerロギング配信モードは、ブロッキングと非ブロッキングです。 選択したDockerロギングドライバーに関係なく、両方のオプションを適用できます。
ブロックモード
ブロッキングモードでは、メッセージをドライバーに配信する必要があるときはいつでもプログラムが中断されます。
ブロッキングモードの利点は、アプリケーションのパフォーマンスに遅れが生じる可能性がある場合でも、すべてのログがロギングドライバーに転送されることです。 この意味で、このモードはパフォーマンスよりもロギングを優先します。
選択したDockerロギングドライバーに応じて、アプリケーションのレイテンシーは異なる場合があります。 たとえば、ローカルファイルシステムに書き込むjson-fileドライバーは、ログを迅速に生成し、ブロックしたり、大幅な遅延を引き起こしたりする可能性はほとんどありません。
逆に、コンテナーがリモートの場所に接続する必要があるDockerロギングドライバーは、コンテナーを長期間ブロックする可能性があり、その結果、レイテンシーが増加します。
Dockerのデフォルトモードはブロッキングです。
いつブロッキングモードを使用しますか？
ほとんどの使用状況では、ブロッキングモードのjson-fileロギングドライバーをお勧めします。 前述のように、ドライバーはローカルファイルに書き込むため、高速です。 したがって、一般的に、ブロックして使用するのが安全です。
ブロッキングモードは、コンテナで使用可能なRAMの大部分を必要とするメモリを大量に消費するプログラムにも使用する必要があります。 その理由は、ネットワークの問題などの問題が原因でドライバーがエンドポイントにログを配信できない場合、非ブロッキングモードの場合、バッファーに使用できる十分なメモリがない可能性があるためです。
ノンブロッキング
非ブロッキングDockerログ配信モードは、ログを提供するためにプログラムを実行することを妨げません。 ログが宛先に送信されるのを待つ代わりに、コンテナはログをメモリ内のバッファに保存します。
非ブロッキングDockerログ配信モードが望ましいオプションのように見えますが、一部のログエントリが失われる可能性もあります。 ログが保存されるメモリバッファの容量には限りがあるため、いっぱいになる可能性があります。
さらに、コンテナが壊れた場合、バッファから解放される前にログが失われる可能性があります。
log-optsアイテムをdaemon.jsonファイルに追加することで、新しいコンテナーに対するDockerのデフォルトのブロックモードをオーバーライドできます。 上記のメモリバッファ容量を表すmax-buffer-sizeも、デフォルトの1MBから変更される場合があります。
{
「ログドライバー」：「ローカル」、
「log-opts」：{
「モード」：「ノンブロッキング」
}
}
また、単一のコンテナーで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プラットフォーム全体の状態を通知する必要があります。デーモンログは、マイクロサービスアーキテクチャ全体の概要を提供するため、そのために存在します。
コンテナが予期せずシャットダウンしたと想定します。 ログイベントをキャプチャする前にコンテナが終了するため、dockerlogsコマンドまたはアプリケーションベースのログフレームワークを使用して根本的な原因を特定することはできません。
代わりに、コンテナ名またはIDを含むイベントのデーモンログをフィルタリングし、タイムスタンプで並べ替えることができます。これにより、コンテナの発生から破壊までの寿命の時系列を確立できます。
デーモンログには、ホストのステータスに関する役立つ情報も含まれています。 ホストカーネルが特定の機能をサポートしていない場合、またはホストセットアップが最適でない場合、Dockerデーモンは初期化プロセス中にそれを記録します。
オペレーティングシステムの設定と使用するDockerログサブシステムによっては、ログが次のようになる場合があります。 多くの場所のXNUMXつに保管。 Linuxでは、journalctlレコードを確認できます。
sudojournalctl -xu docker.service
Dockerログの分析
ログデータは、使用する前に評価する必要があります。 ログデータを分析すると、干し草の山の中の針を探していることになります。
通常、数千行の通常のログエントリの中でエラーが発生したXNUMX行を探しています。 ログの実際の値を決定するには、堅固な分析プラットフォームが必要です。 ログ収集および分析ツールは重要です。 ここにいくつかのオプションがあります。
流暢
Fluentdは、Docker以外のサービスを含む完全なスタックをログに記録するための一般的なオープンソースソリューションです。 これは、データの収集と消費を統合して、データの使用率と理解を向上させることができるデータコレクターです。
ELK
ELKは、最も広く使用されているオープンソースのログデータ分析ソリューションです。 これは一連のツールです。 ElasticSearch ログデータを保存するため、 ログスタッシュ ログデータを処理するため、および 木場 グラフィカルユーザーインターフェイスを介してデータを表示するため。
ELKは、大規模な開発者コミュニティによって維持されている堅固なプラットフォームを提供し、無料であるため、Dockerログ分析の優れたソリューションです。
高度なログ分析ツール
オープンソースの代替手段では、スタックを個別に構築および管理する必要があります。これには、必要なリソースを割り当て、ツールへのアクセス性が高く、スケーラブルなインフラストラクチャに格納されていることを確認する必要があります。 また、かなりの量のITリソースが必要になる可能性があります。
ここで、より高度なログ分析プラットフォームが大きな利点を提供します。 たとえば、次のようなツール ログインテリジェンスと集約のためのLogicMonitorのSaaSプラットフォーム チームは、単一の統合されたクラウドベースのプラットフォームで、コンテキスト化され接続されたログとメトリックにすばやくアクセスできます。
これらの高度なテクノロジーは、機械学習の力を活用して、企業がトラブルシューティングを減らし、IT運用を合理化し、リスクを低減しながら制御を強化できるようにします。
Dockerロギングのベストプラクティス
Dockerロギングがどのように機能するかを理解したので、ロギングドライバーを最大限に活用して、特定のアプリケーションに最適なソリューションを調整できます。
以下は、Dockerロギングプロセスを最適化するために開発者が考慮すべき追加のベストプラクティスです。
データボリュームを使用する
記事で前述したように、コンテナは一時的なものです。 それらが正しく機能しない場合、コンテナ内に含まれるすべてのログデータとファイルが失われ、回復できません。
データボリューム（永続的または一般的に共有されるログイベントを格納するために使用されるコンテナー内の指定されたフォルダー）は、コンテナー内のデータが安全であることを確認するために開発者が使用する必要があります。
データボリュームを使用すると、他のコンテナとデータを簡単に共有でき、データが失われる可能性を減らすことができます。
この方法では、コンテナに何が起こったかに関係なく、長期データまたは共通共有データが保存されるホストシステム上のディレクトリを指すディレクトリをコンテナ内に作成します。 これで、他のコンテナからコピー、バックアップ、およびアクセスログを作成できます。
アプリケーションベースのロギングを使用する
アプリケーションベースのDockerロギングは、一般的なアプリケーションコンテキストで作業するチームにとって有利です。 これにより、開発者はログイベントをさらに制御できます。 この方法は、アプリケーションのフレームワークを使用してデータをログに記録して分析することで機能します。
アプリケーションベースのロギングには、ログをホストに転送するための追加機能は必要ありません。 代わりに、開発者はアプリケーションのフレームワークを介してロギング手順を処理できます。
専用のロギングコンテナを用意する
Dockerコンテナー内の専用のログコンテナーは、ログ管理に役立ちます。 ログを収集、監視、分析し、一元化された場所に送信します。
開発チームはログを処理し、ログイベントを迅速に管理およびスケーリングできます。 ログコンテナでは、このようなアクティビティを実行するためにセットアップコードをインストールする必要はありません。
このロギング手法により、ホスト間のコンテナー移行が簡素化され、新しいDockerロギングコンテナーを追加するだけでDockerロギングインフラストラクチャを拡張できます。 同時に、ログイベント、Docker APIデータ、および統計のいくつかのストリームを介してログを収集できるようになります。
サイドカー方式を使用する
サイドカーの使用は、より大規模で複雑な展開のためにマイクロサービスシステムをログに記録するための最も一般的な手法のXNUMXつです。
専用コンテナソリューションと同じようにDockerロギングコンテナを使用します。 今回の違いは、各アプリケーションコンテナには専用のコンテナがあり、プログラムごとにログソリューションを調整できることです。
最初のコンテナはログファイルをボリュームに保存し、次にファイルにラベルが付けられ、Dockerログコンテナによってサードパーティのログ管理システムに送信されます。
サイドカーを使用する主な利点のXNUMXつは、各ログにカスタムタグを追加して、その出所を簡単に識別できるようにすることです。
まとめ
Dockerコンテナー化により、開発者はアプリケーションとそのファイルシステムを単一のポータブルパッケージにカプセル化できますが、メンテナンスフリーにはほど遠いです。 Dockerロギングは、従来の手法よりも複雑です。 したがって、それを使用するチームはこれに注意する必要があります。
チームは、フルスタックの可視性、トラブルシューティング、パフォーマンスの強化、根本原因分析などを提供するために、Dockerログに精通している必要があります。
この投稿で見たように、Dockerには、ロギングを簡素化するためのロギングドライバーとコマンド、およびサードパーティのロギングツールとインターフェイスするパフォーマンスデータとプラグインを取得する方法が含まれています。 さまざまなアプローチと戦術が、Dockerロギングインフラストラクチャを構築してロギング機能を最適化するのに役立つ場合がありますが、それぞれに長所と短所があります。 包括的なログ分析に投資することをお勧めします コンテナモニタリング マイクロサービスとコンテナ化されたアプリケーションを完全に可視化するためのツール。