Kubernetes ログ収集の一般的なルーチン。これを使えば間違いはありません。

1. 準備

1. コンテナログについて

Docker ログは、Docker エンジン ログとコンテナ ログの 2 つのカテゴリに分かれています。エンジン ログは通常、システム ログに配置されますが、オペレーティング システムによって配置場所が異なります。この記事では主にコンテナログについて紹介します。コンテナ ログは、コンテナ内で実行されているアプリケーションによって出力されるログとして理解できます。デフォルトでは、docker logs は、STOUT (標準出力) と STDERR (標準エラー出力) を含む、現在実行中のコンテナのログ情報を表示します。ログは json ファイル形式で /var/lib/docker/containers/<container id>/<container id>-json.log に保存されますが、この方法は実稼働環境には適していません。

デフォルトでは、コンテナ ログはログ ファイルのサイズを制限しません。コンテナはログの書き込みを継続するため、ディスクがいっぱいになり、システム アプリケーションに影響を及ぼします。 (docker log-driver はログファイルのローテーションをサポートします)

• Docker デーモンはコンテナの標準出力を収集します。ログの量が多すぎると、Docker Daemon がログ収集のボトルネックとなり、ログ収集の速度が制限されます。

• ログ ファイルのボリュームが大きすぎる場合、docker logs -f を使用して表示すると Docker デーモンがブロックされ、docker ps などのコマンドが応答しなくなります。

Docker はログ ドライバーの構成を提供します。ユーザーはニーズに応じてさまざまなログ ドライバーを構成できます。公式サイト（https://docs.docker.com/config/containers/logging/configure/）を参照してください。しかし、上記で設定したログ収集も Docker Daemon 経由で収集されるため、ログ収集の速度が依然としてボトルネックとなっています。

ログドライバーのログ収集速度。

syslog 14.9 MB/秒;

json ファイル 37.9 MB/秒

Docker Daemon を介してログを収集せずに、ログの内容をファイルにリダイレクトし、自動的にローテーションできるツールはありますか?答えは「はい」です。S6 ベースイメージを使用してください。

S6-log は、CMD の標準出力を Docker Daemon に送信する代わりに /.../default/current にリダイレクトし、Docker Daemon がログを収集する際のパフォーマンスのボトルネックを回避します。この記事では、S6 ベース イメージを使用してアプリケーション イメージを構築し、統合ログ収集ソリューションを形成します。

2. k8sログについて

k8s ログ収集ソリューションは、次の 3 つのレベルに分かれています。

1) アプリケーション（ポッド）レベル

ポッドレベルのログは、デフォルトでは標準出力とフラグ入力に出力されますが、これは実際には Docker コンテナのものと同じです。表示するには、kubectl logs pod-name -n namespace を使用します。詳細については、

2) ノードレベル

ノードレベルのログは、コンテナのログ ドライバーを構成することによって管理されます。これには logrotare の使用が必要です。ログが上限を超えた場合、自動的にローテーション操作が実行されます。

3) クラスターレベル

クラスター レベルのログ収集には 3 つの種類があります。

• ノードエージェントモード

ノード レベルでログを収集します。 DaemonSet は通常、各ノードにデプロイするために使用されます。この方法の利点は、ノードにデプロイするだけでアプリケーションに侵入することがないため、消費するリソースが少なくなることです。欠点は、コンテナ内のアプリケーション ログにのみ適しており、すべてのログが標準出力である必要があることです。

• サイドカーコンテナをコンテナログエージェントとして使用する

つまり、アプリケーション コンテナに続くポッドでログ処理コンテナが起動されます。 2つの形式があります。

1つは、アプリケーションコンテナのログを直接収集し、標準出力に出力する方法です（ストリーミングサイドカーコンテナと呼ばれます）。ただし、この時点では、ホスト上には実際には 2 つの同一のログ ファイルが存在することに注意してください。1 つはアプリケーション自体によって書き込まれたものです。もう 1 つは、サイドカーの stdout と stderr に対応する JSON ファイルです。これはディスク領域の大きな無駄なので、絶対に必要な場合、またはアプリケーション コンテナーをまったく変更できない場合にのみ使用する必要があります。

もう 1 つは、各ポッドでログ収集エージェント (logstash や fluebtd など) を起動することです。これは、ポッドのソリューション 1 にログ エージェントを配置することと同じです。ただし、このソリューションは多くのリソース (CPU、メモリ) を消費し、ログは標準出力に出力されないため、kubectl logs ではログの内容を確認できません。

• アプリケーションコンテナ内のストレージバックエンドにログを直接プッシュする

この方法は比較的単純で、ログの内容はアプリケーション内のログ収集サービス バックエンドに直接送信されます。

2. ログアーキテクチャ

上記の k8s ログ収集ソリューションの紹介を通じて、統合ログ収集システムを設計したい場合は、ノード エージェント方式を使用して各ノード上のコンテナーのログを収集できます。全体的なログ アーキテクチャを図に示します。

説明は次のとおりです。

• すべてのアプリケーション コンテナーは s6 ベース イメージに基づいており、コンテナー アプリケーション ログは、/data/logs/namespace/appname/podname/log/xxxx.log などのホスト マシン上のディレクトリ ファイルにリダイレクトされます。
• Log-agent には、filebeat や logrotate などのツールが含まれており、その中で filebeat はログ ファイルを収集するためのエージェントです。
• 収集されたログは、Filebeat を介して Kafka に送信されます。
• Kafka は、ログ送信用の es ログ ストレージ/kibana 取得レイヤーについて説明しています。
• Logstash は、主に ES にインデックスを作成し、Kafka メッセージを消費するために使用される中間ツールです。

プロセス全体は簡単に理解できますが、解決する必要があるのは次の点です。

• ユーザーが展開した新しいアプリケーションの Filebeat 構成を動的に更新する方法。
• 各ログ ファイルが正常にローテーションされていることを確認する方法。
• さらに多くの機能が必要な場合は、filebeat を再開発して、filebeat がより多くのカスタム構成をサポートできるようにする必要があります。

3. 実践する

上記の問題を解決するには、デーモンセットの形式で k8s クラスターの各ノードで実行されるログエージェント アプリケーションを開発する必要があります。アプリケーションには、開発が必要な filebeat、logrotate、および機能コンポーネントが含まれています。

最初の質問は、Filebeat 構成を動的に更新する方法です。 (https://github.com/fsnotify/fsnotify) ツールキットを使用して、ログ ディレクトリの変更の作成および削除イベントを監視し、テンプレート レンダリング メソッドを使用して Filebeat 構成ファイルを更新できます。

2 番目の質問については、(https://github.com/robfig/cron) ツールキットを使用して、ログ ファイルを定期的にローテーションする cronJob を作成します。アプリケーション ログ ファイルが属するユーザーに注意してください。ルートユーザーが所有していない場合は、設定でスイッチユーザーを設定できます。

 /var/ ログ/ xxxx / xxxxx 。 ログ{
 su www - データwww - データ
行方不明
空でない
サイズ1G ​
 コピー切り捨て
 }

3つ目に、Filebeatの二次開発については、ブログ投稿を参照してください: https://www.jianshu.com/p/fe3ac68f4a7a

IV.結論

この記事では、k8s ログ収集の簡単なアイデアのみを紹介します。ログ収集は企業のニーズに合わせてカスタマイズできます。