すべてのDockerユーザーが

を知っておくべきトップ10Docker logging gotchas Dockerユーザーが”docker run”の後に学ぶ最初のコマンドの1つは”docker logs”ですが、”docker logs”コマンドが常に機能するとは それは驚くべきことに聞こえるかもしれませんが、それは本当です。 その理由については、後で詳しく説明します。

Dockerは、アプリケーションのデプロイ方法だけでなく、ログ管理のワークフローも変更しました。 ファイルにログを書き込む代わりに、コンテナはコンソール(stdout/stderr)にログを書き込み、Docker Loggingドライバはログを宛先に転送します。 Docker Githubの問題に対するチェックは、Dockerログを扱うときにユーザーがさまざまな問題を抱えていることをすぐに示します。

Docker Logging Drivers overview

Dockerを使用したログの管理は難しいようで、人々が報告する問題を克服するためには、Docker Logging Driverの実装と代替案についてのより深い知識が必 すべてのDockerユーザーが知っておくべきトップ10のDocker logging gotchasは何ですか?

まず、Dockerログドライバーの概要と、elastic Stack(旧ELK Stack)やSematext Cloudなどの集中型ログ管理ソリューションにログを出荷するためのオプションから始めましょう。

Dockerの初期の頃は、コンテナログはDocker remote API、つまり「docker logs」コマンドといくつかの高度なログ荷送人を介してのみ利用できました。 その後、Dockerはプラグインとしてログドライバーを導入し、さまざまなログ管理ツールとの統合のためにDockerを開きました。 これらのロギングドライバは、dockerデーモンのバイナリプラグインとして実装されています。 最近、プラグインアーキテクチャは、プラグインとして登録し、Linux FIFOファイルを介してログを取得することができ、外部プロセスとしてログギ 現在、dockerバイナリに同梱されているログドライバーはバイナリープラグインですが、近い将来変更される可能性があります。

Docker Loggingドライバはコンテナログを受信し、リモートの宛先またはファイルに転送します。 デフォルトのロギングドライバは”json-file”です。 コンテナログはローカルディスクにJSON形式で保存されます。 Dockerにはドライバをロギングするためのプラグインアーキテクチャがあるので、オープンソースのツールや商用ツール用のプラグインがあります:

  • Journald–コンテナログをシステムジャーナル
  • Syslogドライバに格納する–UDP、TCP、TLS
  • FluentdへのTCPまたはUnixソケット接続をサポートする
  • Splunk–SPLUNK serverへのHTTP/HTTPS転送
  • Gelf–GRAYLOG2へのUDPログ転送

、追加のツールが関与する必要があります:

  • ログを構造化するためのログパーサー、通常はログ荷送人の一部(fluentd,rsyslog,logstash,logagent,…)
  • ログのインデックス作成、視覚化、アラート: ElasticsearchとKibana(Elastic Stack、ELK stackとも呼ばれます)、
  • Splunk、
  • Logentries、
  • Loggly、
  • Sumologic、
  • Graylog OSS/Enterprise
  • Sematext Cloud/エンタープライズ
  • など多数…

バックエンドのいずれかにログを出荷するには、選択したログ管理ソリューションをサポートするログドライバーまたはログツールを選択する必要があ ツールにSyslog入力が必要な場合は、Syslogドライバを選択できます。

1.Docker logsコマンドはjson-file Logging driver

でのみ動作しますデフォルトのログドライバ”json-file”はローカルディスクにログを書き込み、json-fileドライバは”docker logs”コマンドと並行して動作する唯一のドライバです。 Syslog、Gelf、Splunkなどの代替ログドライバーを使用するとすぐに、Docker logs API呼び出しが失敗し始め、”docker logs”コマンドはコンソールにログを表示するのではなく、制限を報告 Docker logコマンドは失敗するだけでなく、PortainerのようなDockerユーザーインターフェイスやLogspoutのようなログコレクションコンテナなど、ログ用にDocker APIを使用する他の

この問題を参照してください。

Docker Syslogドライバは、Syslogサーバに到達できないときにコンテナの展開をブロックし、ログを失う可能性があります

TCPまたはTLSでDocker Syslogドライバを使用すると、ログを配信する信頼性の高い方法です。 ただし、Syslogログドライバーは、コンテナの起動時にSyslogサーバーへの確立されたTCP接続を必要とします。 コンテナの開始時にこの接続を確立できない場合、コンテナの開始は

のようなエラーメッセージで失敗します。docker:error response from daemon:failed to initialize logging driver:dial tcp

これは、一時的なネ さらに、Syslogサーバーを再起動すると、TCP/TS経由で中央のSyslogサーバーにログを記録するすべてのコンテナが破棄される可能性があります。

この問題を参照してください。

3. 宛先がダウンしたときにDocker syslogドライバがログを失う上記の問題と同様に、ログの損失を引き起こすのは、リモート宛先に配信できないときにDocker loggingドライバがディスク上のログをバッファリングする機能が欠落していることです。 ここで見るべき興味深い問題があります。

4. Dockerログドライバーは、error stack traces

のような複数行のログをサポートしていませんログについて話すとき、ほとんどの人は単純な単一行のログ、例えばNginxやApacheのログを考えています。 ただし、ログは複数行にまたがることもできます。 たとえば、例外トレースは通常複数行にまたがっているため、Logstashユーザーを支援するために、Logstashでスタックトレースを処理する方法を共有しました。

