自分のキャッシュを持ち込む

New Relic の Infinite Tracing Processor は、OpenTelemetry Collector tailsamplingprocessorの実装です。アップストリーム機能に加えて、共有状態ストレージ用の分散キャッシュを使用することで、スケーラブルで耐久性のある分散処理をサポートします。このドキュメントでは設定方法を説明します

サポートされているキャッシュ

プロセッサは、Redis 互換のキャッシュ実装をサポートします。単一インスタンスとクラスタ設定の両方で、 Redisと Valkey を使用してテストおよび検証されています。 運用環境のデプロイメントでは、高可用性と拡張性を確保するためにクラスタ モード (シャード) を使用することをお勧めします。 分散キャッシュを有効にするには、 tail_samplingプロセッサ セクションにdistributed_cache設定を追加します。

tail_sampling:
  distributed_cache:
    connection:
      address: redis://localhost:6379/0
      password: 'local'
    trace_window_expiration: 30s      # Default: how long to wait after last span before evaluating
    processor_name: "itc"             # Nane of the processor
    data_compression:
      format: lz4                     # Optional: compression format (none, snappy, zstd, lz4); lz4 recommended

addressでは、標準形式を使用して有効な Redis 互換サーバー アドレスを指定する必要があります。

redis[s]://[[username][:password]@][host][:port][/db-number]

あるいは、認証情報をaddressに直接埋め込むこともできます。

tail_sampling:
  distributed_cache:
    connection:
      address: redis://:yourpassword@localhost:6379/0

プロセッサは Go で実装されており、 go-redisクライアント ライブラリを使用します。

設定パラメーター

distributed_cacheセクションは次の点をサポートしています。

接続設定

データ圧縮

トレース管理

TTLガイドライン:

• traces_ttl 再試行や遅延スパンを処理するのに十分な長さである必要があります
• cache_ttl 遅れて到着するスパンを処理するには、 traces_ttlよりもはるかに長くする必要があります
• cache_ttlが長くなると重複評価は減りますが、Redis のメモリ使用量は増加します。

パーティショニング

パーティショニングの利点:

• 複数のRedisキー範囲にわたって負荷を分散します
• 複数のワーカー間での並列評価を可能にする
• マルチコレクターデプロイメントのスループットを改善します

取り込み設定

摂取アーキテクチャー:

プロセッサは、トレースの取り込みのために構成可能なワーカーを備えた共有チャネルを使用します。

1. 受信したトレースは共有バッファチャネルに送信されます
2. 複数のワーカーがチャネルからプルし、トレースを適切なパーティションにルーティングします。
3. ワーカーは、構成されたハッシュ戦略を使用してトレース ID をハッシュし、パーティションの割り当てを決定します。

設定ガイドライン:

• バッファ サイズ: トラフィックのバーストを吸収する必要があります。
• ワーカー: トレースを処理する同時ゴルーチンの数。
• チャネル タイムアウト: バッファがいっぱいの場合に待機する時間。短いタイムアウト（500ms）は飽和時にすぐに失敗する
• 応答タイムアウト: ワーカーのスタックから保護します。デフォルト: 通常のRedis操作では10秒が適切です
• ハッシュ戦略：トレースパーティションの割り当てを決定するアルゴリズム
• rendezvous (デフォルト): 2 ～ 99 個のパーティションに優れた負荷分散を提供します。典型的なデプロイメントに最適な選択です。
• consistent : ランデブーが遅くなる 100 以上のパーティションを使用するときにパフォーマンスを維持します。大規模環境でのパフォーマンス向上のために、負荷分散は若干最適化されなくなります。
• どちらの戦略も、同じトレースが常に同じパーティションにマッピングされることを保証します（決定論的）。
• ランデブーを選択すると、負荷分散が向上し（最大 99 パーティション）、大規模（100 以上）でも一貫したパフォーマンスが得られます。

評価設定

レートリミッター:

rate_limiterオプションは、同時トレース制限 (num_traces) に達したときのバックプレッシャー動作を制御します。

• false (デフォルト) : レート制限なし。プロセッサは、ストレージに Redis を使用し、ブロックせずにトレースを受け入れます。これは、ほとんどの Redis デプロイメントで推奨される設定です。
• true : num_tracesの同時トレースが処理されているときにバックプレッシャーを適用するブロッキング レート リミッターを有効にします。スロットが利用可能になるまで、新しいトレースはブロックされます。

有効にする場合:

• Redisネットワーク、CPU、メモリの過負荷を防ぐため
• 突然のトラフィックバーストによる下流の消費者の過負荷を防ぐため

再試行と回復

ポリシー設定

これらは、オープンソースのテール サンプリングと同じルールに従います。

Redis クライアントのタイムアウトと接続プール

すべての設定はオプションであり、デフォルトは 10 の位ingestion_response_timeoutに揃えられています。

チューニングガイドライン:

• 高レイテンシRedis (クロスリージョン、VPN): タイムアウトをデフォルトの 2 ～ 3 倍に増やし、 max_retriesを 2 に減らします
• 非常に高速なRedis （同じホスト/ラック）：タイムアウトをさらに短縮（例：250ms）して、障害検出を高速化できます。
• 高スループット: 接続プールの枯渇を回避するには、 pool_size 30 ～ 50 に増やします
• 信頼性の低いネットワーク: max_retries 5 ～ 7 に増やし、バックオフ設定を調整してください

Clusterレプリカオプション

connection.replicaセクションは、クラスター レプリカ ルーティングを制御します。

完全な設定例

processors:
  tail_sampling:
    num_traces: 5_000_000
    distributed_cache:
      # Connection
      connection:
        address: "redis://redis-cluster:6379/0"
        password: "your-redis-password"

        # Connection pool settings (optional - tune for your environment)
        pool_size: 30
        read_timeout: 2s
        write_timeout: 2s
        pool_timeout: 5s
        max_retries: 5

        # Replica read options (cluster mode only)
        replica:
          read_only_replicas: true  # Default: enabled for improved scalability
          route_by_latency: true    # Route to closest node (recommended)

      # Compression
      data_compression: snappy

      # Trace Management
      trace_window_expiration: 30s
      traces_ttl: 2m              # 120s (allow extra time for retries)
      cache_ttl: 1h               # 3600s (keep decisions longer)
      processor_name: "prod-cluster-1"

      # Retry and Recovery
      max_retries: 3
      in_flight_timeout: 45s
      recover_interval: 10s

      # Evaluation
      evaluation_interval: 1s
      max_traces_per_batch: 10000
      rate_limiter: false         # Recommended for Redis mode

      # Partitioning
      partitions: 8
      partition_workers: 8
      partition_buffer_max_traces: 1000

      # Ingestion
      ingestion_workers: 12            # 1.5 workers per partition
      ingestion_buffer_size: 40000     # 40k trace buffer
      ingestion_channel_timeout: 500ms
      ingestion_response_timeout: 10s
      hashing_strategy: rendezvous     # default, best for less than 100 partitions

    # Sampling policies
    policies:
      - name: errors
        type: status_code
        status_code: {status_codes: [ERROR]}
      - name: slow-traces
        type: latency
        latency: {threshold_ms: 1000}
      - name: sample-10-percent
        type: probabilistic
        probabilistic: {sampling_percentage: 10}

トレース評価

このセクションでは、トレースがいつ評価されるか、およびデータがRedisに保持される期間を制御する問題について説明します。

評価のタイミングと頻度

評価の仕組み:

1. evaluation_intervalごとに、ワーカーは少なくともアイドル状態になっているトレースをチェックします trace_window_expiration
2. 評価サイクルごとに最大max_traces_per_batchトレースが Redis から取得されます
3. partition_workers パーティション間でバッチを同時に評価する

