Trae tu propio caché

El procesador de Infinite Tracing de New Relic es una implementación del OpenTelemetry Collector tailsamplingprocessor. Además de las funciones upstream, admite el procesamiento distribuido escalable y duradero mediante el uso de una caché distribuida para el almacenamiento de estado compartido. Esta documentación explica cómo configurarlo

Cachés compatibles

El procesador es compatible con cualquier implementación de caché compatible con Redis. Se ha probado y validado con Redis y Valkey tanto en configuraciones de instancia única como de clúster. Para implementaciones de producción, recomendamos usar el modo clúster (fragmentado) para garantizar una alta disponibilidad y escalabilidad. Para habilitar el almacenamiento en caché distribuido, agregue la configuración distributed_cache a su sección de procesador tail_sampling:

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

El parámetro address debe especificar una dirección de servidor válida compatible con Redis empleando el formato estándar:

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

Alternativamente, puede insertar credenciales directamente en el parámetro address :

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

El procesador está implementado en Go y emplea la biblioteca cliente go-redis.

Parámetro de configuración

La sección distributed_cache admite los siguientes parámetros:

Configuración de conexión

Compresión de datos

Gestión de rastreos

Directrices TTL:

• traces_ttl debe ser lo suficientemente largo para gestionar reintentos y spans tardíos
• cache_ttl debería ser mucho más largo que traces_ttl para manejar los spans que llegan tarde
• Un cache_ttl más largo reduce las evaluaciones duplicadas, pero aumenta el uso de memoria Redis

Particionamiento

Beneficios de la partición:

• Distribuye la carga entre múltiples rangos de claves de Redis
• Permite la evaluación paralela en múltiples trabajadores
• Mejora el rendimiento en implementaciones de múltiples recolectores

Ajustes de ingestión

Arquitectura de ingestión:

El procesador utiliza un canal compartido con trabajadores configurables para la ingestión de trazas:

1. Las trazas entrantes se envían a un canal en búfer compartido
2. Múltiples trabajadores extraen del canal y enrutan las trazas a las particiones apropiadas
3. Los trabajadores hash rastrean los ID utilizando la estrategia de hash configurada para determinar la asignación de particiones.

Guías de configuración:

• Tamaño del búfer: Debe absorber las ráfagas de tráfico.
• Trabajadores: Número de gorutinas concurrentes que procesan rastreos.
• Tiempo de espera del canal: Cuánto tiempo esperar si el búfer está lleno. El tiempo de espera corto (500 ms) falla rápidamente por saturación
• Tiempo de espera de respuesta: Protege contra trabajadores atascados. Predeterminado: 10s es apropiado para operaciones normales de Redis
• Estrategia de hash: algoritmo para determinar la asignación de particiones de rastreo
• rendezvous (predeterminado): Proporciona una distribución de carga superior para 2-99 particiones. La mejor opción para implementaciones típicas.
• consistent: Mantiene el rendimiento cuando se utilizan más de 100 particiones donde el encuentro se vuelve lento. Compensa una distribución de carga ligeramente menos óptima para un mejor rendimiento a escala.
• Ambas estrategias aseguran que el mismo rastreo siempre se mapee a la misma partición (determinista)
• Elija el encuentro para una mejor distribución de la carga (hasta 99 particiones), consistente para el rendimiento a escala (100+)

Configuración de evaluación

Limitador de velocidad:

La opción rate_limiter controla el comportamiento de contrapresión cuando se alcanza el límite de rastreo concurrente (num_traces):

• false (predeterminado): Sin limitación de velocidad. El procesador acepta rastreos sin bloquear, confiando en Redis para el almacenamiento. Esta es la configuración recomendada para la mayoría de las implementaciones de Redis.
• true: Habilita un limitador de velocidad de bloqueo que aplica contrapresión cuando se procesan num_traces trazas concurrentes. Las nuevas trazas se bloquearán hasta que haya una ranura disponible.

Cuándo habilitar:

• Para evitar sobrecargar la red, la CPU y/o la memoria de Redis
• Para evitar abrumar a los consumidores posteriores con ráfagas repentinas de tráfico

Reintento y recuperación

Configuración de la política

Siguen las mismas reglas que en el muestreo de cola de código abierto.

Tiempos de espera del cliente Redis y grupo de conexiones

Todos los ajustes son opcionales y tienen valores predeterminados alineados con los 10 segundos ingestion_response_timeout.

Guías de ajuste:

