メモリリミッタープロセッサー

メモリリミッタプロセッサーは、Splunk Distribution of OpenTelemetry Collector でのメモリ不足の状況を防ぎます。

メモリリミッタプロセッサは、Splunk Distribution of OpenTelemetry Collector でのメモリ不足の状況を防ぎます。サポートされるパイプラインタイプは、traces、metrics、logs です。詳細については「パイプラインでデータを処理する」を参照してください。

はじめに

注: このコンポーネントは、ホスト監視（エージェント）モードでデプロイする場合、Splunk Distribution of the OpenTelemetry Collector のデフォルト設定に含まれます。詳細については、「Collector deployment modes」を参照してください。デフォルト設定について詳しくは「Helm で Collector for Kubernetes を設定する」、「Collector for Linux のデフォルト設定」、または「Collector for Windows のデフォルト設定」を参照してください。このドキュメントで説明されているように、いつでも設定をカスタマイズできます。

以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください：

Splunk Distribution of OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします：
次のセクションで説明するように、memory_limiter プロセッサーを設定します。
Collector を再起動します。

サンプル構成

リソースプロセッサーを有効にするには、設定ファイルの memory_limiter セクションに processors を追加します。

パイプラインの最初のプロセッサーとして、レシーバーの直後に memory_limiter を定義します。これは、バックプレッシャーが該当するレシーバーに送られるようにするためであり、また、memory_limiter がトリガーされたときにデータがドロップされる可能性を最小限にするためです。

次の例を参照してください：

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% に設定した場合、制限は 750 MiB になります。
- 固定メモリ設定（ limit_mib ）は、パーセンテージ設定よりも優先されます。
- このコンフィギュレーションは、cgroup を含む Linux システムでサポートされており、Docker のような動的プラットフォームで使用されることを意図しています。
spike_limit_mib：メモリ使用量の測定値の間に予想される最大スパイク。値は limit_mib 未満である必要があります。spike_limit_mib の推奨値およびデフォルト値は、limit_mib の 20% です。
- ソフトリミット値は、limit_mib の値から spike_limit_mib の値を引いた値に等しくなります。
spike_limit_percentage：メモリ使用量の測定値の間に予想される最大スパイク。値は limit_percentage 未満にする必要があります。デフォルトは 0 です。
- このオプションは、使用可能なメモリの合計から spike_limit_mib を計算するために使用されます。たとえば、合計メモリ 1GiB で 25% に設定した場合、制限は 250MiB になります。

設定

次の表は、memory_limiter プロセッサーの構成オプションを示します：

同梱

https://raw.githubusercontent.com/splunk/collector-config-tools/main/cfg-metadata/processor/memory_limiter.yaml

トラブルシューティング

__ ___ ___ _ ______ _____________ _____ ________ ___ ___ ___ ____ __ ___ ____ ____ __ ______ _____________ ______ ___ ___ ___ ____ __ ___ _________ _____

_________ __ ______ _____________ _____ _________

______ _ ____ __ ___ ______ _______ _______
_______ ______ ________

_________ __ ___________ _________ ___ ____ _____ _____

___ _ ________ ___ ___ _______ _______ _________ _______ __ ______ ________
____ ___ ______ ______________ ____ _____ _____ _______ __ ___________ ____ __________ _________ ___ ______ _________ __________ __ _____ ___ ____ _______