チューニングガイダンス:

• より速い決定: レイテンシを低くするためにevaluation_interval （例：500ms）を減少させますが、Redisの負荷は増加します
• スループットの向上: max_traces_per_batch (例: 5000-10000) を増やすと、サイクルごとに処理できるトレースの数が増えます。
• 並列処理を増やす: 利用可能なCPUコアに合わせてpartition_workersを増やします

TTLと有効期限

分散モードでのTTLの仕組み

distributed_cacheを使用する場合、プロセッサはメモリ内プロセッサとは異なるマルチステージ TTL システムを実装します。

トレースライフサイクルのステージ:

1. 収集フェーズ: スパンは到着し、Redisに保存されます
2. 評価フェーズ: trace_window_expiration後、トレースはサンプリング決定の準備が整います
3. 保持フェーズ: 再試行と遅延スパンを処理するためにトレース データはtraces_ttl保持されます
4. キャッシュフェーズ: 重複評価を防ぐため、サンプリング決定はcache_ttl間持続します

カスケード TTL が重要な理由:

TTL 階層により、トレースのライフサイクル全体にわたってデータの可用性が確保されます。

trace_window_expiration (30s)
    ↓ [trace ready for evaluation]
in_flight_timeout (30s default)
    ↓ [evaluation completes or times out]
traces_ttl (5m)
    ↓ [trace data deleted from Redis]
cache_ttl (30m)
    ↓ [decision expires, late spans re-evaluated]

• trace_window_expiration （最短）は評価開始時の制御です
• in_flight_timeout (最短) は、評価に時間がかかりすぎて再試行する必要がある場合に制御します。
• cache_ttl （最長）は、評価後数時間遅れて到着する範囲を処理します
• traces_ttl (中) は再試行と孤立回復のためのバッファを提供します

適切に構成された TTL は、Redis のメモリ使用量を最適化しながら、データの損失、重複した評価、不完全なトレースを防ぎます。

1. トレース収集ウィンドウ: trace_window_expiration

デフォルト: 30s |設定: distributed_cache.trace_window_expiration

• 目的: トレースがサンプリング評価の準備ができたかどうかを制御します
• 動作: トレースに新しいスパンが到着するたびにリセットされるスライディングウィンドウ
• 例: トレースが t=0 秒、t=15 秒、t=28 秒でスパンを受信する場合、評価は t=58 秒 (28 秒 + 30 秒のウィンドウ) から開始されます。

チューニングガイダンス:

• 短い値（15～20秒） ：サンプリングの決定は速くなりますが、スパンがゆっくりと到達するとトレースが不完全になるリスクがあります。
• 長い値（45～60秒） : より完全なトレースが得られますが、レイテンシとメモリ使用量が増加します
• 標準範囲: スパンの到着パターンに応じて 20 ～ 45 秒

2. バッチ処理のタイムアウト: in_flight_timeout

デフォルト: trace_window_expirationと同じ |設定: distributed_cache.in_flight_timeout

• 目的: バッチが孤立しているとみなされるまでに処理される最大時間
• 動作: 評価中にコレクターがクラッシュした場合のデータ損失を防ぎます
• 孤立回復: このタイムアウトを超えたバッチは、別のコレクターによる評価のために自動的に再キューイングされます。

チューニングガイダンス:

• ≥ trace_window_expirationである必要があります: 通常の評価に十分な時間を確保します

• 増加: 評価ポリシーの計算コストが高い場合 (複雑な OTTL、正規表現)

• モニター: otelcol_processor_tail_sampling_sampling_decision_timer_latencyこの期間内に評価が完了することを確認します

  ヒント

  trace_window_expiration との関係: in_flight_timeout trace_window_expirationに設定すると、ほとんどのデプロイメントで適切に機能します。 ポリシー評価が遅いために孤立したバッチ回復が頻繁に発生する場合にのみ、値を増やしてください。

3. トレースデータの保持期間: traces_ttl

