캐시를 직접 가져오세요

뉴렐릭의 Infinite Tracing Processor는 OpenTelemetry Collector 의 tailsamplingprocessor를 구현한 것입니다. 상위 기능 외에도, 공유 상태 저장소를 위한 분산 캐시를 사용하여 확장 가능하고 내구성이 뛰어난 분산 처리를 지원합니다. 이 문서에는 설정 방법이 나와 있습니다.

지원되는 캐시

이 프로세서는 Redis와 호환되는 모든 캐시 구현을 지원합니다. 단일 인스턴스 및 클러스터 설정 모두에서 레디스와 Valkey를 사용하여 테스트되고 검증되었습니다. 프로덕션 구현, 배포의 경우 고가용성 및 확장성을 보장하기 위해 클러스터 모드(sharded)를 사용하는 것이 좋습니다. 분산 캐싱을 활성화하려면 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 이 길수록 중복 평가는 줄어들지만 레디스 메모리 사용량은 늘어납니다.

파티셔닝

분할의 이점:

• 여러 레디스 키 범위에 걸쳐 부하를 분산합니다.
• 여러 작업자 간에 병렬 평가를 가능하게 합니다.
• 다중 수집기 구현, 배포의 처리량을 개선합니다.

섭취 설정

데이터 수집 아키텍처:

프로세서는 구성 가능한 워커를 사용하는 공유 채널을 통해 데이터 수집을 수행합니다.

1. 수신되는 트레이스는 공유 버퍼 채널로 전송됩니다.
2. 여러 작업자가 채널에서 데이터를 가져와 적절한 파티션으로 전송합니다.
3. 구성된 해싱 전략을 사용하여 작업자 해시 트레이스 ID를 사용하여 파티션 할당을 결정합니다.

설정 지침:

• 버퍼 크기: 트래픽 급증을 흡수할 수 있어야 합니다.
• 작업자: 동시에 처리 중인 고루틴 수.
• 채널 타임아웃: 버퍼가 가득 찼을 때 대기하는 시간입니다. 짧은 타임아웃(500ms)은 포화 상태에서 빠르게 오류를 발생시킵니다.
• 응답 시간 초과: 작업자가 멈추는 현상을 방지합니다. 기본값: 10초는 일반적인 레디스 작동에 적합합니다.
• 해싱 전략: 트레이스 파티션 할당을 결정하는 알고리즘
• rendezvous (기본값): 2-99개 파티션에 대해 우수한 부하 분산을 제공합니다. 일반적인 구현을 위한 최선의 선택, 배포.
• consistent: 랑데부 속도가 느려지는 100개 이상의 파티션을 사용할 때 성능을 유지합니다. 부하 분산 최적화 측면에서 약간 불리한 대신 대규모 환경에서 더 나은 성능을 제공합니다.
• 두 전략 모두 동일한 트레이스가 항상 동일한 파티션에 매핑되도록 보장합니다(결정론적).
• 부하 분산을 개선하려면(최대 99개 파티션) 랑데부를 선택하고, 100개 이상의 파티션에서도 일관된 성능을 유지하세요.

평가 설정

속도 제한기:

rate_limiter 옵션은 동시 실행 제한(num_traces)에 도달했을 때 역압 동작을 제어합니다.

• false (기본값): 속도 제한 없음. 프로세서는 레디스를 저장 장치로 활용하여 블록킹 없이 트레이스를 처리합니다. 이는 대부분의 레디스 구현, 배포에 권장되는 설정입니다.
• true: num_traces 동시 트레이가 처리될 때 역압력을 적용하는 차단 속도 제한기를 활성화합니다. 새로운 트래픽은 자리가 생길 때까지 차단됩니다.

활성화 시점:

• 레디스의 네트워크, CPU 및/또는 메모리의 과부하를 방지하기 위해
• 갑작스러운 트래픽 폭증으로 하위 소비자들이 과부하되는 것을 방지하기 위해

재시도 및 복구

정책 설정

