KubernetesのOpenTelemetryコレクターデプロイモード

OpenTelemetryコレクターを導入してKubernetesクラスタ内のテレメトリーを完全にカバーすることは、困難な作業となる場合があります。Kubernetes環境でコレクターに適切な設定を決定するには、技術的なノウハウだけでなく、オブザーバビリティのニーズとシステム内のデータフローについての深い理解も必要になるためです。

このプロセスを簡素化する良い方法は、「コレクターデプロイモード」、つまり、Kubernetes内でアプリケーションとシステムデータを収集、処理、エクスポートするためにコレクターを設定および管理するための、さまざまな方法に慣れることです。「デプロイモード」は「デプロイパターン」とは異なるため、混乱を招く可能性がある点に注意することが重要です。

このブログ記事では、これらの重要な概念について説明しており、オブザーバビリティ戦略に適したデプロイモードを選択するために必要な基礎知識を得ることができます。ここで取り上げる内容は次のとおりです。

• コレクターデプロイパターンとデプロイモードの違い
• コレクターデプロイモードが重要な理由
• Kubernetes環境で使用される最も一般的なコレクターデプロイモード

コレクターデプロイパターンとデプロイモードの比較

コレクターデプロイパターンは、コレクターを使用して（または使用せずに）全体的なテレメトリーの収集戦略を構築する方法に関する、大まかなアーキテクチャーアプローチを指します。

一般的に、主なパターンは次のとおりです。

• No Collector：テレメトリーをアプリケーションからバックエンドに直接送信します。このアプローチは、データ処理を必要としない小規模なアプリケーションやテスト目的に最適です。
• Agent：コレクターを導入する最も簡単な方法は、アプリケーションのテレメトリーをコレクターエージェントにルーティングします。エージェントは、データを1つ以上のバックエンドにエクスポートする前に、必要に応じて処理を行います。このパターンは通常、コレクターをアプリケーションと同じノードで実行するか、アプリケーションポッド内のサイドカーコンテナーとして実行する場合です。
• Gateway：このパターンでは、一元的な収集ポイントが作成されます。アプリケーションまたは他のコレクターは、スタンドアロンでありながら、スケーラブルなサービスとして実行されている1つ以上のコレクターインスタンスによってサポートされる、単一のOpenTelemetry Protocol（OTLP）エンドポイントにテレメトリーを送信します。
• Layered：このパターンは、コレクターの2つのレイヤーの設定を指します。通常、最初のレイヤーのコレクターはトレースID/サービス名を認識するロードバランシングエクスポーターを使用して設定され、コレクターの2番目のレイヤーでスケールアウトを処理します。テールサンプリングプロセッサとロードバランシングエクスポーターを使用する場合、このパターンはロードバランシングテールサンプリングスパンをサポートするため、同じトトレースIDを持つすべてのスパンが同じコレクターインスタンスに到達し、トレースの断片化が防止されます。

コレクターデプロイモードは、Kubernetes環境にこれらのパターンを実装するために使用する特定のKubernetesメカニズムを指します。これらは、Kubernetesでコレクターを実行する「方法」です。

• Deployment/StatefulSetsはスタンドアロンのコレクターポッドを実行します。
• DaemonSetでは、ノードごとに1つのコレクターポッドが確保されます。
• Sidecarは、アプリケーションコンテナと同じポッド内の隣接するコンテナでコレクターを実行します。

パターンとモードの違いを説明するために、エージェントパターンとゲートウェイパターンを戦略として組み合わせるとします。これをKubernetesで実装するには、クラスタ内で取り込まれているコレクターに対して次のモードを設定します。

• エージェントレベルのコレクター向けのDaemonSet
• ゲートウェイコレクター向けのDeployment

注：「Deployment」という名前のデプロイモードがあります。詳細については、この設定例を参照してください。

デプロイモードを考慮することが重要な理由

各モードには、システムの特定のニーズとアーキテクチャーに応じて、独自の利点とトレードオフがあります。さらに、先ほど説明したように、さまざまなユースケースに合わせてモードを組み合わせることができます。

次の点を考慮してください。

• 拡張性ニーズ：どれくらいの量のデータを処理すると予想されますか？これは、必要なコレクターインスタンスの数に影響します。
• パフォーマンス要件：低レイテンシのデータ収集と処理はどの程度重要ですか？
• 耐障害性と高可用性：高度な耐障害性と信頼性の高いデータ収集が最優先事項となる可能性が高いです。
• 運用の複雑さ：複数のインスタンスや設定を管理するチームの能力はどのくらいですか？また、詳細な設定オプションが必要ですか？
• リソースの使用率：どの程度の計算リソースとネットワークリソースを利用できますか？ネットワークの容量と構造は、コレクターインスタンスの拡張をサポートできますか？

考慮すべきもう1つの側面は、コレクターインスタンスが多数あるため、エージェントとして（SidecarまたはDaemonSetとして）コレクターを実行すると、リソースの観点からコストが高くなる可能性があることです。ただし、コレクターはアプリケーションと同じ物理ノード上で実行されているため、アプリからのテレメトリーのエクスポートは、コレクターが別のノードまたはクラスタの外部にある場合よりもはるかに高速です。さらに、これにより、バックエンドに到着する前に、ホストIDプロパティなどのコンテキスト情報をテレメトリーデータに追加することが容易になります。

