Traga seu próprio cache

O Infinite Tracing Processor da New Relic é uma implementação do OpenTelemetry Collector tailsamplingprocessor. Além dos recursos upstream, ele oferece suporte a processamento distribuído escalável e durável usando um cache distribuído para armazenamento de estado compartilhado. Esta documentação mostra como configurá-lo

Caches suportados

O processador suporta qualquer implementação de cache compatível com Redis. Foi testado e validado com Redis e Valkey em configurações de instância única e cluster. Para implantações de produção, recomendamos o uso do modo cluster (fragmentado) para garantir alta disponibilidade e escalabilidade. Para habilitar o cache distribuído, adicione a configuração distributed_cache à sua seção do processador 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

O parâmetro address deve especificar um endereço de servidor válido e compatível com o Redis, usando o formato padrão:

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

Alternativamente, você pode incorporar as credenciais diretamente no parâmetro address :

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

O processador é implementado em Go e utiliza a biblioteca cliente go-redis.

Parâmetro de configuração

A seção distributed_cache suporta o seguinte parâmetro:

Configurações de conexão

Compressão de dados

Gerenciamento de rastreamento

Diretrizes de TTL:

• traces_ttl deve ser longo o suficiente para lidar com novas tentativas e spans tardios
• cache_ttl deve ser muito maior que traces_ttl para lidar com spans que chegam atrasados
• Um cache_ttl mais longo reduz avaliações duplicadas, mas aumenta o uso de memória do Redis

Particionamento

Benefícios do particionamento:

• Distribui a carga em vários intervalos de chaves Redis
• Permite a avaliação paralela em vários workers
• Melhora a taxa de transferência em implantações multi-coletor

Configurações de ingestão

Arquitetura de ingestão:

O processador usa um canal compartilhado com workers configuráveis para ingestão de rastreios:

1. Os rastreamentos de entrada são enviados para um canal compartilhado em buffer
2. Vários workers puxam do canal e roteiam rastreamentos para as partições apropriadas
3. Workers fazem hash dos IDs de rastreio usando a estratégia de hash configurada para determinar a atribuição da partição

Diretrizes de configuração:

• Tamanho do buffer: Deve absorver picos de tráfego.
• Workers: Número de goroutines simultâneas processando rastreios.
• Tempo limite do canal: Quanto tempo esperar se o buffer estiver cheio. Tempo limite curto (500ms) falha rapidamente em caso de saturação
• Tempo limite da resposta: Protege contra workers travados. Padrão: 10s é apropriado para operações normais do Redis
• Estratégia de hashing: Algoritmo para determinar a atribuição de partição de rastreamento
• rendezvous (padrão): Fornece distribuição de carga superior para 2-99 partições. Melhor opção para implantações típicas.
• consistent: Mantém o desempenho ao usar mais de 100 partições, onde o rendezvous se torna lento. Troca uma distribuição de carga ligeiramente menos otimizada por melhor desempenho em escala.
• Ambas as estratégias garantem que o mesmo rastreamento sempre mapeie para a mesma partição (determinístico)
• Escolha rendezvous para melhor distribuição de carga (até 99 partições), consistente para desempenho em escala (100+)

Configurações de avaliação

Limitador de taxa:

A opção rate_limiter controla o comportamento de backpressure quando o limite de rastreamento simultâneo (num_traces) é atingido:

• false (padrão): Sem limitação de taxa. O processador aceita rastreamentos sem bloqueio, contando com o Redis para armazenamento. Esta é a configuração recomendada para a maioria das implantações do Redis.
• true: Habilita um limitador de taxa de bloqueio que aplica backpressure quando num_traces traces simultâneos estão sendo processados. Novos traces serão bloqueados até que um slot fique disponível.

Quando habilitar:

• Para evitar sobrecarregar a rede, CPU e/ou memória do Redis
• Para evitar sobrecarregar os consumidores downstream com rajadas repentinas de tráfego

Tentar novamente e recuperação

Configuração da política

Eles seguem as mesmas regras do tail sampling de código aberto.

Tempos limite do cliente Redis e pool de conexões

Todas as configurações são opcionais e têm padrões alinhados com os 10s ingestion_response_timeout.

Diretrizes de ajuste:

• Redis de alta latência (cross-region, VPN): Aumente os tempos limite para 2-3x os padrões e reduza max_retries para 2
• Redis muito rápido (mesmo host/rack): Pode reduzir ainda mais os timeouts (por exemplo, 250ms) para uma detecção de falhas mais rápida
• Alta taxa de transferência: Aumente pool_size para 30-50 para evitar o esgotamento do pool de conexões
• Rede não confiável: Aumente max_retries para 5-7 e ajuste as configurações de backoff

Opções de réplica do cluster

A seção connection.replica controla o roteamento de réplicas do cluster.

Exemplo de configuração completa

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}

Avaliação de rastreamento

Esta seção aborda os parâmetros que controlam quando os rastreamentos são avaliados e por quanto tempo os dados persistem no Redis.

Tempo e frequência de avaliação

Como a avaliação funciona:

1. A cada evaluation_interval, os workers verificam rastreamentos que estão ociosos por pelo menos trace_window_expiration
2. Até max_traces_per_batch rastreios são extraídos do Redis por ciclo de avaliação
3. partition_workers avaliar lotes simultaneamente em várias partições

Orientação de ajuste:

• Decisões mais rápidas: Diminua evaluation_interval (por exemplo, 500ms) para menor latência, mas aumenta a carga do Redis
• Maior taxa de transferência: Aumente max_traces_per_batch (por exemplo, 5000-10000) para processar mais rastreios por ciclo
• Mais paralelismo: Aumente partition_workers para corresponder aos núcleos de CPU disponíveis

TTL e expiração

Como o TTL funciona no modo distribuído

Ao usar distributed_cache, o processador implementa um sistema TTL de vários estágios que difere do processador na memória:

Estágios do ciclo de vida do rastreamento:

1. Fase de coleta: os spans chegam e são armazenados no Redis
2. Fase de avaliação: Após trace_window_expiration, o rastreamento está pronto para a decisão de amostragem
3. Fase de retenção: Os dados de rastreamento persistem por traces_ttl para lidar com novas tentativas e spans tardios
4. Fase de cache: As decisões de amostragem persistem por cache_ttl para evitar avaliações duplicadas

Por que os TTLs em cascata são importantes:

A hierarquia TTL garante a disponibilidade de dados durante todo o ciclo de vida do rastreio:

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 (mais curto) controla quando a avaliação começa
• in_flight_timeout (menor) controla quando a avaliação está demorando muito e deve ser repetida
• cache_ttl (mais longo) lida com spans que chegam tardiamente horas após a avaliação
• traces_ttl (médio) fornece buffer para novas tentativas e recuperação de órfãos

Os TTLs configurados corretamente evitam a perda de dados, avaliações duplicadas e rastreamentos incompletos, otimizando o uso da memória Redis.

1. Janela de coleta de rastreamento: trace_window_expiration

Padrão: 30s | Configuração: distributed_cache.trace_window_expiration

• Finalidade: Controla quando um rastreio está pronto para avaliação de amostragem
• Comportamento: Janela deslizante que redefine cada vez que novos spans chegam para um rastreamento
• Exemplo: Se um rastreamento receber spans em t=0s, t=15s e t=28s, a avaliação começa em t=58s (janela de 28s + 30s)

Orientação de ajuste:

• Valores mais curtos (15-20s): Decisões de amostragem mais rápidas, mas risco de rastreios incompletos se os spans chegarem lentamente
• Valores mais longos (45-60s): rastreamentos mais completos, mas maior latência e uso de memória
• Intervalo típico: 20-45 segundos, dependendo dos seus padrões de chegada de span

2. Tempo limite de processamento em lote: in_flight_timeout

Padrão: Igual a trace_window_expiration | Configuração: distributed_cache.in_flight_timeout

• Propósito: Tempo máximo que um lote pode estar em processamento antes de ser considerado órfão
• Comportamento: Evita a perda de dados se um coletor falhar durante a avaliação
• Recuperação de órfãos: Lotes que excedem este tempo limite são automaticamente reenfileirados para avaliação por outro coletor

Orientação de ajuste:

• Deve ser ≥ trace_window_expiration: Garante tempo suficiente para avaliação normal

• Aumente se: Suas políticas de avaliação são computacionalmente caras (OTTL complexo, regex)

• Monitorar: otelcol_processor_tail_sampling_sampling_decision_timer_latency para garantir que as avaliações sejam concluídas dentro desta janela

  Dica

  Relação com trace_window_expiration: Definir in_flight_timeout igual a trace_window_expiration funciona bem para a maioria das implantações. Aumente somente se observar recuperações frequentes de lotes órfãos devido à avaliação lenta da política.

