サイジングとスケーリング

Splunk Distribution of OpenTelemetry Collector を環境に導入する場合は、以下のガイドラインに従ってください。以下のガイドラインを使用して、Collector のサイズが適切であることを確認します。

デフォルトでは、Collector は 512 MB (500 x 2^20バイト) のメモリを使用するように設定されています。

シングルCPUコアで、Collectorは以下をインジェストできます：

  • トレースを扱う場合は、毎秒15,000スパン。

  • メトリクススを扱う場合は、毎秒20,000データポイント。

  • ログを処理する場合、1 秒あたり 10,000 件のログレコード。

サイジングに関する推奨事項

以下を推奨します：

  • CPU1個に対して2GBのメモリの割合で使用します。

  • Collector がトレースとメトリクスの両方のデータを処理する場合は、デプロイメントを計画するときに両方のタイプのデータを考慮してください。たとえば、1 秒あたり 7.5K のスパンと 1 秒あたり 10K のデータポイントには、1 つの CPU コアが必要です。

  • Collector はデータをディスクに保存しないので、ディスク容量は必要ありません。

ホスト監視（エージェント）モード

ホスト監視（エージェント）モードの場合、必要に応じてリソースを割り当てます。

  • 通常、1つのアプリケーションまたはホストにつき1つのエージェントしか実行されないため、エージェントのサイズを適切に設定することが重要です。

  • ユースケースに応じて、特定のアプリケーションやホストに複数の独立したエージェントをデプロイすることを検討します。たとえば、特権エージェントは非特権エージェントとともにデプロイできます。

データ転送（ゲートウェイ）モード

データ転送（ゲートウェイ）モードの場合、Collector ごとに 1 つ以上の CPU コアを割り当てます。各 Collector は独立して実行されるため、デプロイする Collector の数に応じてスケールが直線的に増加します。

より高い可用性とパフォーマンスを得るために、ラウンドロビン ロードバランサの背後に複数の Collector をデプロイすることができます。均等にデータを分散するには、次の手順を実行します。

  • 少なくともN+1の冗長性を持つCollectorのクラスターをインストールします。つまり、ロードバランサと最低2つのCollectorインスタンスを初期構成する必要があります。

  • ラウンドロビンDNS名を定義します。

コンポーネントの制限

Collector 自体に制限はありませんが、一部の OTel コンポーネントには制限があります。

たとえば、Splunk HEC エクスポータを使用している場合、以下のデフォルト制限（その他）が適用されます。

  • 単一のログイベントの最大サイズ：5 MiB

  • ログイベントバッチの最大サイズ（圧縮）：2 MiB

注: Collector の設定で、各コンポーネントのデフォルト値、推奨事項、および制限事項を確認します。制限を設定できますが、標準的な動作環境ではデフォルト値を使用します。

スケーリングに関する推奨事項

アーキテクチャを定義し、拡張するには、ワークロードの動作を分析し、各信号タイプの負荷と形式、および負荷の時間的分布を理解する必要があります。

例えば、スクレイピングするPrometheusのエンドポイントが数百あり、fluentdインスタンスから毎分1テラバイトのログが来ていて、アプリケーションのメトリクスとOTLPのトレースがあるシナリオを考えてみます。

このシナリオでは：

  • Prometheusのレシーバーをスケーリングするには、どのスクレーパーがどのエンドポイントに行くかを決めるためにスクレーパー間の調整が必要なので、各シグナルを個別にスケーリングできるアーキテクチャーを設定します。

  • OTLPレシーバーはすべてのタイプのテレメトリを取り込むことができるので、アプリケーション・メトリクスとトレースは同じインスタンスに置くことができ、必要に応じて水平にスケールすることができます。

スケーリングする時期

注: Collector の内部メトリクスのリストについては、「Internal metrics of the Collector」を参照してください。

いくつかのヒントを以下に示します。

  • memory_limiter プロセッサを使用している場合は、Collector の otelcol_processor_refused_spans メトリクスを確認します。パイプラインへのデータの取り込みを頻繁に拒否されている場合は、Collector クラスターを拡張してください。ノード全体のメモリ消費がプロセッサによって設定された制限を大幅に下回った場合は、縮小できます。プロセッサについての詳細については、「Memory Limiter processor」を参照してください。

  • otelcol_exporter_queue_capacity や otelcol_exporter_queue_size など、エクスポータのキューサイズに関連する他の内部メトリクスを確認します。ワーカーが十分でなかったり、バックエンドが遅すぎたりすると、スペースがなくなって拒否されるまでキューにデータが蓄積される可能性があります。

以下の場合にはクラスターを拡張してもメリットがありません。

  • テレメトリデータベースが負荷に対応できない場合。otelcol_exporter_queue_size と otelcol_exporter_queue_capacity をチェックします。キューサイズがキュー容量に近い場合、データエクスポートがデータ受信より遅くなります。

  • Collector とバックエンド間のネットワーク接続が飽和している場合。otelcol_exporter_send_failed_spans メトリクスが増加すると、データはバックエンドに到達しません。

Collector のスケール

どのようにスケールするかは、Collectorコンポーネントがステートレスか、ステートフルか、スクレーパーかによって異なります。

ステートレス・コンポーネント

ほとんどのコンポーネントはステートレスのため、たとえメモリ上で状態を保持していたとしても、拡張の目的には関係しません。

ステートレスコンポーネントを拡張するには、新しいレプリカを追加して、ロードバランサを使用します。信頼性を高めるために、収集パイプラインの分割を検討してください。

ステートフル・コンポーネント

メモリにデータを保持している可能性のあるコンポーネントは、ステートフルと見なされます。ステートフルコンポーネントは、拡張時に異なる結果をもたらす可能性があるため、拡張前に慎重に検討する必要があります。

一般的なアプローチとして、load-balancing エクスポータを含む Collector のレイヤを、テールサンプリングまたはスパン/メトリクス処理を行う Collector の前に追加することを検討してください。ロードバランシング エクスポータは、トレース ID またはサービス名を一貫してハッシュし、トレースのスパンを受信する必要がある Collector のバックエンドを決定します。

load-balancing エクスポータを設定して、任意の DNS A エントリの背後にあるホストリストを使用できます。また、エクスポータが使用する静的ホストのリストを指定することもできます。

スクレーパー

各 Collector はクラスター内の他のすべての Collector と同じエンドポイントをスクレイピングしようとするため、同じ設定のインスタンスを追加して、何千ものエンドポイントをスクレイピングすることはできません。

解決策は、Collector の別のレプリカを追加する場合にそれぞれが異なるエンドポイントのセットに作用するように、Collector インスタンスによってエンドポイントをシャードすることです。これを行うには、Collector ごとに 1 つの構成ファイルを使用して、各 Collector がその Collector に関連するエンドポイントのみを検出するようにします。または、ターゲットアロケータを使用して、Prometheus レシーバーを拡張する方法もあります。

さらに詳しく

詳細と拡張例については、https://opentelemetry.io/docs/collector/scaling/ にある OpenTelemetry のドキュメントを参照してください。