デフォルト: 5m |設定: distributed_cache.traces_ttl

• 目的: トレーススパンデータが初期保存後、Redis にどれくらい長く保存されるか
• 動作: 再試行、遅延スパン、孤立回復のためのバッファ時間を提供します
• 重要な制約: trace_window_expirationより大幅に長くなければなりません + in_flight_timeout

推奨配合:

traces_ttl ≥ (trace_window_expiration + in_flight_timeout + max_retries × evaluation_interval) × 2

デフォルトの例:

traces_ttl ≥ (30s + 30s + 2 retries × 1s) × 2 = 124s ≈ 5m ✅

チューニングガイダンス:

• メモリ制約: TTLを短くする(2～3分)が、非常に遅いスパンではデータが失われるリスクがある

• 遅延スパン許容範囲: 遅延スパン到着を処理するために、より長い TTL (10～15 分) を使用します。

• 標準生産：5〜10分でバランスが取れます

  重要

  短すぎる = データが失われます: traces_ttlが短すぎる場合、特に再試行中または孤立回復中に、評価が完了する前にトレースが削除される可能性があります。その結果、トレースが部分的に残ったり、欠落したりします。

4. 決定キャッシュの保持: cache_ttl

デフォルト: 30m |設定: distributed_cache.cache_ttl

• 目的: サンプリング決定（サンプリング済み/未サンプリング）がキャッシュされる期間
• 動作: トレースが評価された後に遅延スパンが到着した場合の重複評価を防止します
• 重要な制約: より長くなければならない traces_ttl

推奨配合:

cache_ttl ≥ traces_ttl × 6

なぜもっと長いのですか?

• 遅れて到着するスパンは、トレースが完了してから数分または数時間後に到着する可能性がある
• 決定キャッシュは、非常に遅いスパンが到着したときにトレースの再評価を防止します。
• キャッシュされた決定がなければ、遅れたスパンは不完全なトレースとして評価されます（誤ったサンプリング決定）。

チューニングガイダンス:

• 標準生産: 30 分～ 2 時間でメモリ使用量と後期スパン処理のバランスをとる
• 高い遅延スパン率: 2～4時間で、非常に遅延したデータに対しても決定が持続することを保証
• メモリ制限: 最低15～30分ですが、重複した評価が増える可能性があります

メモリへの影響:

• 各決定: トレース ID ごとに最大 50 バイト

• 10,000 スパン/秒、20 スパン/トレースの場合 → 500 トレース/秒

• 30 分間のキャッシュ: 約 900,000 件の決定 × 50 バイト =約 45 MB

• 2時間キャッシュ: 約360万の決定 × 50バイト =約180 MB

  ヒント

  キャッシュの有効性を監視: otelcol_processor_tail_sampling_early_releases_from_cache_decisionメトリクスを追跡します。 値が高い場合は、キャッシュが重複した評価を効果的に防止していることを示します。

TTL設定例

低レイテンシ、メモリ制限あり:

distributed_cache:
  trace_window_expiration: 20s
  in_flight_timeout: 20s
  traces_ttl: 2m
  cache_ttl: 15m
  evaluation_interval: 500ms
  max_traces_per_batch: 2000

高スループット、遅延耐性:

distributed_cache:
  trace_window_expiration: 45s
  in_flight_timeout: 60s
  traces_ttl: 10m
  cache_ttl: 2h
  evaluation_interval: 1s
  max_traces_per_batch: 10000

バランスの取れた生産（推奨）:

distributed_cache:
  trace_window_expiration: 30s
  in_flight_timeout: 45s  # Extra buffer for complex policies
  traces_ttl: 5m
  cache_ttl: 30m
  evaluation_interval: 1s
  max_traces_per_batch: 5000

再試行と回復

孤児の回復:

コレクターが評価の途中でクラッシュすると、孤立したバッチが発生します。孤立回復プロセスはrecover_intervalごとに実行され、次のようになります。

