ログアーキテクチャの進化: Kubernetes ログ戦略は集中型から分散型へ

アプリケーションをデプロイするためにクラウドネイティブ ソリューションを使用しない場合、使用するログ ソリューションは多くの場合、ELK テクノロジー スタックです。

この技術的ソリューションは比較的成熟しており、安定性も非常に高いため、当時の標準にほぼなりました。

しかし、Kubernetes を使用したクラウド ネイティブ時代に入ると、Kubernetes は以前のオペレーティング システムの多くの基礎レイヤーをブロックし、いくつかの標準インターフェースを提供します。

同時に、Kubernetes のログ ソースは、コンテナ、Kubernetes 独自のイベント、ログなど、従来の仮想マシンのものよりも多くなります。

当社のログ収集ソリューションも時代の変化に対応する必要があります。 Kubernetes の公式ブログでは、次のソリューションが提供されています。

ノードコレクション

最初の解決策は、ノードでログを収集することです。 Kubernetes はマスター スケジューリング ノードとワーカー作業ノードに分かれていることはわかっています。アプリケーションはすべてワーカーノードで実行されています。

Kubernetes 環境では、Kubernetes がより簡単かつ統一された処理を実行できるように、ログ出力として標準の stdout/stderr を使用することをお勧めします。

Docker ランタイムを例にとると、デフォルトでは標準入力ファイルは /var/log ディレクトリに書き込まれます。

上図に示すように、Kubernetes の各ワーカーノードに DaemonSet タイプのコレクター (filebeat など) をデプロイし、ノード下の /var/log にログを収集させ、収集したログを elasticsearch などのコンポーネントなどのログ処理のバックエンドに送信できます。

このソリューションの利点は、使用するリソースが少なく、ワーカーノードの数だけコレクターをデプロイできることです。

また、業務との結合度が低く、業務とコレクターのどちらを再起動またはアップグレードしても、お互いに影響を与えることはありません。

しかし、欠点も明らかです。ノード全体のログ収集のボトルネックはこのコレクターにあります。一部のワーカーノード上の Pod 数が不均衡であったり、ログ生成自体が不均一であったりすると、明らかな負債の不均衡が生じます。

また、特定のログ ピーク シナリオに合わせて調整することも不可能です (結局のところ、すべての Pod は同じログ コレクターを使用します)。

したがって、ノード レベルのログ収集は、ワーカー ノードの負債が少なく、保守が容易な場合に適しています。

サイドカープロキシパターン

最初のタイプと比較すると、2 番目のタイプは、集中ログ収集から各アプリケーション Pod への自己収集への分散ログ収集として理解できます。

ログ収集のために、各ビジネス ポッドにサイドカーを搭載する必要があります。サイドカーとビジネス ポッドは同じストレージを共有するため、ログを簡単に読み取ることができます。

アプリケーションと一緒にマウントされるため、リソース使用量は当然ノードコレクションより多くなります。同様に結合度も増加します。コレクション コンポーネントのアップグレードは、ビジネス ポッドにも影響する可能性があります。

ただし、同じ利点として、単一の Pod の収集計画をより細かく制御できるという点があります。

たとえば、ログを頻繁に書き込むアプリケーションの場合、Filebeat の構成を改善し、そのような高負荷のログを Elasticsearch に別途書き込むことで、リソースを通常の負荷のログから分離することもできます。

このソリューションは、クラスター サイズが大きいシナリオに適しており、きめ細かい構成が必要です。

実際に私たちもこのソリューションを採用しましたが、具体的な内容は少し異なります。

以下の理由により、標準入力と出力を直接使用しません。

ログ形式を統一できないため、クエリ時に標準化された制限を設けることができません (たとえば、各ログにビジネス ID、traceId などが含まれている必要があります。クエリ時に、これらのビジネス インジケーターを使用していくつかの標準クエリ ステートメントを蓄積するのは簡単です)。

結局、私たちは Java の古い友人である logback を使い続け、独自のログ形式を設定しました。すべてのアプリケーションはこのテンプレートに従ってログを出力します。

同時に、ログ フレームワークのバッチ書き込み機能とバッファリング機能により、ログのパフォーマンスの調整が容易になります。 (標準出力のみを使用すると、アプリケーションにとってブラックボックスになります。)

私たちの最終的な技術的解決策は次のとおりです。

直接書き込み

もう 1 つの解決策は直接書き込むことですが、これは実際には Kubernetes 自体とはほとんど関係がありません。

ビジネス自体が elasticsearch やその他のストレージ コンポーネントの API を呼び出してデータを書き込みます。この方法は通常、パフォーマンス要件が高いシナリオに適しています。中間の収集ステップをスキップし、ストレージの端に直接書き込みます。

私はこれを VictoriaLogs: 超低占有率 ElasticSearch の代替として紹介しました。メッセージ リンク情報を生成できるように、ブローカーのインターセプターにいくつかのメッセージ情報を埋め込む必要があります。

メッセージの送信と消費の各段階をインターセプトする必要があり、同時実行の圧力が比較的高いため、ログ書き込みパフォーマンスに対する要件は依然としてかなり高くなります。

そのため、インターセプター内のログストレージに直接書き込む必要があります。