• Redis de alta latencia (entre regiones, VPN): Aumente los tiempos de espera a 2-3 veces los valores predeterminados y reduzca max_retries a 2
• Redis muy rápido (mismo host/rack): Puede reducir aún más los tiempos de espera (por ejemplo, 250 ms) para una detección de fallos más rápida
• Alto rendimiento: Aumente pool_size a 30-50 para evitar el agotamiento del grupo de conexiones.
• Red poco confiable: Aumente max_retries a 5-7 y ajuste la configuración de retroceso

Opciones de réplica del clúster

La sección connection.replica controla el enrutamiento de réplicas del clúster.

Ejemplo de configuración completo

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}

Evaluación de trazas

Esta sección cubre los parámetros que controlan cuándo se evalúan los rastreos y cuánto tiempo persisten los datos en Redis.

Tiempo y frecuencia de evaluación

Cómo funciona la evaluación:

1. Cada evaluation_interval, los trabajadores comprueban si hay rastreos que han estado inactivos durante al menos trace_window_expiration
2. Se extraen hasta max_traces_per_batch rastreos de Redis por ciclo de evaluación
3. partition_workers evaluar lotes simultáneamente en todas las particiones

Guía de ajuste:

• Decisiones más rápidas: Disminuya evaluation_interval (por ejemplo, 500 ms) para una latencia más baja, pero aumenta la carga de Redis
• Mayor rendimiento: Aumenta max_traces_per_batch (por ejemplo, 5000-10000) para procesar más rastreos por ciclo
• Más paralelismo: aumente partition_workers para que coincida con los núcleos de CPU disponibles

TTL y vencimiento

Cómo funciona TTL en modo distribuido

Cuando se utiliza distributed_cache, el procesador implementa un sistema TTL de varias etapas que difiere del procesador en memoria:

Fases del ciclo de vida del rastreo:

1. Fase de recopilación: las spans llegan y se almacenan en Redis
2. Fase de evaluación: Después de trace_window_expiration, el rastreo está listo para la decisión de muestreo
3. Fase de retención: los datos de traza persisten durante traces_ttl para manejar reintentos y spans tardíos
4. Fase de caché: Las decisiones de muestreo persisten durante cache_ttl para evitar evaluaciones duplicadas

Por qué las TTL en cascada son importantes:

La jerarquía TTL garantiza la disponibilidad de datos durante todo el ciclo de vida del rastreo:

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 (más corto) controla cuándo comienza la evaluación
• in_flight_timeout (más corto) controla cuándo la evaluación está tardando demasiado y debe reintentarse
• cache_ttl (más largo) gestiona los spans que llegan tarde horas después de la evaluación
• traces_ttl (medio) proporciona un búfer para reintentos y recuperación de huérfanos

Los TTL configurados correctamente evitan la pérdida de datos, las evaluaciones duplicadas y los rastreos incompletos, a la vez que optimizan el uso de la memoria de Redis.

1. Ventana de recopilación de rastreo: trace_window_expiration

Predeterminado: 30s | Configuración: distributed_cache.trace_window_expiration

• Propósito: Controla cuándo un rastreo está listo para la evaluación de muestreo
• Comportamiento: Ventana deslizante que se restablece cada vez que llegan nuevos spans para una traza
• Ejemplo: Si una traza recibe spans en t=0s, t=15s y t=28s, la evaluación comienza en t=58s (ventana de 28s + 30s)

Guía de ajuste:

• Valores más cortos (15-20 s): decisiones de muestreo más rápidas, pero riesgo de trazas incompletas si los spans llegan lentamente
• Valores más largos (45-60s): Rastros más completos, pero mayor latencia y uso de memoria
• Rango típico: 20-45 segundos dependiendo de tus patrones de llegada de spans

2. Tiempo de espera de procesamiento por lotes: in_flight_timeout

Predeterminado: Igual que trace_window_expiration | Configuración: distributed_cache.in_flight_timeout

• Propósito: tiempo máximo que un lote puede estar en procesamiento antes de ser considerado huérfano
• Comportamiento: Evita la pérdida de datos si un recolector falla durante la evaluación
• Recuperación de huérfanos: los lotes que exceden este tiempo de espera se vuelven a poner en cola automáticamente para su evaluación por otro recopilador

Guía de ajuste:

• Debe ser ≥ trace_window_expiration: Garantiza suficiente tiempo para la evaluación normal

• Aumentar si: Sus políticas de evaluación son computacionalmente costosas (OTTL complejo, regex)

• Monitorear: otelcol_processor_tail_sampling_sampling_decision_timer_latency para asegurar que las evaluaciones se completen dentro de esta ventana

  Sugerencia

  Relación con trace_window_expiration: Establecer in_flight_timeout igual a trace_window_expiration funciona bien para la mayoría de las implementaciones. Aumente solo si observa recuperaciones de lotes huérfanos frecuentes debido a una evaluación de política lenta.

