Apportez votre propre cache

Le processeur Infinite Tracing de New Relic est une implémentation du collecteur OpenTelemetry tailsamplingprocessor. En plus des fonctionnalités en amont, il prend en charge le traitement distribué évolutif et durable en utilisant un cache distribué pour le stockage d'état partagé. Cette documentation explique comment le configurer.

Caches pris en charge

Le processeur prend en charge toute implémentation de cache compatible avec Redis. Il a été testé et validé avec Redis et Valkey dans les configurations à instance unique et en cluster. Pour les déploiements en production, nous recommandons d'utiliser le mode cluster (sharded) pour garantir une haute disponibilité et une évolutivité. Pour activer la mise en cache distribuée, ajoutez la configuration distributed_cache à votre section de processeur 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

Le paramètre address doit spécifier une adresse de serveur compatible Redis valide au format standard :

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

Vous pouvez également intégrer directement les informations d'identification dans le paramètre address :

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

Le processeur est implémenté en Go et utilise la bibliothèque cliente go-redis.

Paramètres de configuration

La section distributed_cache prend en charge les paramètres suivants :

Paramètres de connexion

Compression des données

Gestion des traces

Consignes TTL :

• traces_ttl doit être suffisamment long pour gérer les nouvelles tentatives et les spans tardifs
• cache_ttl devrait être beaucoup plus long que traces_ttl pour gérer les spans arrivant tardivement
• Une cache_ttl plus longue réduit les évaluations en double, mais augmente l'utilisation de la mémoire Redis

Partitionnement

Avantages du partitionnement:

• Répartit la charge sur plusieurs plages de clés Redis
• Permet une évaluation parallèle sur plusieurs workers
• Améliore le débit dans les déploiements multi-collecteurs

Paramètres d'ingestion

Architecture d'ingestion :

Le processeur utilise un canal partagé avec des workers configurables pour l'ingestion des traces :

1. Les traces entrantes sont envoyées à un canal tampon partagé
2. Plusieurs workers tirent du canal et routent les traces vers les partitions appropriées
3. Les workers hachent les ID de trace en utilisant la stratégie de hachage configurée pour déterminer l'affectation des partitions.

Consignes de configuration :

• Taille du tampon : Doit absorber les pics de trafic.
• Workers : Nombre de goroutines simultanées traitant les traces.
• Délai d'attente du canal: Durée d'attente si la mémoire tampon est pleine. Un court délai d'attente (500 ms) échoue rapidement en cas de saturation
• Délai d'attente de la réponse: Protège contre les workers bloqués. Par défaut : 10 s est approprié pour les opérations Redis normales
• Stratégie de hachage: Algorithme pour déterminer l'affectation des partitions de trace
• rendezvous (par défaut) : Fournit une répartition de charge supérieure pour 2 à 99 partitions. Meilleur choix pour les déploiements typiques.
• consistent: Maintient les performances lors de l'utilisation de plus de 100 partitions où le rendez-vous devient lent. Compense une répartition de la charge légèrement moins optimale pour de meilleures performances à grande échelle.
• Les deux stratégies garantissent que la même trace est toujours mappée à la même partition (déterministe)
• Choisissez le rendez-vous pour une meilleure répartition de la charge (jusqu'à 99 partitions), cohérent pour les performances à l'échelle (100+)

Paramètres d'évaluation

Limiteur de débit :

L'option rate_limiter contrôle le comportement de la contre-pression lorsque la limite de traces simultanées (num_traces) est atteinte :

• false (par défaut): Pas de limitation de débit. Le processeur accepte les traces sans blocage, en s'appuyant sur Redis pour le stockage. C'est le paramètre recommandé pour la plupart des déploiements Redis.
• true: Active un limiteur de débit bloquant qui applique une contre-pression lorsque num_traces traces simultanées sont traitées. Les nouvelles traces seront bloquées jusqu'à ce qu'un emplacement devienne disponible.

Quand activer :

• Pour éviter de surcharger le réseau, le processeur et/ou la mémoire Redis
• Pour éviter de submerger les consommateurs en aval avec des pics de trafic soudains

Nouvelle tentative et récupération

Configuration de la politique

Elles suivent les mêmes règles que dans le tail sampling open source.

Délais d'attente du client Redis et pool de connexions

Tous les paramètres sont facultatifs et ont des valeurs par défaut alignées sur les 10s ingestion_response_timeout.

Conseils de réglage :

• Redis à haute latence (inter-régions, VPN) : Augmentez les délais d'attente à 2-3 fois la valeur par défaut et réduisez max_retries à 2
• Redis très rapide (même hôte/rack) : Peut réduire davantage les délais d'attente (par exemple, 250 ms) pour une détection plus rapide des défaillances
• Haut débit: Augmentez pool_size à 30-50 pour éviter l'épuisement du pool de connexions
• Réseau non fiable: Augmentez max_retries à 5-7 et ajustez les paramètres de backoff

Options de réplica de cluster

La section connection.replica contrôle le routage des réplicas du cluster.

Exemple de configuration complet

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}

