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": "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}
If you can’t fix throttling by bumping limits on the backend or reducing amount of data sent through the Collector, you can avoid OOMs by reducing the sending queue of the failing exporter. For example, you can reduce sending_queue for the otlphttp exporter:
agent:
config:
exporters:
otlphttp:
sending_queue:
queue_size: 512
同じような設定を、他の失敗したエクスポーターにも適用できます。