3. Retención de datos de rastreo: traces_ttl

Predeterminado: 5m | Configuración: distributed_cache.traces_ttl

• Propósito: Cuánto tiempo persisten los datos de intervalo de rastreo en Redis después del almacenamiento inicial
• Comportamiento: Proporciona tiempo de búfer para reintentos, intervalos tardíos y recuperación de huérfanos
• Restricción crítica: debe ser significativamente más largo que trace_window_expiration + in_flight_timeout

Fórmula recomendada:

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

Ejemplo con valores predeterminados:

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

Guía de ajuste:

• Con restricción de memoria: Use un TTL más corto (2-3m) pero corre el riesgo de perder datos para spans muy tardíos

• Tolerancia de span tardío: Usa un TTL más largo (10-15m) para manejar la llegada tardía de spans

• Producción estándar: 5-10 minutos proporciona un buen equilibrio

  Importante

  Demasiado corto = pérdida de datos: Si traces_ttl es demasiado corto, los rastreos pueden eliminarse antes de que se complete la evaluación, especialmente durante los reintentos o la recuperación de huérfanos. Esto da como resultado rastreos parciales o faltantes.

4. Retención de la caché de decisiones: cache_ttl

Predeterminado: 30m | Configuración: distributed_cache.cache_ttl

• Propósito: Cuánto tiempo se almacenan en caché las decisiones de muestreo (muestreado/no muestreado)
• Comportamiento: Evita la evaluación duplicada cuando los spans tardíos llegan después de que se ha evaluado el rastreo
• Restricción crítica: Debe ser mucho más largo que traces_ttl

Fórmula recomendada:

cache_ttl ≥ traces_ttl × 6

¿Por qué mucho más largo?

• Los spans que llegan tarde pueden llegar minutos u horas después de que se completó el rastreo
• La caché de decisiones evita la reevaluación de rastreos cuando llegan spans muy tardíos
• Sin una decisión en caché, los spans tardíos se evaluarían como rastreos incompletos (decisión de muestreo incorrecta)

Guía de ajuste:

• Producción estándar: 30m-2h equilibra el uso de la memoria y el manejo de spans tardíos
• Alta tasa de spans tardíos: 2-4 horas asegura que las decisiones persistan para datos muy retrasados
• Con restricción de memoria: Mínimo 15-30m, pero espere más evaluaciones duplicadas

Impacto en la memoria:

• Cada decisión: ~50 bytes por ID de traza

• A 10,000 spans/segundo con 20 spans/traza → 500 trazas/segundo

• Caché de 30 minutos: ~900,000 decisiones × 50 bytes = ~45 MB

• Caché de 2 horas: ~3.6M decisiones × 50 bytes = ~180 MB

  Sugerencia

  Supervisar la efectividad de la caché: Rastree la métrica otelcol_processor_tail_sampling_early_releases_from_cache_decision. Los valores altos indican que la caché está evitando eficazmente las evaluaciones duplicadas.

Ejemplos de configuración TTL

Baja latencia, con memoria limitada:

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

Tolerante a alto rendimiento y de último lapso:

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

Producción equilibrada (recomendado):

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

Reintento y recuperación

Recuperación de huérfanos:

Los lotes huérfanos ocurren cuando un recolector se bloquea a mitad de la evaluación. El proceso de recuperación de huérfanos se ejecuta cada recover_interval y:

1. Identifica los lotes que han excedido in_flight_timeout
2. Vuelve a poner en cola estos rastreos para su evaluación por otra instancia del recopilador
3. Garantiza que no se pierdan trazas debido a fallas del recolector

Guía de ajuste:

• Aumentar max_retries (3-5) si experimenta errores transitorios de Redis
• Disminuir recover_interval (2-3 s) para una recuperación más rápida en entornos de alta disponibilidad
• Monitoree las métricas de recuperación para identificar si los recolectores se bloquean con frecuencia

Particionamiento y escalado

¿Qué es una partición?

Una partición es una partición lógica de datos de traza en Redis que permite el procesamiento paralelo y el escalado horizontal. Piense en las particiones como colas separadas donde las trazas se distribuyen en función de su ID de traza.

Conceptos clave:

• Cada partición mantiene su propia cola de trazas pendientes en Redis

• Las trazas se asignan a las particiones utilizando una estrategia de hashing configurable (rendezvous o consistente) en el ID de la traza

