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

メモリリミッタプロセッサーは、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 のデフォルト設定」を参照してください。このドキュメントで説明されているように、いつでも設定をカスタマイズできます。

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

  1. Splunk Distribution of OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします：

  2. 次のセクションで説明するように、memory_limiter プロセッサーを設定します。

  3. Collector を再起動します。

サンプル構成

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

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

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

YAML 
processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 4000
    spike_limit_mib: 800

設定を完了するには、構成ファイルの service セクションの任意のパイプラインにプロセッサを含めます。例：

YAML 
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

トラブルシューティング

If you are a Splunk Observability Cloud customer and are not able to see your data in Splunk Observability Cloud, you can get help in the following ways.

Available to Splunk Observability Cloud customers

Available to prospective customers and free trial users

  • Ask a question and get answers through community support at Splunk Answers.

  • Join the Splunk community #observability Slack channel to communicate with customers, partners, and Splunk employees worldwide.