Ottimizzazione del sampling in OpenTelemetry per Java: guida pratica

Ottimizzazione del sampling in OpenTelemetry per Java: ridurre il volume dati senza perdere insight critici

Introduzione

Il sampling è una tecnica fondamentale per gestire la quantità di dati di tracing generata da applicazioni Java che utilizzano OpenTelemetry. Senza un'adeguata configurazione, il volume di span può crescere in modo incontrollato, aumentando i costi di storage e rallentando le analisi. In questa guida per principianti, spiegheremo passo dopo passo come ottimizzare il sampling, mantenendo gli insight più importanti per il monitoraggio e la diagnosi.

1. Concetti di base

1.1 Che cos'è OpenTelemetry?

OpenTelemetry è un progetto open‑source che fornisce API, SDK e strumenti per la tracciatura distribuita, il monitoraggio delle metriche e la rilevazione dei log. Permette di raccogliere dati da microservizi, applicazioni monolitiche e funzioni serverless.

1.2 Cos'è il sampling?

Il sampling definisce la percentuale di richieste che verrà effettivamente tracciata. Un tasso di 100 % significa che ogni singola chiamata genera uno span; un tasso di 10 % ne registra solo uno su dieci.

1.3 Perché è importante ridurre il volume dati?

  • Costi di storage: più dati, più spazio necessario.
  • Performance di query: gli strumenti di APM impiegano più tempo a elaborare dataset più grandi.
  • Rumore: dati superflui possono nascondere pattern critici.

2. Preparazione dell'ambiente Java

2.1 Requisiti preliminari

  • JDK 11 o superiore.
  • Maven o Gradle per la gestione delle dipendenze.
  • Accesso a un backend di osservabilità (es. Lescopr, Jaeger, Zipkin).

2.2 Aggiungere le dipendenze OpenTelemetry

<!-- Maven pom.xml -->
<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-api</artifactId>
    <version>1.31.0</version>
</dependency>
<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-sdk</artifactId>
    <version>1.31.0</version>
</dependency>
<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-otlp</artifactId>
    <version>1.31.0</version>
</dependency>

3. Configurare il sampling passo dopo passo

3.1 Impostare un ParentBasedSampler

Il ParentBasedSampler rispetta il campionamento dei genitori, evitando di creare nuovi span inutili quando il contesto è già stato campionato.

SdkTracerProvider tracerProvider = SdkTracerProvider.builder()
    .setSampler(Sampler.parentBased(Sampler.traceIdRatioBased(0.2))) // 20 % di sampling
    .build();

3.2 Utilizzare un TraceIdRatioBasedSampler

Il TraceIdRatioBasedSampler campiona in base a una percentuale fissa del Trace ID.

Sampler sampler = Sampler.traceIdRatioBased(0.1); // 10 % di sampling
Tracer tracer = OpenTelemetrySdk.builder()
    .setTracerProvider(SdkTracerProvider.builder().setSampler(sampler).build())
    .build()
    .getTracer("example-tracer");

3.3 Definire policy di sampling per endpoint critici

Puoi combinare più sampler usando il CompositeSampler. Ad esempio, traccia al 100 % le richieste che restituiscono errori 5xx, ma al 5 % le richieste di successo.

Sampler errorSampler = Sampler.alwaysOn(); // 100 % per errori
Sampler successSampler = Sampler.traceIdRatioBased(0.05); // 5 % per successi
Sampler composite = Sampler.composite(errorSampler, successSampler);

Nota: Lescopr supporta la configurazione dinamica di questi sampler tramite la UI, consentendo di modificare le percentuali senza ridistribuire il codice.

4. Verificare l'impatto sul volume dati

4.1 Misurare il throughput di span

Utilizza le metriche di OTLP per monitorare il numero di span inviati al backend:

curl -X GET http://localhost:4318/v1/metrics | jq '.instrumentation_library_metrics[0].metrics[0].data_points'

4.2 Calcolare il reduction ratio

Reduction Ratio = (Span_before - Span_after) / Span_before * 100 %

Un buon punto di partenza è mirare a una riduzione del 60‑80 % mantenendo la copertura degli errori.

5. Best practice per mantenere insight critici

  • Campiona al 100 % gli errori (status ≥ 500) e le richieste con latenza > 300 ms.
  • Escludi endpoint statici (es. /health, /metrics).
  • Aggiorna le policy in staging prima di applicarle in produzione.
  • Monitora costantemente il rapporto tra volume dati e tempo medio di risoluzione (MTTR).

5.1 Checklist rapida

  • Aggiunta dipendenze OpenTelemetry.
  • Configurazione di un sampler di base.
  • Definizione di policy per errori e latenza.
  • Verifica del throughput di span.
  • Messa a punto delle percentuali in staging.

6. Integrazione con Lescopr per un controllo avanzato

Lescopr offre un’interfaccia grafica per gestire le policy di sampling in tempo reale. Puoi:

  1. Creare regole basate su attributi (es. http.status_code >= 500).
  2. Visualizzare l’impatto sul traffico di tracing con dashboard dedicate.
  3. Impostare soglie dinamiche che si adattano al carico corrente.

Esempio: impostare un sampler al 10 % per le richieste con latenza < 200 ms, ma al 100 % per quelle sopra 500 ms.

Conclusione

Ottimizzare il sampling in OpenTelemetry per Java è un passo cruciale per bilanciare costi operativi e visibilità. Seguendo i passaggi descritti, potrai ridurre significativamente il volume dei dati, mantenendo gli insight necessari per un monitoraggio efficace.

Per approfondire, la documentazione di Lescopr descrive la configurazione passo dopo passo.