3. Retenção de dados de rastreamento: traces_ttl

Padrão: 5m | Configuração: distributed_cache.traces_ttl

• Finalidade: Quanto tempo os dados de span de rastreamento persistem no Redis após o armazenamento inicial
• Comportamento: Fornece tempo de buffer para novas tentativas, spans tardios e recuperação de órfãos
• Restrição crítica: Deve ser significativamente maior que trace_window_expiration + in_flight_timeout

Fórmula recomendada:

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

Exemplo com padrões:

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

Orientação de ajuste:

• Restrito por memória: Use TTL mais curto (2-3m), mas corra o risco de perder dados para spans muito tardios

• Tolerância a span tardios: Use um TTL mais longo (10-15m) para lidar com a chegada de span atrasados

• Produção padrão: 5-10 minutos oferece um bom equilíbrio

  Importante

  Muito curto = perda de dados: Se traces_ttl for muito curto, os rastreamentos podem ser excluídos antes que a avaliação seja concluída, especialmente durante as tentativas ou a recuperação de órfãos. Isso resulta em rastreamentos parciais ou ausentes.

4. Retenção do cache de decisão: cache_ttl

Padrão: 30m | Configuração: distributed_cache.cache_ttl

• Finalidade: Por quanto tempo as decisões de amostragem (amostrado/não amostrado) são armazenadas em cache
• Comportamento: Impede a avaliação duplicada quando spans tardios chegam após a avaliação do rastreamento
• Restrição crítica: Deve ser muito maior que traces_ttl

Fórmula recomendada:

cache_ttl ≥ traces_ttl × 6

Por que muito maior?

• Spans tardios podem chegar minutos ou horas após a conclusão do rastreamento
• O cache de decisão impede a reavaliação de rastreamentos quando spans muito tardios chegam
• Sem a decisão em cache, os spans tardios seriam avaliados como rastreamentos incompletos (decisão de amostragem incorreta)

Orientação de ajuste:

• Produção padrão: 30m-2h equilibra o uso de memória e o tratamento de spans tardios
• Alta taxa de spans tardios: 2-4h garante que as decisões persistam para dados muito atrasados
• Com restrição de memória: mínimo de 15-30m, mas espere mais avaliações duplicadas

Impacto na memória:

• Cada decisão: ~50 bytes por ID de rastreamento

• A 10.000 spans/seg com 20 spans/rastreamento → 500 rastreamentos/seg

• Cache de 30 minutos: ~900.000 decisões × 50 bytes = ~45 MB

• Cache de 2 horas: ~3,6 milhões de decisões × 50 bytes = ~180 MB

  Dica

  Monitorar a eficácia do cache: Acompanhe a métrica otelcol_processor_tail_sampling_early_releases_from_cache_decision. Valores altos indicam que o cache está impedindo avaliações duplicadas de forma eficaz.

Exemplos de configuração de TTL

Baixa latência, com restrição de memória:

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 throughput e spans tardios:

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