コンテナの世界では、コンテナで実行されているすべてのアプリからのログが同じ出力–stdoutに出力されるため、物事はさらに複雑になります。 第22920号が”クローズド”で終了したのも不思議ではありません。 気にしないで”非常に多くの人々を失望させた。 幸いなことに、Sematext Docker Agentのようなツールがあり、複数行のログをそのまま解析したり、カスタムの複数行パターンを適用したりすることができます。

非jsonログドライバでDocker service logsコマンドがハングする

json-filesドライバは堅牢に見えますが、他のログドライバは残念ながらDocker Swarmモードで問題を引き起こ このGitHubの問題を参照してください。

Fluentdデーモンがなくなり、バッファがいっぱいになるとDocker daemonがクラッシュする

リモート宛先に到達できないときにロギングドライバーがトラブルを引き起こ

DockerコンテナがSplunk driver failureでCreated状態になった

コンテナの開始時にSplunkサーバーが504を返した場合、コンテナは実際に開始されますが、dockerはコンテナの開始に失敗したと報告します。 この状態になると、コンテナはdocker psの下に表示されなくなり、コンテナプロセスはdocker killで停止することはできません。 プロセスを停止する唯一の方法は、手動で強制終了することです。

この問題を参照してください。

Docker logs skipping/missing application logs(journald driver)

この問題は、Dockerが実行中のすべてのアプリケーションのログを作成し、journaldがレート制限設定のためにいくつかのログをスキップする可能性があるため、Journaldレート制限が原因であることが判明しました。 Dockerに接続するときは、journald設定に注意してください。

Gelfドライバの問題

GELFログドライバにTCPまたはTLSオプションがありません。 いくつかの問題は、Gelfドライバを使用したDNS解決/キャッシュの問題を報告するため、GraylogサーバーのIPが変更されたときにログが”Nirvana”に送信される可能性があDockerは複数のログドライバをサポートしていません

ログをサーバーにローカルに保存し、リモートサーバーに出荷する可能性があると便利です。 現在、Dockerは複数のログドライバーをサポートしていないため、ユーザーは単一のログドライバーを選択する必要があります。 この記事に記載されているさまざまな問題を知っている簡単な決定ではありません。

それだ! これらは私のトップ10Docker Logging Gotchasです!

も参照してください:Jenkinsを使用した継続的な配信&Dockerセキュリティ:長所、短所、およびステータス更新

Docker Log Driversの代替

Docker Log Driversに関する非常に多くの問題 それは救助にDocker APIベースのログ荷主があることが判明しました!救助に。

ここでは、そのような選択肢を見るためのいくつかの良い理由があります:

  1. Json-fileドライバはデフォルトで信頼性があり、ログのローカルコピーは常に利用可能であり、ログの’docker logs’とDocker API呼び出しは機能します。
  2. イメージ名やラベルなどのさまざまな動的基準でログをフィルタリングする機能
  3. Docker APIへのフルアクセスを持つ優れたメタデータ
  4. そのようなログ バッファディレクトリをボリュームに入れ、有用な制限を設定する)

2つの推奨されるDocker APIベースのログ収集ツール、LogspoutとSematext Docker Agentを見てみましょう。 どちらもオープンソースです。

このカテゴリに多かれ少なかれ適合する第三のツールは、Elastic Filebeatですのでご注意ください。 Filebeatは、jsonファイルのログドライバーによって生成されたログファイルを収集し、コンテナメタデータの強化のみがDocker API呼び出しを介して行われます。

Logspoutは複数の出力を提供し、アプリケーションコンテナログ設定を変更せずに、異なるコンテナから異なる宛先にログをルーティングできます。 これはANSIエスケープシーケンス(ログ内のカラーコードなど)を処理しますが、Elasticsearchのフルテキスト検索では問題になる可能性があります。

Logspoutと同様に、Sematext Docker Agent(SDA)はAPIベースで、ログルーティングをサポートし、フルテキスト検索用のANSIエスケープシーケンスを処理します。 しかし、Sematext Docker Agentは、実際には単なるログシッパー以上のものです。

SDAは、複数行のログ、ログ形式の検出とログ解析、完全なメタデータ強化コンテナ(ラベル、geoip、Swarm、Kubernetes固有のメタデータ)、ディスクバッファリング、TLS経由の信頼性の高い出荷など、Dockerユーザーによって提起された多くの問題を処理します。 これはGithub上のオープンソースであり、elastic StackまたはSematext Cloudで使用でき、コンテナログだけでなく、コンテナイベント、Dockerホストとコンテナメトリックも収集できます。

json-fileドライバーとDocker Remote APIでうまく動作する三つのロギングソリューションの違い

勧告

APIベースのロガーに対する明確な勧告は、Dockerログドライバが時間の経過とともに改善され、Unixソケットを介した新しいプラグイン機構により、新しいロ この機能はDockers logging plugin architectureを本当に改善し、Dockerがロギングの問題を真剣に受け止めている良い兆候です。

その間、Sematext Docker AgentやLogspoutのようなDocker APIベースのログコレクターを検討して、ここで説明する10の落とし穴のようなDockerログの問題に遭遇しないようにしてくださ

コメントを残す

メールアドレスが公開されることはありません。