Kubernetesのコレクターデプロイモード

Kubernetes環境では、コレクターに適用できる主なデプロイモードは、集中型コレクターの場合はDeployment、分散コレクターの場合はDaemonSetです。分散コレクターの場合、インスタンスは各Kubernetesノードで実行され、個々のホストからの収集が可能になります。特定のニーズに応じて、予測可能な名前を持つレプリカの数を制御するためにStatefulSetモードを使用することもできます。

Deploymentモード

コレクターをDeploymentモードでインストールすることは、通常、次のようなクラスタレベルのデータを収集するために使用します。

• Kubernetesイベントは、クラスタ内の問題のトラブルシューティングに役立ちます。
• コントロールプレーンメトリクスは、コントロールプレーンコンポーネントのパフォーマンスを可視化します。
• kube-state-metricsは、クラスタ内のさまざまなKubernetesオブジェクトの状態に関するメトリクスを提供します。

これらのデータソースはクラスタ全体を表すため、複数のコレクターインスタンスが同じエンドポイントから同じメトリクスを収集しようとする可能性があるため、DaemonSetモードでの使用は推奨していません。

ただし、Deploymentモードでは留意すべき点がいくつかあります。1つは、データを集中型コレクターに送信する必要があるため、ネットワークのオーバーヘッドとレイテンシが増加し、トラフィックが多い場合はボトルネックが発生する可能性があります。さらに、Deploymentモードコレクターをスケールするには、負荷分散も考慮する必要があり、複雑な設定が必要になる場合があります。コレクターをスケーリングしないと、単一障害点が発生し、コレクターが利用できなくなったり過負荷になったりした場合にデータが失われるリスクがあります。

こうした考慮事項により、チームは異なるモードで実行される複数のコレクターを実装することがよくあります。各コレクターは、これらの制限が特に影響を与える特定のユースケースに対応します。

DaemonSetモード

DaemonSetモードでは、コレクターはKubernetesクラスタ内のすべてのノードでポッドとして実行され、システムメトリクス、ローカルログ収集、ネットワーク監視などのインフラストラクチャパフォーマンスメトリクスの収集に最適です。アプリケーションのコンテキストでは、テレメトリーにノードローカルのエンドポイントを提供し、レイテンシとネットワークエラーの可能性を減らします。

次の図は、DaemonSetとしての導入済みコレクターのアーキテクチャーを示しています。

Kubernetesノードからメトリクスを収集するには、いくつかのオプションがあります。1つ目はホストメトリクスレシーバーで、CPU使用率、メモリ、ディスク入出力（I/O）などの重要なシステムメトリクスをノードから直接収集します。基本的なシステムメトリクスが必要な場合は、このコンポーネントを使用します。また、セットアップが簡単で、 OpenTelemetryではすぐに使用できます。このレシーバーの使用方法を示す、このリポジトリの例を確認することをお勧めします。

ノードからより広範なメトリクスを取得したい場合は、PrometheusレシーバーとPrometheusノードエクスポーターをペアにするという方法もあります。この組み合わせにより、ホストメトリクスレシーバーでは利用できないより高度なシステムメトリクスなど、300を超える一意のメトリクス名が提供されます。ただし、メトリクスの数が多いと、多大なコストが発生する可能性があります。

• 高いカーディナリティとデータストレージ：大量のメトリクスを管理すると、ストレージと処理のコストが増加する可能性があります。
• 運用の複雑さ：過剰で実用的でないデータが生成されないように、アラートとクエリを微調整する必要があります。

ワークロードメトリクスを収集するには、各ノードのKubernetes Kubeletからメトリクスを直接取得するKubelet Statsレシーバー を使用できます。これは、追加のツールを必要とせずに、Kubernetesコンテナを直接監視する効率的な方法です。コンテナのCPUやメモリの使用状況、ポッドレベルのリソース割り当てなど、便利なメトリクスを提供します。

あるいは、Prometheusレシーバーを利用して、 Kubernetes cAdvisor（コンテナレベルのメトリクス集約）などのソースからメトリクスを収集することもできます。これらのメトリクスは、既存のオブザーバビリティの設定で一般的に使用されます。

コレクターをDaemonSetとして導入する場合、ノードのファイルシステムに書き込まれるコンテナログをキャプチャするようにファイルログレシーバーを設定できます。ただし、アプリケーション開発者がすでにログをアプリからコレクターに直接送信している可能性があるため、アプリケーション開発者に相談する必要があります。

DeploymentとDaemonSetの主な違いは導入戦略にあります。標準のOpenTelemetryコレクターデプロイでは一元化されたスケーラブルな収集ポイントを提供しますが、DaemonSetコレクターはユビキタスなノードレベルのデータ収集を保証します。組織がこれらの導入パターンを組み合わせて使用し、サービスレベルとインフラストラクチャレベルのテレメトリーデータの両方を取得する、包括的なオブザーバビリティ戦略を作成しているのをよく見かけます。

