Troubleshoot sizing for the Collector for Kubernetes 🔗
注釈
こちらも参照してください：
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": "sapm", "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": "sapm", "dropped_items": 1348}
バックエンドの制限を増やしたり、Collector 経由で送信されるデータ量を減らしたりしてもスロットリングを修正できない場合は、失敗したエクスポーターの送信キューを減らすことで OOM を回避できます。たとえば、sapm エクスポーターの sending_queue を減らすことができます：
agent:
config:
exporters:
sapm:
sending_queue:
queue_size: 512
同じような設定を、他の失敗したエクスポーターにも適用できます。