이들은 오픈 소스 테일 샘플링 과 동일한 규칙을 따릅니다.

레디스 클라이언트 타임아웃 및 연결 풀

모든 설정은 선택 사항이며 기본값은 10의 거듭제곱 ingestion_response_timeout 에 맞춰져 있습니다.

튜닝 가이드라인:

• High-지연시간 레디스 (크로스 리전, VPN): 타임아웃을 기본값의 2-3배로 늘리고 max_retries 2로 줄이세요.
• 매우 빠른 레디스 (동일 호스트/랙): 타임아웃 시간을 더욱 줄여(예: 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 마다 작업자는 최소 1시간 동안 유휴 상태였던 트레이를 확인합니다. trace_window_expiration
2. 평가 주기당 최대 max_traces_per_batch 트레이를 레디스에서 가져옵니다.
3. partition_workers 파티션 전체에 걸쳐 배치 작업을 동시에 평가합니다.

튜닝 가이드:

• 더 빠른 결정: 지연 시간을 줄이려면 evaluation_interval 줄이십시오(예: 500ms). 하지만 레디스 부하가 증가합니다.
• 처리량 증가: 주기당 더 많은 트레이스를 처리하려면 max_traces_per_batch 값을 늘리십시오(예: 5000-10000).
• 병렬 처리량 증가: 사용 가능한 CPU 코어 수에 맞춰 partition_workers 값을 늘리세요.

TTL 및 만료

분산 모드에서 TTL이 작동하는 방식

distributed_cache 사용할 때 프로세서는 메모리 내 프로세서와는 다른 다단계 TTL 시스템을 구현합니다.

트레이스 수명주기 단계:

1. 수집 단계: 스팬이 도착하여 레디스에 저장됩니다.
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은 레디스 메모리 사용을 최적화하는 동시에 데이터 손실, 중복 평가 및 불완전한 트레이스를 방지합니다.

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

• 목적: 초기 저장 후 트레이스 스팬 데이터가 레디스에 얼마나 오래 남아 있는지 확인하기 위함
• 동작: 재시도, 지연 시간 및 고아 복구를 위한 버퍼 시간을 제공합니다.
• 중요 제약 조건: 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-15m)을 사용하십시오.

• 표준 제작 시간: 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분 캐시: 약 90만 건의 결정 × 50바이트 = 약 45MB

• 2시간 캐시: 약 360만 건의 결정 × 50바이트 = 약 180MB

  팁

  캐시 효율성 모니터링: 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. 수집 실패로 인해 트레이가 손실되지 않도록 보장

튜닝 가이드:

• 일시적인 오류가 발생하는 경우 max_retries(3-5)을 증가시키십시오.
• 고가용성 환경에서 더 빠른 복구를 위해 recover_interval(2-3초)를 줄이십시오 .
• 수집기가 자주 충돌하는지 확인하기 위한 모니터 복구 지표

파티셔닝 및 스케일링

파티션이란 무엇인가요?

파티션 은 레디스에서 트레이스 데이터의 논리적 샤드로, 병렬 처리와 수평 확장을 가능하게 합니다. 파티션을 트레이스 ID에 따라 트레이스가 분산되는 별도의 큐로 생각하십시오.

주요 개념:

• 각 파티션은 레디스에 자체 대기열을 유지합니다.

• 트레이는 트레이 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. 저장 위치: 트레이스 데이터는 파티션별 키를 사용하여 레디스에 저장됩니다.
3. 평가: 해당 파티션에 할당된 작업자가 트레이스를 추출하고 평가합니다.
4. 동시성: 모든 파티션 작업자가 병렬로 실행되어 서로 다른 트레이를 동시에 처리합니다.

해싱 전략

이 프로세서는 파티션 선택을 위해 두 가지 해싱 알고리즘을 지원합니다. 선택은 파티션 수에 따라 달라집니다.

파티션 설정 방법,

