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

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

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

トレースを扱う場合は、毎秒15,000スパン。
メトリクススを扱う場合は、毎秒20,000データポイント。
ログを扱う場合、Fluentd td-agent を含めて、毎秒10,000件のログレコードがCollectorの fluentforward レシーバーにログを転送します。詳しくは Fluent Forward レシーバーを参照してください。

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

以下を推奨します：

CPU1個に対して2GBのメモリの割合で使用します。
Collectorがトレースとメトリクスの両方のデータを処理する場合は、導入を計画するときに両方のタイプのデータを考慮してください。たとえば、毎秒7.5Kスパンと毎秒10Kデータポイントを処理するには、1CPUコアが必要です。
Collector はデータをディスクに保存しないので、ディスク容量は必要ありません。

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

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

通常、1つのアプリケーションまたはホストにつき1つのエージェントしか実行されないため、エージェントのサイズを適切に設定することが重要です。
ユースケースに応じて、特定のアプリケーションやホストに複数の独立したエージェントをデプロイすることを検討します。例えば、特権エージェントを非特権エージェントと一緒にデプロイすることができます。

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

データ転送（ゲートウェイ）モードの場合は、Collector 1つにつき少なくとも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の内部メトリクスのリストは Collector の内部メトリクスを参照してください。

ここにいくつかのヒントがあります：

memory_limiter プロセッサーを使用している場合は、Collectot の otelcol_processor_refused_spans メトリクスを確認してください。データがパイプラインに入るのを拒否する頻度が高すぎる場合は、Collectorクラスターをスケールアップしてください。ノード全体のメモリ消費量がプロセッサーで設定された制限値よりも大幅に低くなってから、スケールダウンできます。プロセッサーについては、メモリリミッタープロセッサーを参照してください。
otelcol_exporter_queue_capacity や otelcol_exporter_queue_size のような、エクスポーターのキューサイズに関連する他の内部メトリクスをチェックしてください。ワーカーが十分でなかったり、バックエンドが遅すぎたりすると、スペースがなくなって拒否されるまでキューにデータが蓄積される可能性があります。

規模を拡大してもメリットがないこともあります：

テレメトリデータベースが負荷に追いつけない場合。otelcol_exporter_queue_size と otelcol_exporter_queue_capacity をチェックしてください：キューサイズがキュー容量に近い場合、データのエクスポートがデータの受信より遅くなります。
Collector とバックエンド間のネットワーク接続が飽和している場合。otelcol_exporter_send_failed_spans メトリクスが増加する場合は、バックエンドにデータが届いていません。

Collector のスケール 🔗

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

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

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

ステートレス・コンポーネントをスケールするには、新しいレプリカを追加し、ロードバランサーを使用します。信頼性を高めるために、コレクションパイプラインの分割を検討します。

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

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

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

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

スクレーパー 🔗

To scrape thousands of endpoints you can’t add more instances with the same configuration, as each Collector would try to scrape the same endpoints as every other Collector in the cluster.

解決策は、Collectorインスタンスごとにエンドポイントをシャーディングすることで、Collectorの別のレプリカを追加した場合、それぞれが異なるエンドポイントのセットで動作するようにすることです。各CollectorがそのCollectorに関連するエンドポイントのみを検出するように、各Collectorに対して1つの設定ファイルを持つことでこれを行うことができます。または、Target Allocatorを使用してPrometheusレシーバーをスケールすることもできます。

さらに詳しく 🔗

より詳しく学び、スケーリング例を見るには、https://opentelemetry.io/docs/collector/scaling/ にあるOpenTelemetryのドキュメントを読んでください。

このページは 2024年07月03日に最終更新されました。

Related Topics