10 - Sampling Strategies - Reducing Telemetry Volume and Costs

Sampling Strategies: Ridurre Volume e Costi della Telemetria

In un sistema distribuito con centinaia di microservizi e migliaia di richieste al secondo, raccogliere ogni traccia e proibitivamente costoso. Il sampling (campionamento) e la tecnica che permette di selezionare un sottoinsieme rappresentativo delle tracce, riducendo il volume di dati e i costi di storage senza perdere la capacità di diagnosticare i problemi.

La sfida del sampling e trovare il giusto equilibrio: campionare troppo poco riduce la visibilità; campionare troppo aumenta i costi. Le strategie di sampling avanzate permettono di mantenere tutte le tracce con errori e le richieste lente, scartando solo il traffico "normale" e ripetitivo.

Head-Based Sampling

Il head-based sampling prende la decisione di campionare una traccia all'inizio, nel primo span (root span). La decisione viene poi propagata a tutti i servizi downstream attraverso il flag sampled nel traceparent header. Se il root span decide di non campionare, nessun servizio nella catena registrera span per quella traccia.

Il vantaggio principale e la semplicità e l'efficienza: la decisione viene presa immediatamente, senza dover attendere il completamento della traccia. Lo svantaggio e che non conosce il risultato della richiesta al momento della decisione: una traccia con errore potrebbe essere scartata.

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.sampling import (
    TraceIdRatioBased,
    ParentBasedTraceIdRatio,
    ALWAYS_ON,
    ALWAYS_OFF,
)

# --- 1. Probability Sampler (25% delle tracce) ---
# Ogni traccia ha il 25% di probabilità di essere campionata
sampler_25 = TraceIdRatioBased(0.25)

# --- 2. ParentBased Sampler (rispetta la decisione del parent) ---
# Se il parent e campionato, il figlio e campionato
# Se non c'è parent, usa il ratio specificato
sampler_parent = ParentBasedTraceIdRatio(0.25)

# --- 3. Configurazione nel TracerProvider ---
provider = TracerProvider(
    sampler=ParentBasedTraceIdRatio(0.25)
)
trace.set_tracer_provider(provider)

# --- 4. Configurazione via variabili d'ambiente ---
# OTEL_TRACES_SAMPLER=parentbased_traceidratio
# OTEL_TRACES_SAMPLER_ARG=0.25
      

Tail-Based Sampling

Il tail-based sampling prende la decisione di campionare una traccia dopo che tutti gli span sono stati raccolti, analizzando la traccia completa. Questo permette decisioni intelligenti basate sul risultato della richiesta: mantenere tutte le tracce con errori, le richieste lente e le tracce anomale, scartando solo il traffico ripetitivo e di successo.

Il tail-based sampling richiede un componente centralizzato (tipicamente il Collector in modalità Gateway) che raccoglie tutti gli span di una traccia, li assembla, valuta le policy di campionamento e decide se conservare o scartare l'intera traccia.

# Configurazione tail_sampling nel Collector Gateway
processors:
  tail_sampling:
    # Tempo massimo per attendere tutti gli span di una traccia
    decision_wait: 30s
    # Numero massimo di tracce in attesa di decisione
    num_traces: 100000
    # Numero atteso di nuove tracce al secondo
    expected_new_traces_per_sec: 1000

    policies:
      # Policy 1: mantenere TUTTE le tracce con errori
      - name: errors-policy
        type: status_code
        status_code:
          status_codes:
            - ERROR

      # Policy 2: mantenere le tracce lente (latenza > 2s)
      - name: latency-policy
        type: latency
        latency:
          threshold_ms: 2000

      # Policy 3: mantenere tracce con attributi specifici
      - name: vip-customers
        type: string_attribute
        string_attribute:
          key: customer.tier
          values:
            - premium
            - enterprise

      # Policy 4: campionamento probabilistico per il resto
      - name: probabilistic-policy
        type: probabilistic
        probabilistic:
          sampling_percentage: 10

      # Policy 5: rate limiting globale
      - name: rate-limiting
        type: rate_limiting
        rate_limiting:
          spans_per_second: 500

      # Policy 6: policy composita (AND/OR)
      - name: composite-policy
        type: composite
        composite:
          max_total_spans_per_second: 1000
          policy_order: [errors-policy, latency-policy, probabilistic-policy]
          rate_allocation:
            - policy: errors-policy
              percent: 50
            - policy: latency-policy
              percent: 30
            - policy: probabilistic-policy
              percent: 20
      

Confronto Head vs Tail Sampling

Strategie di Ottimizzazione dei Costi

I costi di observability crescono con il volume di telemetria. Le strategie di ottimizzazione si concentrano su tre leve: ridurre il volume di tracce, ridurre il numero di attributi per span e ottimizzare la retention nel backend.

# Strategia di ottimizzazione multi-livello

# 1. Filtrare il rumore nel Collector
processors:
  filter:
    traces:
      span:
        # Eliminare health check e readiness probe
        - 'attributes["http.route"] == "/health"'
        - 'attributes["http.route"] == "/ready"'
        - 'attributes["http.route"] == "/metrics"'
        # Eliminare richieste di asset statici
        - 'attributes["http.route"] =~ "/static/.*"'

  # 2. Rimuovere attributi ad alta cardinalita
  attributes:
    actions:
      # Rimuovere header sensibili
      - key: http.request.header.authorization
        action: delete
      - key: http.request.header.cookie
        action: delete
      # Troncare query SQL lunghe
      - key: db.query.text
        action: hash

  # 3. Tail sampling intelligente
  tail_sampling:
    policies:
      - name: keep-errors
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: keep-slow
        type: latency
        latency:
          threshold_ms: 1000
      - name: sample-rest
        type: probabilistic
        probabilistic:
          sampling_percentage: 5

  # 4. Batch per efficienza
  batch:
    send_batch_size: 2048
    timeout: 10s
      

Adaptive Sampling

L'adaptive sampling adatta automaticamente il tasso di campionamento in base al volume di traffico corrente. Quando il traffico e basso, campiona una percentuale maggiore; quando il traffico e alto, riduce il tasso per mantenere il volume entro i limiti di budget.

Il rate limiting nel tail sampling del Collector e una forma semplice di adaptive sampling: spans_per_second: 500 garantisce un volume massimo costante indipendentemente dal traffico. Per strategie più sofisticate, servono soluzioni custom o servizi SaaS che implementano l'adaptive sampling a livello di piattaforma.

Conclusioni e Prossimi Passi

Il sampling e una competenza fondamentale per gestire l'observability a scala. La scelta della strategia dipende dal volume di traffico, dal budget e dal livello di visibilità richiesto. L'approccio consigliato e combinare head-based sampling per la riduzione base del volume con tail-based sampling per garantire che errori e anomalie vengano sempre catturati.

La regola d'oro e: campionare le tracce, mai le metriche. Le metriche aggregate hanno un costo fisso indipendente dal traffico e forniscono la visibilità di alto livello necessaria per gli alert. Le tracce sono costose ma necessarie solo per il debugging dettagliato.

Nel prossimo articolo esploreremo l'AI observability, analizzando come tracciare le chiamate ai Large Language Model, monitorare l'utilizzo dei token, le latenze delle inferenze e il comportamento degli agenti AI.