Évaluation des traces

Cette section couvre les paramètres qui contrôlent quand les traces sont évaluées et combien de temps les données persistent dans Redis.

Timing et fréquence d'évaluation

Fonctionnement de l'évaluation :

1. Tous les evaluation_interval, les workers vérifient les traces qui sont restées inactives pendant au moins trace_window_expiration
2. Jusqu'à max_traces_per_batch traces sont extraites de Redis par cycle d'évaluation
3. partition_workers évaluer les lots simultanément sur les partitions

Conseils de réglage :

• Décisions plus rapides: diminuez evaluation_interval (par exemple, 500 ms) pour une latence plus faible, mais augmente la charge Redis
• Débit plus élevé: Augmentez max_traces_per_batch (par exemple, 5000-10000) pour traiter plus de traces par cycle
• Plus de parallélisme: Augmentez partition_workers pour correspondre aux cœurs de processeur disponibles

Durée de vie (TTL) et expiration

Fonctionnement du TTL en mode distribué

Lors de l'utilisation de distributed_cache, le processeur met en œuvre un système TTL à plusieurs niveaux qui diffère du processeur en mémoire :

Étapes du cycle de vie de la trace :

1. Phase de collecte: Les spans arrivent et sont stockés dans Redis
2. Phase d'évaluation: Après trace_window_expiration, la trace est prête pour la décision d'échantillonnage
3. Phase de rétention: Les données de trace persistent pendant traces_ttl pour gérer les nouvelles tentatives et les spans tardifs
4. Phase de cache: Les décisions d'échantillonnage persistent pendant cache_ttl pour éviter les évaluations en double

Pourquoi les TTL en cascade sont importants :

La hiérarchie TTL garantit la disponibilité des données tout au long du cycle de vie de la trace:

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 (le plus court) contrôle le début de l'évaluation.
• in_flight_timeout (le plus court) contrôle le moment où l'évaluation prend trop de temps et doit être relancée.
• cache_ttl (le plus long) gère les spans arrivant tardivement, des heures après l'évaluation
• traces_ttl (moyen) fournit une mémoire tampon pour les nouvelles tentatives et la récupération des orphelins

Des TTL correctement configurés évitent la perte de données, les évaluations en double et les traces incomplètes tout en optimisant l'utilisation de la mémoire Redis.

1. Fenêtre de collecte des traces : trace_window_expiration

Par défaut : 30s | Config : distributed_cache.trace_window_expiration

• Objectif: Contrôle le moment où une trace est prête pour l’évaluation de l’échantillonnage
• Comportement: Fenêtre glissante qui se réinitialise chaque fois que de nouveaux spans arrivent pour une trace
• Exemple: Si une trace reçoit des spans à t=0s, t=15s et t=28s, l'évaluation commence à t=58s (fenêtre de 28s + 30s)

Conseils de réglage :

• Valeurs plus courtes (15-20s): Décisions d'échantillonnage plus rapides, mais risque de traces incomplètes si les spans arrivent lentement
• Valeurs plus longues (45-60s): Traces plus complètes, mais latence et utilisation de la mémoire plus élevées
• Plage typique: 20 à 45 secondes selon vos schémas d'arrivée des spans

2. Délai d'expiration du traitement par lots : in_flight_timeout

Par défaut : Identique à trace_window_expiration | Config : distributed_cache.in_flight_timeout

• Objectif: Temps maximal pendant lequel un lot peut être en cours de traitement avant d'être considéré comme orphelin
• Comportement: Empêche la perte de données si un collecteur se bloque pendant l'évaluation
• Récupération des orphelins: Les lots dépassant ce délai d'attente sont automatiquement remis en file d'attente pour être évalués par un autre collecteur

Conseils de réglage :

• Doit être ≥ trace_window_expiration: Assure suffisamment de temps pour une évaluation normale

• Augmenter si: Vos politiques d'évaluation sont coûteuses en calcul (OTTL complexe, regex)

• Monitorer: otelcol_processor_tail_sampling_sampling_decision_timer_latency pour s'assurer que les évaluations se terminent dans cette fenêtre

  Conseil

  Relation avec trace_window_expiration: Définir in_flight_timeout égal à trace_window_expiration fonctionne bien pour la plupart des déploiements. Augmentez uniquement si vous observez des récupérations de lots orphelins fréquentes en raison d'une évaluation de stratégie lente.