StatefulSetモード

StatefulSetモードのコレクターは、永続ストレージまたは安定した一意のネットワークIDが必要なユースケースをサポートします。StatefulSetモードでコレクターを実行する最も一般的な使用例は次の2つです。

• 多数のPrometheusエンドポイントを含む大規模なKubernetesクラスタ：StatefulSetをターゲットアロケーターと組み合わせて使用すると、コレクターインスタンスのプール全体にPrometheusターゲットを均等に分散できます。
• 負荷分散とテールベースサンプリング： StatefulSetsは、ロードバランシングエクスポーターなどのプロセッサにデータの永続性と安定したホスト名が必要な場合に最適です。テールベースサンプリングを成功させるには、特定のトレースのすべてのスパンを同じコレクターインスタンスに送信する必要があります。

すべてを1つにまとめる

KubernetesでOpenTelemetryコレクターを設計する方法は数多くありますが、この例はより汎用的な「パターン」の1つであることがわかりました。KubernetesでOpenTelemetryを実装する場合、すべてのユースケースを満たすためにコレクターをレイヤー化またはチェーン化する必要がある場合があります。ほとんどの複雑なアーキテクチャーと同様に、考慮すべきさまざまな注意点や考慮事項がありますが、これが考えるための材料と確かな出発点となることを願っています。

Deployment

Deploymentコレクターはスタンドアロンで実行され、Kube Stateメトリクス、 Kubernetesイベント、 APIサーバーメトリクスなど、「クラスタ全体の」データを収集する役割を果たします。Deploymentでこのデータを収集することで、これらの設定をDaemonSetの一部として実行しようとした場合に発生する可能性のあるデータの重複を防ぐことができます。

DaemonSet

DaemonSetコレクターは、各ノード上でエージェントとして実行されます。Kubernetesノードメトリクス、KubeletおよびcAdvisorからのワークロードメトリクス、およびノードファイルシステムからのログを収集する役割を果たします。アプリケーションは、同じノードに共存するエージェントにトレースを送信することもできます。

Gateway

コレクターゲートウェイは、最終処理とデータ変換に使用され、データを複数のバックエンドに分散させる機能を備えています。これは、DeploymentまたはStatefulSetにすることができます。ロードバランサーは、既製のもの、またはロードバランシングエクスポーターを実行するコレクター（テールサンプリングのユースケースなど）のいずれかで、コレクターゲートウェイの前に配置され、テレメトリーがゲートウェイコレクターのインスタンス全体に均等に分散されるようにします。

追加で考慮すべき事項

各コレクターのデプロイモードには考慮すべき独自の長所と短所がありますが、コレクターを設計する際に考慮すべき追加の項目がいくつかあります。

• テナント：クラスタはシングルテナントですか、それともマルチテナントですか、これに基づいてデータはどこにどのようにルーティングされるのでしょうか？
• クラスタアーキテクチャー：ノードあたりのポッド数が多い少数の大型ノードを計画していますか、それともノードあたりのポッド数が少ない多数の小型ノードを計画していますか？
• データ出力と管理：データ管理を容易にするために、すべてのテレメトリーを各クラスタ内の単一のゲートウェイコレクター経由でルーティングしますか、それとも外部ゲートウェイコレクターでデータを処理しますか？

コレクターアーキテクチャーを構築してテストするときは、コレクター構成でOpenTelemetryコレクターの内部テレメトリー（「セルフメトリクス」とも呼ばれる）を有効にすることを強くお勧めします。これらのメトリクスは、コレクターのボトルネック、パフォーマンスの問題、またはパイプライン内で無意識にテレメトリーをドロップしている可能性がある状況を特定するのに非常に役立ちます。

次の図は、次のような主要なメトリクスの一部に焦点を当てた、New RelicのOpenTelemetryコレクターデータフローダッシュボードの例を示しています。

• 受け入れられたスパンと拒否されたスパン、メトリクス、ログ
• スパン、メトリクス、ログのエクスポートの失敗
• スパン、メトリクス、ログのエクスポート率
• エクスポーターのキューの容量とサイズ

まとめ

OpenTelemetryコレクターは、アプリケーションおよびKubernetes環境から監視テレメトリーを収集するための頼りになるツールになりました。これが幅広いタスクを処理できる多用途のベンダーニュートラルソリューションであることを考えると、それほど驚くべきことではありません。ただし、学習には少し時間がかかることは確かです。

コレクターを大規模に設定および管理するには、ある程度の計画が必要です。設定の基本をよく理解し、さまざまなデプロイモードを探索し、必要に応じてコレクターをチェーン接続する方法を理解することで、コレクターを使用してKubernetesオブザーバビリティを次のレベルに引き上げる準備が整います。

OpenTelemetryコレクターKubernetesディストリビューションを確認することもできます。これには、OpenTelemetryでKubernetesを監視するために一般的に使用するコンポーネントがバンドルされています。