• Cada partición se puede procesar de forma independiente y simultánea

• Las particiones permiten tanto el escalado vertical (más núcleos de CPU) como el escalado horizontal (más instancias de recopilador)

  Advertencia

  Importante: Cambiar el número de particiones cuando ya hay un clúster en ejecución causará rastreos fragmentados, ya que los rastreos podrían enrutarse a otra partición después del cambio.

Cómo funciona el particionamiento

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

Flujo:

1. Ingesta: El ID de rastreo se somete a hashing utilizando la estrategia de hashing configurada para determinar la asignación de particiones
2. Almacenamiento: datos de rastreo almacenados en Redis bajo claves específicas de partición
3. Evaluación: El trabajador asignado a esa partición extrae y evalúa los rastros
4. Concurrencia: Todos los trabajadores de partición se ejecutan en paralelo, procesando diferentes rastreos simultáneamente

Estrategia de hashing

El procesador admite dos algoritmos de hash para la selección de particiones. La elección depende del número de particiones:

Parámetros de configuración de partición

Utilice partitions para controlar cuántos fragmentos lógicos tiene y partition_workers para establecer cuántos trabajadores los procesan:

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

Comportamiento del trabajador:

• 8 particiones + 8 trabajadores: Cada trabajador procesa una partición cada evaluation_interval ✅ Equilibrado
• 8 particiones + 16 trabajadores: Cada partición se evalúa dos veces por intervalo (redundante, desperdicia recursos)
• 8 particiones + 4 trabajadores: Solo la mitad de las particiones evaluadas por intervalo (más lento, pero menos carga de Redis)

Directrices de dimensionamiento de particiones

Ejemplos de configuración de particiones

Un solo recolector (máquina de 4 núcleos):

distributed_cache:
  partitions: 4
  partition_workers: 4
  partition_buffer_max_traces: 5000

Recopilador múltiple (3 instancias, 8 núcleos cada una):

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

Alto volumen (más de 10 recolectores):

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

Dimensionamiento y rendimiento

Ejemplo: supongamos los siguientes parámetros

• Spans por segundo: asume un rendimiento de 10,000 spans/seg
• Tamaño de tramo promedio: 900 bytes

1. Requisitos de red

Cálculos de ancho de banda:

Para 10,000 spans/segundo a 900 bytes por span:

• Tráfico de ingestión (recopiladores → Redis): 10,000 × 900 bytes = 9 MB/sec = ~72 Mbps
• Tráfico de evaluación (Redis → recolectores): ~9 MB/sec = ~72 Mbps (lectura de trazas para la evaluación)
• Bidireccional total: ~18 MB/sec = ~144 Mbps

Con 25% de compresión (snappy/lz4):

• Tráfico comprimido: ~108 Mbps bidireccional

Directrices de red:

• Supervisar el uso de la red Redis: Una instancia típica de redis puede manejar hasta 1 GBs, asegúrese de supervisar el uso de la red
• Usar compresión: Reduce la cantidad de tráfico de red a cambio del uso de la CPU en los recopiladores
• Co-localizado (mismo centro de datos/VPC): las interfaces de red de 1 Gbps son suficientes para la mayoría de las cargas de trabajo
• Entre regiones: Espere una latencia de 10-50 ms; aumente los tiempos de espera y use la compresión para reducir el ancho de banda
• Agrupación de conexiones: Aumentar para un mayor rendimiento
• Usar réplicas: Si el clúster tiene réplicas de lectura, se utilizarán de forma predeterminada. Reducción del uso de la red y la CPU en los nodos maestros

2. Requisitos de CPU

Directrices de CPU:

• Instancia única de Redis: Mínimo 4 vCPUs

• Clúster Redis: 3+ nodos con réplicas de lectura con 4 vCPUs cada uno para un alto rendimiento.

• Usar réplicas: Si el clúster tiene réplicas de lectura, se utilizarán de forma predeterminada. Reducción del uso de la red y la CPU en los nodos maestros

  Sugerencia

  Monitoreo de la CPU: Esté atento a la saturación de la CPU (más del 80 % de utilización) como el primer indicador de las necesidades de escalado. Si está limitado por la CPU, agregue nodos de clúster

3. Requisitos de memoria

Si bien la memoria es menos restrictiva que la CPU y la red, el dimensionamiento adecuado evita las expulsiones y garantiza la disponibilidad de los datos.

Fórmula de estimación de memoria

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

Almacenamiento de datos de rastreo

Los datos de traza se almacenan en Redis durante todo el periodo traces_ttl para respaldar los tramos de llegada tardía y la recuperación de traza:

• Almacenamiento por tramo: ~900 bytes (protobuf serializado)

• Duración del almacenamiento: controlada por traces_ttl (predeterminado: 1 hora)

• Ventana de recopilación activa: controlada por trace_window_expiration (predeterminado: 30 s)

• Fórmula: Memory ≈ spans_per_second × traces_ttl × 900 bytes

  Importante

  Ventana activa vs. retención completa: los datos se recopilan durante una ventana activa ~30-second (trace_window_expiration), pero persisten en Redis durante el periodo completo de 1 hora traces_ttl. Esto permite que el procesador gestione tramos que llegan tarde y recupere trazas huérfanas. El tamaño de Redis debe tener en cuenta el periodo de retención completo, no solo la ventana activa.

Ejemplo de cálculo: A 10 000 intervalos/segundo con 1 hora traces_ttl:

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

Con compresión lz4 (observamos una reducción del 25%):

32.4 GB × 0.75 = 24.3 GB

Nota: Este cálculo representa el consumidor principal de memoria. La memoria Redis real puede ser ligeramente mayor debido a los cachés de decisiones y las estructuras de datos internas.

Almacenamiento de caché de decisiones

Al emplear distributed_cache, los cachés de decisiones se almacenan en Redis sin límites de tamaño explícitos. En su lugar, Redis emplea su política de desalojo LRU nativa (configurada a través de maxmemory-policy) para gestionar la memoria. Cada ID de traza requiere aproximadamente 50 bytes de almacenamiento:

• Caché muestreada: gestionada por Redis LRU eviction

• Caché no muestreada: gestionada por el desalojo de LRU de Redis

• Gastos generales típicos por ID de traza: ~50 bytes

  Sugerencia

  Gestión de memoria: configure Redis con maxmemory-policy allkeys-lru para permitir el desalojo automático de entradas de caché de decisiones antiguas cuando se alcanzan los límites de memoria. Las claves de caché de decisiones emplean una expiración basada en TTL (controlada por cache_ttl) en lugar de límites de tamaño fijos.

Gastos generales del procesamiento por lotes

• Cola de lotes actual: Mínima (ID de traza + puntajes en el conjunto ordenado)
• Lotes en vuelo: max_traces_per_batch × average_spans_per_trace × 900 bytes

Ejemplo de cálculo: 500 trazas por lote (predeterminado) con 20 tramos por traza en promedio:

500 × 20 × 900 bytes = 9 MB per batch

El tamaño del lote afecta el uso de memoria durante la evaluación. La memoria por lotes en vuelo es temporal y se libera una vez finalizado el procesamiento.

Arquitectura de configuración predeterminada

Los valores de configuración predeterminados están diseñados para una implementación de referencia que admite 1 millón de spans por minuto (~16,000 spans/seg):

Implementación del recolector:

• 3 instancias de recopilador
• 4 vCPUs por instancia
• 8 GB de RAM por instancia

Clúster Redis:

• 3 instancias de Redis (AWS cache.r6g.xlarge: 4 vCPUs, 25.01 GiB de memoria cada una)
• Configurado como un clúster para alta disponibilidad y distribución de carga
• Co-localizado con recolectores para acceso de baja latencia

Esta arquitectura de referencia proporciona un punto de partida para las implementaciones de producción. Ajuste según sus requisitos reales de rendimiento y latencia.

Referencia de métricas

El procesador de muestreo de cola emite las siguientes métricas en modo distribuido Redis para ayudarte a monitorear el rendimiento y diagnosticar problemas.

Métricas disponibles

Detalles de la dimensión

• policy: Nombre de la política de muestreo que tomó la decisión
• sampled: Si la decisión fue muestrear (true/false)
• decision: El tipo de decisión de muestreo (sampled, not_sampled, dropped)
• deleted: Si la eliminación fue exitosa (true/false)
• partition: Identificador de partición (hash codificado en hexadecimal, por ejemplo, {a1b2c3d4...}) - garantiza la compatibilidad con la etiqueta hash del clúster Redis
• processor: Identificador de instancia del procesador (de la configuración distributed_cache.processor_name)

Requisitos de caché compatibles con Redis

El procesador emplea la caché como almacenamiento distribuido para los siguientes datos traza:

• traza y span atributo
• Datos de traza activos
• Caché de decisiones de ejemplificación

El procesador ejecuta el script Lua para interactuar con el caché Redis de forma atómica. La compatibilidad script Lua normalmente está habilitada de forma predeterminada en los cachés compatibles con Redis. No se requiere ninguna configuración adicional a menos que desactivó explícitamente esta función.