メモリリミッタープロセッサー 🔗
Memory Limiter プロセッサーは、Splunk Distribution of OpenTelemetry Collector でのメモリ不足の状況を防ぎます。サポートされているパイプラインタイプは traces 、metrics 、logs です。詳細は パイプラインでデータを処理する を参照してください。
はじめに 🔗
注釈
このコンポーネントは、ホスト監視 (エージェント) モードでデプロイする場合、Splunk Distribution of the OpenTelemetry Collector のデフォルト設定に含まれます。詳細は Collector のデプロイモード を参照してください。
デフォルト設定の詳細については、Helmで Collector for Kubernetes を設定する、Collector for Linux のデフォルト設定、または Collector for Windows のデフォルト設定 を参照してください。この文書で説明されているように、いつでも設定をカスタマイズすることができます。
以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください：
Splunk Distribution of OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします：
次のセクションで説明するように、
memory_limiterプロセッサーを設定します。Collector を再起動します。
サンプル構成 🔗
リソースプロセッサーを有効にするには、設定ファイルの processors セクションに memory_limiter を追加します。
パイプラインの最初のプロセッサーとして、レシーバーの直後に memory_limiter を定義します。これは、バックプレッシャーが該当するレシーバーに送られるようにするためであり、また、memory_limiter がトリガーされたときにデータがドロップされる可能性を最小限にするためです。
memory_limiter プロセッサーと共に、すべての Collector で Ballast エクステンションを構成することを強くお勧めします。バラストは Collector に割り当てられたメモリの1/3から1/2になるように設定する必要があります。
次の例を参照してください：
processors:
memory_limiter:
check_interval: 1s
limit_mib: 4000
spike_limit_mib: 800
コンフィギュレーションを完了するには、コンフィギュレーションファイルの service セクションの任意のパイプラインにプロセッサーを含めます。例：
service:
pipelines:
metrics:
processors: [memory_limiter]
logs:
processors: [memory_limiter]
traces:
processors: [memory_limiter]
メモリ使用量の制御 🔗
Collectorが処理するデータの量と種類は環境に固有であり、Collectorが使用するリソースも構成されたプロセッサーに依存することを考えると、メモリ使用量に関するチェックを設置することが重要です。
注意
プロセッサーはメモリ不足の状況を緩和するのに役立つが、Collector の適切なサイズと構成に取って代わるものではありません。
ソフトリミットを超えた場合、Collector は十分なメモリが解放されるまで、すべての受信操作に対してエラーを返します。これは、レシーバーがデータを保留して無期限に再試行できない可能性があるため、データのドロップにつながる可能性があります。
パイプラインのメモリリミッターの前のコンポーネントが正しくデータを再試行し送信しなければ、そのデータは永久に失われます。
ソフトおよびハードメモリ制限を定義する 🔗
memory_limiter プロセッサーは、メモリ使用量を定期的にチェックすることができます。定義された制限を超えると、データを拒否し始め、メモリ消費を強制的に削減します。
memory_limiter では、ソフトとハードのメモリ制限を使用します：
ハード・リミットは常にソフト・リミットを上回るか等しくなります。
メモリ使用量がソフトリミットを超えると、プロセッサーはメモリ制限モードに入り、ConsumeLogs/Trace/Metrics関数コールを行ったパイプラインの先行コンポーネントにエラーを返すことで、データの拒否を開始します。先行コンポーネントはレシーバーでなければなりません。
メモリ使用量がハードリミットを超えると、データを拒否するだけでなく、プロセッサーは強制的にガベージコレクションを実行し、メモリの解放を試みます。
メモリ使用量がソフトリミット以下になると、通常の動作が再開され、データが拒否されることはなくなり、強制的なガベージコレクションも行われません。
ソフトリミットとハードリミットの差は、spike_limit_mib 設定オプションで定義します。メモリ・チェックの間隔がこの値を超えてメモリ使用量が増加しないような値を選択してください。そのようにしない場合、メモリ使用量がハードリミットを超える可能性があります。詳しくは 設定オプション を参照してください。
設定オプション 🔗
プロセッサーには以下のコンフィギュレーション・オプションがあります：
check_interval:メモリ使用量の測定間隔。推奨値は1秒。デフォルトでは0です。Collector への予想トラフィックが非常に急増する場合は、
check_intervalを減らすか、spike_limit_mibを増やして、メモリ使用量がハードリミットを超えないようにしてください。
limit_mib: プロセスヒープで割り当てられるメモリの最大量（MiB）。これは、ハードリミットを定義します。デフォルトでは0です。通常、プロセスの総メモリ使用量は、この値より50MiBほど多くなります。
limit_percentage：プロセスヒープによって割り当てられるメモリの最大量。デフォルトで0。このオプションは、利用可能なメモリの合計から
memory_limit。例えば、総メモリが1GiBで75%に設定した場合、上限は750MiBになります。固定メモリ設定（
limit_mib）は、パーセンテージ設定よりも優先されます。このコンフィギュレーションは、cgroupを持つLinuxシステムでサポートされており、Dockerのような動的プラットフォームで使用されることを意図しています。
spike_limit_mib:メモリ使用量の測定値の間に予想される最大スパイク。limit_mibspike_limit_mibの推奨値およびデフォルト値はlimit_mibの 20%です。ソフトリミット値は(
limit_mib-spike_limit_mib)に等しくなります。
spike_limit_percentage:メモリ使用量の測定値の間に予想される最大スパイク。値はlimit_percentage未満である必要があります。デフォルトでは0です。このオプションは、利用可能なメモリの合計から
spike_limit_mibを計算するために使用されます。例えば、総メモリが1GiBで25%に設定した場合、上限は250MiBになります。
設定 🔗
次の表は、memory_limiter プロセッサーの構成オプションを示します：
トラブルシューティング 🔗
Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。
Splunk Observability Cloudをご利用のお客様
Splunk サポートポータル でケースを送信する
Contact Splunk Support .
見込み客および無料トライアルユーザー様
Splunk Answers のコミュニティサポートで質問し、回答を得る
Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルの チャットグループ を参照してください。