논리 샤드의 수를 제어하려면 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 마다 하나의 파티션을 처리합니다. ✅ 균형 잡힘
• 8개 파티션 + 16개 워커: 각 파티션은 간격당 두 번씩 평가됨 (중복, 자원 낭비)
• 8개 파티션 + 4개 워커: 간격당 절반의 파티션만 평가됨 (속도는 느리지만 레디스 부하 감소)

파티션 크기 조정 지침

파티션 설정 예시

단일 수집기(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

크기 및 성능

예: 다음과 같은 사례를 가정합니다.

• 초당 스팬 처리량: 초당 10,000개의 스팬 처리량을 가정합니다.
• 평균 스팬 크기: 900바이트

1. 네트워크 요구 사항

대역폭 계산:

초당 10,000개의 스팬, 스팬당 900바이트의 경우:

• 수집 트래픽 (수집기 →디스 레): 10,000 × 900 bytes = 9 MB/sec = ~72 Mbps
• 평가 트래픽 (레디스 → 수집기): ~9 MB/sec = ~72 Mbps (평가를 위해 Traces 읽기)
• 총 양방향: ~18 MB/sec = ~144 Mbps

25% 압축률(스내피/lz4):

• 압축된 트래픽: ~108 Mbps 양방향

네트워크 가이드라인:

• 모니터 레디스 네트워크 사용량: 일반적인 redis 는 최대 1GB까지 처리할 수 있으므로 네트워크 사용량을 모니터링하십시오.
• 압축을 사용하세요: 압축은 수집기의 CPU 사용량을 늘리는 대신 네트워크 트래픽 양을 줄여줍니다.
• 동일 데이터센터/VPC 내 배치 : 대부분의 워크로드에는 1Gbps 네트워크 인터페이스로 충분합니다.
• 지역 간 연결: 10-50ms의 지연 시간이 예상됩니다. 타임아웃 시간을 늘리고 압축을 사용하여 대역폭을 줄이십시오.
• 연결 풀링: 처리량 증가를 위해 값을 높이세요.
• 복제본 사용: 클러스터에 읽기용 복제본이 있는 경우 기본적으로 해당 복제본이 사용됩니다. 마스터 노드의 네트워크 및 CPU 사용량 감소

2. CPU 요구 사항

CPU 가이드라인:

• 단일 레디스: 최소 4개의 vCPU

• 레디스 클러스터: 높은 처리량을 위해 각각 4개의 vCPU가 있는 읽기 전용 복제본이 있는 3개 이상의 노드.

• 복제본 사용: 클러스터에 읽기용 복제본이 있는 경우 기본적으로 해당 복제본이 사용됩니다. 마스터 노드의 네트워크 및 CPU 사용량 감소

  팁

  CPU 모니터링: CPU 포화 상태(사용률 80% 이상)를 주시하여 확장 필요성을 파악하십시오. CPU 사용량이 많을 경우 클러스터 노드를 추가하세요.

3. 메모리 요구 사항

메모리는 CPU나 네트워크보다 제약이 적지만, 적절한 크기로 설정하면 메모리 강제 종료를 방지하고 데이터 가용성을 보장할 수 있습니다.

메모리 추정 공식

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

트레이스 데이터 저장

트레이스 데이터는 늦게 도착하는 스팬과 트레이스 복구를 지원하기 위해 전체 traces_ttl 기간 동안 레디스에 저장됩니다.

• 스팬당 저장소: ~900 bytes (마샬링된 protobuf)

• 저장 기간: traces_ttl 에 의해 제어됨(기본값: 1시간)

• 활성 수집 창: trace_window_expiration 에 의해 제어됨(기본값: 30초)

• 공식: Memory ≈ spans_per_second × traces_ttl × 900 bytes

  중요

  활성 창 대 전체 보존: 트레이스는 ~30-second 활성 창(trace_window_expiration) 동안 수집되지만 전체 1시간 traces_ttl 기간 동안 트레이스에 지속됩니다. 이를 통해 프로세서는 늦게 도착한 스팬을 처리하고 버려진 트레이스를 복구할 수 있습니다. 여성용 사이즈는 활성 기간뿐만 아니라 전체 보관 기간 을 고려해야 합니다.

계산 예시: 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

참고: 이 계산은 기본 메모리 소비자를 나타냅니다. 실제 LEDS 메모리는 결정 캐시와 내부 데이터 구조로 인해 약간 더 높을 수 있습니다.

결정 캐시 저장소

distributed_cache 사용하면 결정 캐시는 명시적 크기 제한 없이 LEDS에 저장됩니다. 대신, REDIS는 기본 LRU 퇴거 정책( maxmemory-policy 통해 구성됨)을 사용하여 메모리를 관리합니다. 각 트레이스 ID에는 약 50바이트의 저장 공간이 필요합니다.

• 샘플링된 캐시: 레디스 LRU 제거에 의해 관리됨

• 샘플링되지 않은 캐시: 레디스 LRU 제거에 의해 관리됨

• 트레이스 ID당 일반적인 오버헤드: ~50 bytes

  팁

  메모리 관리: 메모리 제한에 도달하면 오래된 결정 캐시 항목을 자동으로 제거할 수 있도록 maxmemory-policy allkeys-lru 으로 LEDS를 구성합니다. 결정 캐시 키는 고정 크기 제한 대신 TTL 기반 만료( cache_ttl 에 의해 제어됨)를 사용합니다.

배치 처리 오버헤드

• 현재 배치 대기열: 최소(트레이스 ID + 정렬된 세트의 점수)
• 기내 배치: max_traces_per_batch × average_spans_per_trace × 900 bytes

계산 예시: 배치당 500 트레이스(기본값), 트레이당 평균 20 스팬:

500 × 20 × 900 bytes = 9 MB per batch

배치 크기는 평가 중의 메모리 사용량에 영향을 미칩니다. 진행 중인 배치 메모리는 일시적이며 처리가 완료되면 해제됩니다.

기본 설정하기

기본 설정 값은 분당 100만 범위(-16,000 범위/초)를 지원하는 참조 구현을 위해 설계되었습니다.

Collector 구현, 배포:

• 3개의 수집기 인스턴스
• 인스턴스당 4개의 vCPU
• 인스턴스당 8GB RAM

레디스 클러스터:

• 3없었습니다 (AWS 캐시.r6g.xlarge: vCPU 4개, 각각 25.01 GiB 메모리)
• 고가용성 및 부하 분산을 위해 클러스터로 구성됨
• 낮은 지연시간 접속을 위해 수집기와 함께 배치

이 참조는 생산, 배포의 시작점을 제공합니다. 실제 처리량 및 지연 시간 요구 사항에 따라 조정하십시오.

지표 참조

테일 샘플링 프로세서는 성능 모니터링 및 문제 진단을 지원하기 위해 Redis 분산 모드에서 다음과 같은 메트릭을 출력합니다.

사용 가능한 지표

치수 상세 정보

• policy: 결정을 내리는 데 사용된 샘플링 정책의 이름
• sampled: 샘플링을 할 것인지 여부 (true/false)
• decision: 샘플링 결정 유형(sampled, not_sampled, dropped)
• deleted: 삭제가 성공했는지 여부 (true/false)
• partition: Partition (hex-encoded Mid, eg, {a1b2c3d4...}) - 레디스 Cluster 태그 호환성 보장
• processor: 프로세서 인스턴스 식별자 (distributed_cache.processor_name 구성에서 가져옴)

Redis 호환 캐시 요구 사항

프로세서는 다음 트레이스 데이터에 대한 분산 저장소로 캐시를 사용합니다.

• 트레이스 및 스팬 속성
• 액티브 트레이스 데이터
• 샘플링 결정 캐시

프로세서는 Lua 펼쳐보기를 실행하여 레디스 캐시와 원자적으로 상호작용합니다. Lua 스크립트 지원은 일반적으로 Redis 호환 캐시에서 기본적으로 활성화됩니다. 이 기능을 명시적으로 비활성화하지 않는 한 추가 설정은 필요하지 않습니다.