Collector インスタンスのサイズ設定

処理するデータ量に基づいて、Collector インスタンスに割り当てるリソースを設定します。詳細については「サイジングとスケーリング」を参照してください。

以下の設定を使用して、エージェントにリソース制限をかけます：

agent:
  resources:
    limits:
      cpu: 500m
      memory: 1Gi

クラスターサイズに基づいて、クラスターレシーバのデプロイメントに割り当てるリソースを設定します。たとえば、100 ノードのクラスターの場合は、次のリソースを割り当てます。

clusterReceiver:
  resources:
    limits:
      cpu: 1
      memory: 2Gi

コンテナのメモリ不足を確認する

Collector コンテナに十分なリソースを提供しなかった場合でも、通常の状況では Collector のメモリ不足（OOM）は発生しません。これは、Collector がバックエンドによって大幅にスロットルされ、Collector がメモリの使用を制御できるよりも速くエクスポータの送信キューが増加する場合にのみ発生します。その場合、メトリクスとトレースの 429 エラー、またはログの 503 エラーが表示されます。

例：

2021-11-12T00:22:32.172Z      info    exporterhelper/queued_retry.go:325      Exporting failed. Will retry the request after interval.        {"kind": "exporter", "name": "otlphttp", "error": "server responded with 429", "interval": "4.4850027s"}
2021-11-12T00:22:38.087Z      error   exporterhelper/queued_retry.go:190      Dropping data because sending_queue is full. Try increasing queue_size. {"kind": "exporter", "name": "otlphttp", "dropped_items": 1348}

バックエンドの制限を増やしたり、Collector 経由で送信されるデータ量を減らしたりしてもスロットリングを修正できない場合は、失敗したエクスポータの送信キューを減らすことで OOM を回避できます。たとえば、otlphttpエクスポータの sending_queue を減らすことができます。

agent:
  config:
    exporters:
      otlphttp:
        sending_queue:
          queue_size: 512

同じような設定を、他の失敗したエクスポーターにも適用できます。