3. Rétention des données de trace : traces_ttl

Par défaut : 5m | Config : distributed_cache.traces_ttl

• Objectif: Durée de conservation des données de span de trace dans Redis après le stockage initial
• Comportement: fournit un temps tampon pour les nouvelles tentatives, les spans tardifs et la récupération des orphelins
• Contrainte critique: doit être significativement plus long que trace_window_expiration + in_flight_timeout

Formule recommandée :

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

Exemple avec les valeurs par défaut :

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

Conseils de réglage :

• Contrainte de mémoire: Utilisez un TTL plus court (2-3 m) mais risquez de perdre des données pour les spans très tardifs

• Tolérance des spans tardifs: Utilisez un TTL plus long (10-15m) pour gérer les arrivées de spans retardées

• Production standard: 5 à 10 minutes offrent un bon équilibre

  Important

  Trop court = perte de données: Si traces_ttl est trop court, les traces peuvent être supprimées avant la fin de l'évaluation, en particulier lors des nouvelles tentatives ou de la récupération des orphelins. Cela entraîne des traces partielles ou manquantes.

4. Rétention du cache de décision : cache_ttl

Par défaut : 30m | Config : distributed_cache.cache_ttl

• Objectif: Durée de mise en cache des décisions d'échantillonnage (échantillonné/non échantillonné)
• Comportement: Empêche l'évaluation en double lorsque des spans tardifs arrivent après l'évaluation de la trace
• Contrainte critique: Doit être beaucoup plus long que traces_ttl

Formule recommandée :

cache_ttl ≥ traces_ttl × 6

Pourquoi beaucoup plus long ?

