Dockerで複数のログストリームを使用する方法

アクセスログ、汎用アプリケーションログ、システムログの3つのタイプのログを3つの個別のファイルに書き込むアプリケーションがあります。これらのログの形式（および目的）は大きく異なります。また、集中ログシステムに個別に送信する個別のログフォワーダーがあります。

ログをイベントストリームとして扱うという原則に基づいて、ファイルの使用から標準出力への移行を検討しています。このアプローチの利点の一部はわかっていますが、これはまた、異なる形式のログのマージされたストリームを取得することを意味し、中央システムに送信する前に再度分割する必要があります（Kibana / Splunk /など）、またはその中。

この状況にどのように取り組むべきかについてのツールや推奨事項があるかどうか疑問に思っています。

docker logging

— SztupY
ソース

価値があるとは思わない。何らかの「原理」のためだけに、ログストリームをマージしてから分割するのに一生懸命なのはなぜですか。ファイルは良いです。ファイルは機能します。これは過剰に設計されているように聞こえます。たぶん、すべてのログを異なるタグなどでsyslogにパイプするかもしれませんが、私のチームの誰かがこれを提案した場合、私は言わなければなりません。

— アサフラビー

ファイルを使用すると、特にドッカーコンテナ内から生成された場合、他の種類の管理上の悪夢があるためです。現時点では、stdoutに切り替えることのデメリットがユースケースのメリットを上回っているように見えますが、ファイルベースのアプローチでは既に問題が発生しています

— -SztupY

「悪夢」については知りません。私はこれが彼らが今しばらくの間行われている方法であることを知っています、そしてあなたがこれを行うのを助ける多くのソフトウェアがそこにあります。ログファイルはチェックポイントで読み取られ、回転されます-ファイルはこのための優れた抽象化です。古い、馴染みのあるパターンに対する恐怖のために、私に新しい悪夢を売る原則を購入しません。ログレコードはファイルに書き込まれるか、メモリ内で処理されます（少なくともコンテナ内で移動されている限り）。インメモリストリームスプリッターと合併によりログファイルの信頼性を達成できました。

— アサフラビー

@AssafLavie賛成になる答えでそれを書くべきです。私見それは完全に有効な視点です。

— ダンコルニレスク

私は同じ質問でここに来ました。単純な事実は、Dockerの組み込みロギング機能がstdout / stderrに向かうすべてに依存しているため、ロギングドライバーとその周りに構築されたサードパーティツールのエコシステムも同様です。私もすべてのログをホストボリュームにダンプしたいと思っていますが、コンテナがk8sまたはopenshiftまたはgkeなどに移動したときに戻って管理し続けなければならないことを知っていますが、ドッカーに従う場合stdoutアプローチでは、はるかにスムーズになります。その間、この合法的な質問への答えを探し続けます

— ルバーブ

回答:

私はまだ自分でマージ/分割のアプローチを探していますが、Kubernetesのドキュメントで推奨されているこのアプローチは健全な解決策のようです：個別のログごとにサイドカーコンテナを使用してください。

「サイドカー」は、何らかの方法で作業するために別のドッカーコンテナと一緒に使用するドッカーコンテナです。この場合、3つのログのそれぞれに対して、ログをスキャンまたはテールし、stdoutに出力する個別のコンテナーがあります。

このようにして、各log-sidecar-containersには、独自のstdoutから独自のdocker-logがあります。このように分離することで、標準のdocker（およびkubernetesなど）プラクティスを使用して分離または集約できます。Kubernetesページの内容は次のとおりです。

このアプローチにより、アプリケーションのさまざまな部分からいくつかのログストリームを分離することができます。その一部は、stdoutまたはstderrへの書き込みのサポートを欠く可能性があります。ログのリダイレクトの背後にあるロジックは最小限であるため、それほど大きなオーバーヘッドにはなりません。さらに、stdoutとstderrはkubeletによって処理されるため、kubectlログなどの組み込みツールを使用できます。

「個別のログストリーム」は、Dockerがさまざまなコンテナからのログに適用する組み込みのタグ付けに由来します。これについては、Dockerのドキュメントをご覧ください。

タグログオプションは、コンテナのログメッセージを識別するタグのフォーマット方法を指定します。デフォルトでは、システムはコンテナIDの最初の12文字を使用します。この動作をオーバーライドするには、タグオプションを指定します

— ダイオウ
ソース

このlog-sidecar-containersアプローチのマイナス面に言及する価値があります：「CPUとメモリの使用率が低いにもかかわらず、ログをファイルに書き込んでからstdoutにストリーミングするとディスク使用率が2倍になることに注意してください」誰もが実際にこのアプローチを試みているのだろうか。

— ユソン

それらを後で分割するためだけに1つのストリームにマージするという考えは、痛いように聞こえます。これを自分で行う理由はありませんでしたが、ここから始めます。

Dockerコンテナを実行するときに、ホストからログを簡単に表示/配布できるようにボリュームを作成します。
remote_syslog2などを使用して、ログをログコレクターに送信します。

ホスト上で何らかのセットアップを行う必要があるのは少し優雅ではありませんが、プレイブックを実行し、ボックスへのデプロイ中にそれをセットアップできるansibleのようなものを使用する場合、それはあまりすべきではありません悪い。

— ブラディム
ソース

このソリューションは、名前付きパイプと組み合わせることができます。名前付きパイプの唯一の問題は、現在すべてのシステムで動作しないことです。Mac

— Jens