1. 超過したバッチを識別します in_flight_timeout
2. これらのトレースを別のコレクターインスタンスによる評価のために再キューします
3. コレクターの障害によりトレースが失われないようにします

チューニングガイダンス:

• 一時的なRedisエラーが発生している場合は、 max_retries （3〜5）を増やします。
• 高可用性環境でのリカバリを高速化するには、 recover_interval （2～3秒）を減らします。
• コレクターが頻繁にクラッシュしているかどうかを特定するためのモニターリカバリー・メトリクス

パーティショニングとスケーリング

パーティションとは何ですか?

パーティションは、並列処理と水平スケーリングを可能にする、Redis 内のトレース データの論理シャードです。パーティションは、トレース ID に基づいてトレースが分散される個別のキューと考えてください。

重要な概念:

• 各パーティションはRedisで独自の保留中のトレースキューを維持します

• トレースは、トレース ID で構成可能なハッシュ戦略(ランデブーまたはコンシステント) を使用してパーティションに割り当てられます。

• 各パーティションは独立して同時に処理できる

• パーティションにより、垂直方向のスケーリング(より多くの CPU コア) と水平方向のスケーリング(より多くのコレクター インスタンス) の両方が可能になります。

  注意

  重要: クラスターがすでに実行されているときにパーティションの数を変更すると、変更後にトレースが別のパーティションにルーティングされる可能性があるため、トレースが断片化されます。

パーティショニングの仕組み

Incoming Traces
      |
      v
┌─────────────────────────────┐
│  Hashing Strategy           │  trace_id → rendezvous or consistent hash
│  (rendezvous by default)    │
└─────────────────────────────┘
      |
      ├──────────┬──────────┬──────────┐
      v          v          v          v
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│Partition│ │Partition│ │Partition│ │Partition│
│    0    │ │    1    │ │    2    │ │    3    │
│ (Redis) │ │ (Redis) │ │ (Redis) │ │ (Redis) │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
      |          |          |          |
      v          v          v          v
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Worker  │ │ Worker  │ │ Worker  │ │ Worker  │
│    0    │ │    1    │ │    2    │ │    3    │
│(Goroutine)│(Goroutine)│(Goroutine)│(Goroutine)│
└─────────┘ └─────────┘ └─────────┘ └─────────┘
      |          |          |          |
      └──────────┴──────────┴──────────┘
                   |
                   v
            Sampled Traces

流れ：

1. インジェスト: トレース ID は、構成されたハッシュ戦略を使用してハッシュされ、パーティションの割り当てが決定されます。
2. ストレージ: パーティション固有のキーでRedisに保存されるトレースデータ
3. 評価: そのパーティションに割り当てられたワーカーがトレースをプルして評価します
4. 同時実行性: すべてのパーティションワーカーが並列に実行され、異なるトレースを同時に処理します。

ハッシュ戦略

プロセッサは、パーティション選択用の 2 つのハッシュ アルゴリズムをサポートしています。選択はパーティションの数によって異なります。

パーティション設定がある

partitionsを使用して論理シャードの数を制御し、 partition_workers使用してそれらを処理するワーカーの数を設定します。

distributed_cache:
  partitions: 8         # Number of logical shards in Redis
  partition_workers: 8  # Number of workers processing partitions

労働者の行動:

• 8つのパーティション + 8つのワーカー: 各ワーカーはevaluation_intervalごとに1つのパーティションを処理します✅バランスが取れています
• 8 つのパーティション + 16 人のワーカー: 各パーティションは間隔ごとに 2 回評価されます (冗長、リソースの無駄)
• 8 つのパーティション + 4 つのワーカー: 間隔ごとに半分のパーティションのみが評価されます (速度は遅くなりますが、Redis の負荷は少なくなります)

パーティションのサイズ設定ガイドライン

パーティション設定例

シングルコレクター（4コアマシン）:

distributed_cache:
  partitions: 4
  partition_workers: 4
  partition_buffer_max_traces: 5000

マルチコレクター (インスタンス 3 つ、各 8 コア):

distributed_cache:
  partitions: 12                    # 3x more than single collector
  partition_workers: 6              # Each collector processes 6 partitions
  partition_buffer_max_traces: 10000

大容量 (10 人以上のコレクター):

distributed_cache:
  partitions: 24
  partition_workers: 4              # Fewer per collector to share load
  partition_buffer_max_traces: 20000

サイズとパフォーマンス

例: 次のような問題を想定します

• 1秒あたりのスパン数: 1秒あたり10,000スパンのスループットを想定
• 平均スパンサイズ: 900 バイト

1. ネットワーク要件

帯域幅の計算:

1スパンあたり900バイトで10,000スパン/秒の場合:

• 取り込みトラフィック(コレクター → Redis): 10,000 × 900 bytes = 9 MB/sec = ~72 Mbps
• 評価トラフィック(Redis → コレクター): ~9 MB/sec = ~72 Mbps (評価用のトレースを読み込んでいます)
• 双方向合計: ~18 MB/sec = ~144 Mbps

25% 圧縮 (snappy/lz4):

• 圧縮トラフィック: ~108 Mbps双方向

ネットワークガイドライン:

• Redisネットワーク使用量の監視: 一般的なredisインスタンスは最大 1GB を処理できるため、ネットワーク使用量を必ず監視してください。
• 圧縮を使用する：コレクターのCPU使用率と引き換えにネットワークトラフィックの数を削減します
• 共存（同じデータセンター/VPC）：ほとんどのワークロードには 1 Gbps のネットワーク インターフェースで十分です
• リージョン間: 10～50 ミリ秒のレイテンシが想定されるため、タイムアウトを増やし、圧縮を使用して帯域幅を削減します。
• 接続プーリング: スループット向上のため増加
• レプリカを使用する: クラスターに読み取りレプリカがある場合は、デフォルトでそれらが使用されます。マスターノードのネットワークとCPU使用量を削減する

2. CPU要件

CPUガイドライン:

• 単一Redisインスタンス: 最小 4 つの vCPU

• Redis クラスター: 高いスループットを実現するために、それぞれ 4 つの vCPU を備えた読み取りレプリカを備えた 3 つ以上のノード。

• レプリカを使用する: クラスターに読み取りレプリカがある場合は、デフォルトでそれらが使用されます。マスターノードのネットワークとCPU使用量を削減する

  ヒント

  CPU の監視: スケーリングの必要性を示す最初の指標として、CPU の飽和状態 (使用率 80% 以上) を監視します。CPUが制限されている場合は、クラスタノードを追加するか

3. メモリ要件

メモリは CPU やネットワークほど制約がありませんが、適切なサイズ設定により、メモリの排除が防止され、データの可用性が確保されます。

メモリ推定式

Total Memory = (Trace Data) + (Decision Caches) + (Overhead)

トレースデータの保存

トレース データは、遅延到着スパンとトレース リカバリをサポートするために、 traces_ttl期間全体にわたってRedisに保存されます。

• スパンごとのストレージ: ~900 bytes (マーシャリングされたプロトコルバッファ)

• 保存期間: traces_ttlによって制御されます (デフォルト: 1 時間)

• アクティブなコレクションウィンドウ: trace_window_expirationによって制御されます (デフォルト: 30 秒)

• 式： Memory ≈ spans_per_second × traces_ttl × 900 bytes

  重要

  アクティブ ウィンドウと完全な保持期間: トレースは~30-secondアクティブ ウィンドウ (trace_window_expiration) 中に収集されますが、1 時間traces_ttl期間全体にわたって Redis に保持されます。これにより、プロセッサは遅れて到着するスパンを処理し、孤立したトレースを回復できるようになります。Redis のサイズ設定では、アクティブ ウィンドウだけでなく、保持期間全体を考慮する必要があります。