Produção balanceada (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

Tentar novamente e recuperação

Recuperação de órfãos:

Lotes órfãos ocorrem quando um coletor trava no meio da avaliação. O processo de recuperação de órfãos é executado a cada recover_interval e:

1. Identifica lotes que excederam in_flight_timeout
2. Reenvia esses rastreamentos para avaliação por outra instância do coletor
3. Garante que nenhum rastreio seja perdido devido a falhas do coletor

Orientação de ajuste:

• Aumentar max_retries (3-5) se estiver enfrentando erros transitórios do Redis
• Diminuir recover_interval (2-3s) para uma recuperação mais rápida em ambientes de alta disponibilidade
• Monitorar métricas de recuperação para identificar se os coletores estão travando com frequência

Particionamento e dimensionamento

O que é uma partição?

Uma partição é um shard lógico de dados de rastreamento no Redis que permite o processamento paralelo e o dimensionamento horizontal. Pense nas partições como filas separadas onde os rastreamentos são distribuídos com base em seu ID de rastreamento.

Conceitos-chave:

• Cada partição mantém sua própria fila de rastreios pendentes no Redis

• Os rastreios são atribuídos a partições usando uma estratégia de hash configurável (rendezvous ou consistente) no ID do rastreio

• Cada partição pode ser processada de forma independente e simultânea

• As partições permitem escalonamento vertical (mais núcleos de CPU) e escalonamento horizontal (mais instâncias de coletor)

  Cuidado

  Importante: Alterar o número de partições quando já houver um cluster em execução causará rastreamentos fragmentados, pois os rastreamentos podem ser roteados para outra partição após a alteração.

Como o particionamento funciona

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

Fluxo:

1. Ingestão: O ID do rastreamento é submetido a hash usando a estratégia de hash configurada para determinar a atribuição da partição
2. Armazenamento: Dados de rastreamento armazenados no Redis em chaves específicas da partição
3. Avaliação: Trabalhador atribuído a essa partição puxa e avalia rastreamentos
4. Concorrência: Todos os workers de partição são executados em paralelo, processando rastreamentos diferentes simultaneamente

Estratégia de hashing

O processador suporta dois algoritmos de hashing para seleção de partição. A escolha depende do número de partições:

Parâmetros de configuração de partição

Use partitions para controlar quantos shards lógicos você tem e partition_workers para definir quantos workers os processam:

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

Comportamento do worker:

• 8 partições + 8 workers: Cada worker processa uma partição a cada evaluation_interval ✅ Balanceado
• 8 partições + 16 workers: Cada partição avaliada duas vezes por intervalo (redundante, desperdiça recursos)
• 8 partições + 4 workers: Apenas metade das partições avaliadas por intervalo (mais lento, mas menos carga do Redis)

Diretrizes de dimensionamento de partição

Exemplos de configuração de partição

Coletor único (máquina de 4 núcleos):

distributed_cache:
  partitions: 4
  partition_workers: 4
  partition_buffer_max_traces: 5000

Multi-coletor (3 instâncias, 8 núcleos cada):

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

Alto volume (mais de 10 coletores):

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

Dimensionamento e desempenho

Exemplo: assuma os seguintes parâmetros

• Spans por segundo: assume 10.000 spans/seg de throughput
• Tamanho médio do intervalo: 900 bytes

1. Requisitos de rede

Cálculos de largura de banda:

Para 10.000 spans/segundo a 900 bytes por span:

• Tráfego de ingestão (coletores → Redis): 10,000 × 900 bytes = 9 MB/sec = ~72 Mbps
• Tráfego de avaliação (Redis → coletores): ~9 MB/sec = ~72 Mbps (lendo rastreios para avaliação)
• Total bidirecional: ~18 MB/sec = ~144 Mbps

Com 25% de compressão (snappy/lz4):

• Tráfego comprimido: ~108 Mbps bidirecional

Diretrizes de rede:

• Monitorar o uso da rede Redis: Uma instância típica do Redis pode lidar com até 1 GB/s, certifique-se de monitorar o uso da rede
• Usar compressão: Reduz a quantidade de tráfego de rede em troca do uso da CPU nos coletores
• Co-localizado (mesmo data center/VPC): interfaces de rede de 1 Gbps são suficientes para a maioria das cargas de trabalho
• Entre regiões: Espere latência de 10-50ms - aumente os tempos limite e use a compressão para reduzir a largura de banda
• Pool de conexões: Aumente para maior throughput
• Usar réplicas: Se o cluster tiver réplicas de leitura, elas serão usadas por padrão. Reduzindo o uso da rede e da CPU em nós mestres

2. Requisitos de CPU

Diretrizes de CPU:

• Instância Redis única: Mínimo de 4 vCPUs

• Cluster Redis: 3+ nós com réplicas de leitura com 4 vCPUs cada para alta vazão.

• Usar réplicas: Se o cluster tiver réplicas de leitura, elas serão usadas por padrão. Reduzindo o uso da rede e da CPU em nós mestres

  Dica

  Monitoramento da CPU: Observe a saturação da CPU (mais de 80% de utilização) como o primeiro indicador das necessidades de dimensionamento. Se limitado pela CPU, adicione nós de cluster

3. Requisitos de memória

Embora a memória seja menos restrita do que CPU e rede, o dimensionamento adequado impede despejos e garante a disponibilidade de dados.

Fórmula de estimativa de memória

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

Armazenamento de dados de rastreamento

Os dados de rastreamento são armazenados no Redis durante todo o período traces_ttl para suportar intervalos que chegam com atraso e recuperação trace :

• Armazenamento por intervalo: ~900 bytes (protobuf serializado)

• Duração do armazenamento: Controlada por traces_ttl (padrão: 1 hora)

• Janela de coleta ativa: Controlada por trace_window_expiration (padrão: 30s)

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

  Importante

  Janela ativa vs. retenção total: os traços são coletados durante uma janela ativa ~30-second (trace_window_expiration), mas persistem no Redis durante todo o período de 1 hora traces_ttl. Isso permite que o processador lide com intervalos que chegam com atraso e recupere traços órfãos. O dimensionamento do seu Redis deve levar em consideração todo o período de retenção, e não apenas a janela ativa.

Exemplo de cálculo: A 10.000 vãos/segundo com 1 hora traces_ttl:

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

Com compressão lz4 (observamos uma redução de 25%):

32.4 GB × 0.75 = 24.3 GB

Nota: Este cálculo representa o principal consumidor de memória. O consumo real de memória do Redis pode ser ligeiramente maior devido aos caches de decisão e às estruturas de dados internas.

Armazenamento em cache de decisão

Ao usar distributed_cache, os caches de decisão são armazenados no Redis sem limites de tamanho explícitos. Em vez disso, o Redis usa sua política de remoção LRU nativa (configurada via maxmemory-policy) para gerenciar a memória. Cada ID trace requer aproximadamente 50 bytes de armazenamento:

• Cache amostrado: gerenciado pelo Redis com remoção LRU.

• Cache não amostrado: gerenciado pelo processo de remoção LRU do Redis.

• Sobrecarga típica por ID trace : ~50 bytes

  Dica

  gerenciamento de memória: Configure Redis com maxmemory-policy allkeys-lru para permitir a remoção automática de entradas antigas do cache de decisão quando os limites de memória forem atingidos. As chaves do cache de decisão usam expiração baseada em TTL (controlada por cache_ttl) em vez de limites de tamanho fixos.

Sobrecarga de processamento em lote

• Fila de lotes atual: Mínima (IDs trace + pontuações no conjunto ordenado)
• Lotes a bordo: max_traces_per_batch × average_spans_per_trace × 900 bytes

Exemplo de cálculo: 500 traços por lote (padrão) com 20 intervalos por trace em média:

500 × 20 × 900 bytes = 9 MB per batch

O tamanho do lote influencia o uso de memória durante a avaliação. A memória de processamento em lote durante o voo é temporária e liberada após a conclusão do processamento.

Arquitetura de configuração padrão

Os valores de configuração padrão são projetados para uma implantação de referência que suporta 1 milhão de spans por minuto (~16.000 spans/seg):

Implantação do coletor:

• 3 instâncias do coletor
• 4 vCPUs por instância
• 8 GB de RAM por instância

Cluster Redis:

• 3 instâncias Redis (AWS cache.r6g.xlarge: 4 vCPUs, 25,01 GiB de memória cada)
• Configurado como um cluster para alta disponibilidade e distribuição de carga
• Co-localizado com coletores para acesso de baixa latência

Esta arquitetura de referência fornece um ponto de partida para implantações de produção. Ajuste com base em seus requisitos reais de taxa de transferência e latência.

Referência de métricas

O processador de amostragem de cauda emite as seguintes métricas no modo distribuído Redis para ajudá-lo a monitorar o desempenho e diagnosticar problemas.

Métricas disponíveis

Detalhes da dimensão

• policy: Nome da política de amostragem que tomou a decisão
• sampled: Se a decisão foi amostrar (true/false)
• decision: O tipo de decisão de amostragem (sampled, not_sampled, dropped)
• deleted: Se a exclusão foi bem-sucedida (true/false)
• partition: Identificador de partição (hash codificado em hexadecimal, por exemplo, {a1b2c3d4...}) - garante a compatibilidade da tag de hash do Redis Cluster
• processor: Identificador da instância do processador (da configuração distributed_cache.processor_name)

Requisitos de cache compatíveis com Redis

O processador utiliza o cache como armazenamento distribuído para os seguintes dados trace :

• atributo de rastreamento e extensão
• Dados trace ativos
• Cache de decisão de amostragem

O processador executa um script Lua para interagir atomicamente com o cache Redis. O suporte script Lua geralmente está habilitado por padrão em caches compatíveis com Redis. Nenhuma configuração adicional é necessária, a menos que você tenha desativado explicitamente esse recurso.