ログアーキテクチャの進化: 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 がリリースされてからまだ時間が経っていないため、以前のファイルビートと比較した安定性をテストするにはまだ時間が必要です。