• Les spans arrivant tardivement peuvent arriver minutes ou heures après la fin de la trace
• Le cache de décision empêche la réévaluation des traces lorsque des spans très tardifs arrivent
• Sans décision mise en cache, les spans tardifs seraient évalués comme des traces incomplètes (décision d'échantillonnage incorrecte)

Conseils de réglage :

• Production standard: 30m-2h équilibre l'utilisation de la mémoire et la gestion des spans tardifs
• Taux de spans tardifs élevé: 2-4h garantit que les décisions persistent pour les données très retardées
• Contrainte de mémoire: 15-30 minutes minimum, mais attendez-vous à plus d'évaluations en double

Impact sur la mémoire:

• Chaque décision: ~50 octets par ID de trace

• À 10 000 spans/s avec 20 spans/trace → 500 traces/s

• Cache de 30 minutes : ~900 000 décisions × 50 octets = ~45 Mo

• Cache de 2 heures : ~3,6 millions de décisions × 50 octets = ~180 Mo

  Conseil

  Monitorer l'efficacité du cache: suivre la métrique otelcol_processor_tail_sampling_early_releases_from_cache_decision. Des valeurs élevées indiquent que le cache empêche efficacement les évaluations en double.

Exemples de configuration TTL

Faible latence, mémoire limitée :

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

Tolérant aux spans tardifs et à haut débit :

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

Production équilibrée (recommandé) :

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

Nouvelle tentative et récupération

Récupération des orphelins :

Les lots orphelins se produisent lorsqu'un collecteur se bloque en cours d'évaluation. Le processus de récupération des orphelins s'exécute toutes les recover_interval et:

1. Identifie les lots qui ont dépassé in_flight_timeout
2. Remet ces traces en file d'attente pour évaluation par une autre instance de collecteur
3. Garantit qu'aucune trace n'est perdue en raison de défaillances du collecteur

Conseils de réglage :

• Augmenter max_retries (3-5) en cas d'erreurs Redis transitoires
• Diminuer recover_interval (2-3s) pour une récupération plus rapide dans les environnements à haute disponibilité
• Monitorer les métriques de récupération pour identifier si les collecteurs se bloquent fréquemment

Partitionnement et mise à l'échelle

Qu'est-ce qu'une partition ?

Une partition est une partition logique des données de trace dans Redis qui permet le traitement parallèle et la mise à l'échelle horizontale. Considérez les partitions comme des files d'attente distinctes où les traces sont distribuées en fonction de leur ID de trace.

Concepts clés :

• Chaque partition maintient sa propre file d'attente de traces en attente dans Redis

• Les traces sont affectées aux partitions à l'aide d'une stratégie de hachage configurable (rendez-vous ou cohérent) sur l'ID de trace

• Chaque partition peut être traitée indépendamment et simultanément

• Les partitions permettent à la fois une mise à l'échelle verticale (plus de cœurs de processeur) et une mise à l'échelle horizontale (plus d'instances de collecteur)

  Prudence

  Important: La modification du nombre de partitions lorsqu'un cluster est déjà en cours d'exécution entraînera des traces fragmentées, car les traces peuvent être routées vers une autre partition après la modification.

Fonctionnement du partitionnement

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

Flux :

1. Ingestion: l'ID de trace est haché à l'aide de la stratégie de hachage configurée pour déterminer l'affectation de la partition
2. Stockage: données de trace stockées dans Redis sous des clés spécifiques à la partition
3. Évaluation: Le worker affecté à cette partition extrait et évalue les traces
4. Concurrence: Tous les workers de partition s'exécutent en parallèle, traitant différentes traces simultanément

Stratégie de hachage

Le processeur prend en charge deux algorithmes de hachage pour la sélection des partitions. Le choix dépend du nombre de partitions :

Paramètres de configuration des partitions

Utilisez partitions pour contrôler le nombre de shards logiques dont vous disposez et partition_workers pour définir le nombre de workers qui les traitent :

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

Comportement du worker :

• 8 partitions + 8 workers: Chaque worker traite une partition toutes les evaluation_interval ✅ Équilibré
• 8 partitions + 16 workers: Chaque partition est évaluée deux fois par intervalle (redondant, gaspille des ressources)
• 8 partitions + 4 workers: Seule la moitié des partitions évaluées par intervalle (plus lent, mais moins de charge Redis)

Consignes de dimensionnement des partitions

Exemples de configuration de partition

Collecteur unique (machine à 4 cœurs) :

distributed_cache:
  partitions: 4
  partition_workers: 4
  partition_buffer_max_traces: 5000

Multi-collecteur (3 instances, 8 cœurs chacune) :

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

Volume élevé (plus de 10 collecteurs) :

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

Dimensionnement et performance

Exemple : supposons les paramètres suivants

• Spans par seconde: suppose un débit de 10 000 spans/sec
• Taille moyenne d'une portée: 900 octets

1. Exigences réseau

Calculs de la bande passante :

Pour 10 000 spans/sec à 900 octets par span :

• Trafic d'ingestion (collecteurs → Redis) : 10,000 × 900 bytes = 9 MB/sec = ~72 Mbps
• Trafic d'évaluation (Redis → collecteurs): ~9 MB/sec = ~72 Mbps (lecture des traces pour l'évaluation)
• Total bidirectionnel: ~18 MB/sec = ~144 Mbps

Avec une compression de 25 % (snappy/lz4) :

• Trafic compressé: ~108 Mbps bidirectionnel

Consignes relatives au réseau :

• Monitorer l'utilisation du réseau Redis: Une instance Redis typique peut gérer jusqu'à 1 Go/s, assurez-vous de monitorer l'utilisation du réseau
• Utiliser la compression: Cela réduit le volume de trafic réseau en échange de l'utilisation du processeur dans les collecteurs.
• Co-localisé (même centre de données/VPC) : Les interfaces réseau de 1 Gbit/s suffisent pour la plupart des charges de travail
• Inter-région: Attendez-vous à une latence de 10 à 50 ms - augmentez les délais d'attente et utilisez la compression pour réduire la bande passante
• Pool de connexions: Augmenter pour un débit plus élevé
• Utiliser des réplicas: Si le cluster possède des réplicas de lecture, ils seront utilisés par défaut. Réduction de l'utilisation du réseau et du processeur sur les nœuds maîtres

2. Exigences CPU

Consignes relatives au CPU :

• Instance Redis unique: 4 vCPU minimum

• Cluster Redis: 3+ nœuds avec des réplicas en lecture avec 4 vCPU chacun pour un débit élevé.

• Utiliser des réplicas: Si le cluster possède des réplicas de lecture, ils seront utilisés par défaut. Réduction de l'utilisation du réseau et du processeur sur les nœuds maîtres

  Conseil

  Monitoring du CPU : Monitorez la saturation du processeur (plus de 80 % d'utilisation) comme premier indicateur des besoins de mise à l'échelle. Si le processeur est limité, ajoutez des nœuds de cluster

3. Exigences de mémoire

Bien que la mémoire soit moins contrainte que le processeur et le réseau, un dimensionnement approprié empêche les évictions et garantit la disponibilité des données.

formule d'estimation de la mémoire

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

Stockage des données de trace

Les données de trace sont stockées dans Redis pour toute la période traces_ttl afin de prendre en charge les intervalles arrivant en retard et la récupération trace :

• Stockage par étendue: ~900 bytes (protobuf sérialisé)

• Durée de stockage: Contrôlée par traces_ttl (par défaut : 1 heure)

• Fenêtre de collecte active: Contrôlée par trace_window_expiration (par défaut : 30 s)

• Formule: Memory ≈ spans_per_second × traces_ttl × 900 bytes

  Important

  Fenêtre active vs. rétention complète: les traces sont collectées pendant une fenêtre active ~30-second (trace_window_expiration), mais persistent dans Redis pendant toute la période d'une heure traces_ttl. Cela permet au processeur de gérer les segments arrivant en retard et de récupérer les traces orphelines. Le dimensionnement de votre instance Redis doit prendre en compte la période de rétention complète, et non seulement la fenêtre active.

Exemple de calcul: À 10 000 portées/seconde avec 1 heure traces_ttl:

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

Avec la compression lz4 (nous avons observé une réduction de 25 %) :

32.4 GB × 0.75 = 24.3 GB

Remarque : ce calcul représente le principal consommateur de mémoire. La mémoire Redis réellement utilisée peut être légèrement supérieure en raison des caches de décision et des structures de données internes.

Stockage du cache de décision

Lors de l'utilisation distributed_cache, les caches de décision sont stockés dans Redis sans limites de taille explicites. Au lieu de cela, Redis utilise sa politique d'éviction LRU native (configurée via maxmemory-policy) pour gérer la mémoire. Chaque identifiant de trace nécessite environ 50 octets de stockage :

• Cache échantillonné: géré par l'éviction LRU de Redis

• Cache non échantillonné: géré par l’éviction LRU de Redis

• Surcharge typique par ID de trace: ~50 bytes

  Conseil

  Gestion de la mémoire: Configurez Redis avec maxmemory-policy allkeys-lru pour permettre l'éviction automatique des anciennes entrées du cache de décision lorsque les limites de mémoire sont atteintes. Les clés du cache de décision utilisent une expiration basée sur TTL (contrôlée par cache_ttl) plutôt que des limites de taille fixes.

Frais généraux du traitement par lots

• File d'attente actuelle: Minimale (identifiants de trace + scores dans l'ensemble trié)
• Lots en vol: max_traces_per_batch × average_spans_per_trace × 900 bytes

Exemple de calcul: 500 traces par lot (par défaut) avec 20 segments par trace en moyenne :

500 × 20 × 900 bytes = 9 MB per batch

La taille du lot influe sur l'utilisation de la mémoire pendant l'évaluation. La mémoire de traitement par lots en vol est temporaire et est supprimée une fois le traitement terminé.

Architecture de configuration par défaut

Les valeurs de configuration par défaut sont conçues pour un déploiement de référence prenant en charge 1 million de spans par minute (~16 000 spans/sec) :

Déploiement du collecteur :

• 3 instances de collecteur
• 4 vCPU par instance
• 8 Go de RAM par instance

Cluster Redis :

• 3 instances Redis (AWS cache.r6g.xlarge : 4 vCPU, 25,01 Gio de mémoire chacune)
• Configuré en tant que cluster pour une haute disponibilité et une répartition de la charge
• Co-localisé avec les collecteurs pour un accès à faible latence

Cette architecture de référence fournit un point de départ pour les déploiements en production. Ajustez-vous en fonction de vos exigences réelles en matière de débit et de latence.

Référence des métriques

Le processeur d'échantillonnage de queue émet les métriques suivantes en mode distribué Redis pour vous aider à monitorer les performances et à diagnostiquer les problèmes.

Métriques disponibles

Détails des dimensions

• policy: Nom de la politique d'échantillonnage qui a pris la décision
• sampled: Si la décision était d'échantillonner (true/false)
• decision: Le type de décision d'échantillonnage (sampled, not_sampled, dropped)
• deleted: Si la suppression a réussi (true/false)
• partition: Identifiant de partition (hachage encodé en hexadécimal, par exemple, {a1b2c3d4...}) - assure la compatibilité des balises de hachage du cluster Redis
• processor: identifiant d'instance de processeur (à partir de la configuration distributed_cache.processor_name)

Exigences de cache compatibles avec Redis

Le processeur utilise le cache comme stockage distribué pour les données trace suivantes :

• attribut trace et étendue
• Données trace actif
• Cache de décision d'échantillonnage

Le processeur exécute un script Lua pour interagir de manière atomique avec le cache Redis. La prise en charge script Lua est généralement activée par défaut dans les caches compatibles avec Redis. Aucune configuration supplémentaire n'est requise, sauf si vous avez explicitement désactivé cette fonctionnalité.