計算例: 1時間traces_ttlで10,000スパン/秒の場合:

10,000 spans/sec × 3600 sec × 900 bytes = 32.4 GB

lz4 圧縮の場合(25% の削減が見られました):

32.4 GB × 0.75 = 24.3 GB

注: この計算は、主なメモリの消費者を表します。実際の Redis メモリは、決定キャッシュと内部データ構造により若干大きくなる場合があります。

決定キャッシュストレージ

distributed_cacheを使用する場合、決定キャッシュは明示的なサイズ制限なしで Redis に保存されます。代わりに、Redis はネイティブの LRU 削除ポリシー ( maxmemory-policyで構成) を使用してメモリを管理します。各トレース ID には約 50 バイトのストレージが必要です。

• サンプルキャッシュ: Redis LRUエビクションによって管理

• 非サンプリングキャッシュ: Redis LRUエビクションによって管理

• トレース ID ごとの一般的なオーバーヘッド: ~50 bytes

  ヒント

  メモリ管理: メモリ制限に達したときに古いデシジョン キャッシュ エントリを自動的に削除できるように、 maxmemory-policy allkeys-lruを使用してRedisを構成します。 決定キャッシュ キーは、固定サイズ制限ではなく、TTL ベースの有効期限 ( cache_ttlによって制御) を使用します。

バッチ処理のオーバーヘッド

• 現在のバッチ キュー: 最小限 (ソート セット内のトレース ID + スコア)
• 飛行中のバッチ: max_traces_per_batch × average_spans_per_trace × 900 bytes

計算例: バッチあたり 500 トレース (デフォルト)、トレースあたり平均 20 スパン:

500 × 20 × 900 bytes = 9 MB per batch

バッチ サイズは評価中のメモリ使用量に影響します。実行中のバッチ メモリは一時的なものであり、処理が完了すると解放されます。

デフォルト設定アーキテクチャー

デフォルトの設定値は、1 分あたり 100 万スパン (~16,000 スパン/秒) をサポートする参照デプロイメント用に設計されています。

Collector :

• 3つのコレクターインスタンス
• インスタンスあたり 4 つの vCPU
• インスタンスあたり 8 GB の RAM

Redis クラスター:

• 3 つの Redis インスタンス(AWS cache.r6g.xlarge: 4 つの vCPU、各 25.01 GiB のメモリ)
• 高可用性と負荷分散のためにクラスタとして構成
• コレクターと同じ場所に設置され、低レイテンシアクセスを実現

このリファレンス アーキテクチャーは、運用開発の開始点を提供します。 実際のスループットとレイテンシの要件に基づいて調整します。

メトリクスリファレンス

テール サンプリング プロセッサは、パフォーマンスの監視と問題の診断に役立つように、Redis 分散モードで次のメトリクスを生成します。

利用可能なメトリクス

寸法詳細

• policy : 決定を行ったサンプリングポリシーの名前
• sampled : サンプリングの決定 (true / false) であったかどうか
• decision : サンプリング決定タイプ (sampled 、 not_sampled 、 dropped)
• deleted : 削除が成功したかどうか (true / false)
• partition : パーティション識別子 (16 進数でエンコードされたハッシュ、例: {a1b2c3d4...}) - Redis Cluster のハッシュタグの互換性を確保します
• processor : プロセッサインスタンス識別子 (distributed_cache.processor_name構成から)

Redis互換キャッシュ要件

プロセッサは、次のトレース データの分散ストレージとしてキャッシュを使用します。

• トレースとスパン属性
• アクティブトレースデータ
• サンプリング決定キャッシュ

プロセッサはLua スクリプトを実行して、Redis キャッシュとアトミックに対話します。Redis 互換キャッシュでは、通常、Lua スクリプトのサポートはデフォルトで有効になっています。この機能を明示的に無効にしない限り、追加の設定は必要ありません。