私のシナリオとリソースの消費を考慮して、最終的に私は  victoriaLog  このログは保存されます。

ログを送信する場合は、高性能なログ生成フレームワークを使用する必要があります。ここでは、aliyun-log-java-producer が選択され、いくつかのカスタマイズが行われます。

このライブラリは次の機能をサポートしています。

• 高性能: バッチ送信、マルチスレッドなど
• 自動再試行
• 非同期非ブロッキング
• リソース制御（メモリと量を制御可能）

これは Alibaba Cloud Log Service のコンポーネントであるため、コードは Alibaba のログ サービスにのみ書き込むようにハードコードされています。

したがって、少し変更するだけで、任意のバックエンドへのカスタム送信をサポートできるようになりました。初期化中に送信コールバック インターフェイスをカスタマイズするだけで済みます。

 ProducerConfig producerConfig = new ProducerConfig(); producerConfig.setSenderArgs(new Object[]{vlogUrl, client}); producerConfig.setSender((batch, args) -> { StringBuilder body = new StringBuilder(); for (String s : batch.getLogItemsString()) { body.append("{\"create\":{}}"); body.append("\n"); body.append(s); body.append("\n"); } RequestBody requestBody = RequestBody.create(MediaType.parse("application/json"), body.toString()); Request request = new Request.Builder() .url(String.format("%s/insert/elasticsearch/_bulk", args[0])) .post(requestBody) .build(); OkHttpClient okHttpClient = (OkHttpClient) args[1]; try (Response response = okHttpClient.newCall(request).execute()) { if (response.isSuccessful()) { } else { log.error("Request failed with error code: " + response); } } catch (IOException e) { log.error("Send vlogs failed", e); throw e; } }); logProducer = new LogProducer(producerConfig);

このライブラリは Alibaba Cloud Log Service の単なるコンポーネントであり、コードは長期間メンテナンスされていないため、この部分のコードはコミュニティに送信されていません。ご興味がございましたら、コメント欄にメッセージを残してください。

ログセキュリティ

ログ記録は非常に基本的ですが、繊細な機能です。まず、コーディング標準では、ID カードやパスワードなどの機密情報を印刷しないようにする必要があります。同時に、ログへのアクセスも権限制御の対象となる必要があります。

当社の社内研究開発プラットフォームでは、ログ記録や監視などの機能がアプリケーションの権限にリンクされています。

簡単に言えば、ES の統合クエリ エントリは閉じられており、クエリは次のようにアプリケーション レベルでのみ提供されます。

写真はオービットプロダクトより。

オープンテレメトリー

もちろん、ログに関しては、OpenTelemetry は当然避けられません。クラウド ネイティブの可観測性の現在の標準として、対応するログ コンポーネントも提供します。

OpenTelemetry は構造化されたログ形式も定義します。

 {"resourceLogs":[{"resource":{"attributes":[{"key":"resource-attr","value":{"stringValue":"resource-attr-val-1"}}]},"scopeLogs":[{"scope":{},"logRecords":[{"timeUnixNano":"1581452773000000789","severityNumber":9,"severityText":"Info""body":{"stringValue":"This is a log message"},"attributes":[{"key":"app","value":{"stringValue":"server"}},{"key":"instance_num","value":{"intValue":"1"}}],"droppedAttributesCount":1,"traceId":"08040201000000000000000000000000","spanId":"0102040800000000"},{"timeUnixNano":"1581452773000000789","severityNumber":9,"severityText":"Info","body":{"stringValue":"something happened"},"attributes":[{"key":"customer","value":{"stringValue":"acme"}},{"key":"env","value":{"stringValue":"dev"}}],"droppedAttributesCount":1,"traceId":"","spanId":""}]}]}]}

otel.logs.exporter=otlp (デフォルト) を設定すると、ログが oetl-collector にエクスポートされ、バックエンド ストレージにエクスポートされます。

otel-collector がボトルネックになりますが、複数のレプリカを展開して負荷を軽減することもできます。

また、アプリケーションで異なるエンドポイント (otel.exporter.otlp.endpoint=http://127.0.0.1:4317) を指定して、ログ コレクターを区別し、リソースを他のタイプのコレクターから分離することもできます。

ただし、ログに関するコミュニティの実践はまだ比較的少なく、バージョン 1.0 がリリースされてからまだ時間が経っていないため、以前のファイルビートと比較した安定性をテストするにはまだ時間が必要です。

要約する

理想的には、問題のトラブルシューティングと特定を改善するために、可観測性の 3 つの重要なコンポーネントをリンクする必要があります。

たとえば、インジケーターの変化を通じて監視システムからアラームを受信した場合、リンク トラッキングを使用して、どのシステムが問題を引き起こしたかを特定できます。

次に、traceID を通じて特定のログが特定され、ログ コンテキストを通じてさらに多くのログ情報がリストされるため、チェーン全体を直列に接続することができ、効率が大幅に向上します。

参考リンク:

• https://github.com/aliyun/aliyun-log-java-Producer。
• https://kubernetes.io/docs/concepts/cluster-administration/logging/。
• https://coding.net/help/docs/orbit/env/logs-event/intro.html。
• https://opentelemetry.io/docs/concepts/signals/logs/。