Come smettere di riscrivere codice per log e metriche

Immagina questo: hai una dozzina di microservizi Java in produzione. A un certo punto, uno di essi inizia a "laggare." Apri i log, ma non c'è nulla — i messaggi standard non sono sufficienti per capire in quale fase esatta la richiesta si blocca. Storia familiare? Di solito a questo punto lo sviluppatore entra nel codice, decora i metodi con annotazioni, aggiunge dipendenze di tracing, ricompila il progetto e lo ridistribuisce. E se ci fossero centinaia di servizi scritti su framework diversi?

Nell'ecosistema OpenTelemetry, c'è un progetto che risolve questo problema in modo elegante e, cosa particolarmente piacevole, quasi pigro. Questo è opentelemetry-java-instrumentation. È un agente Java speciale che può iniettarsi nella tua applicazione "al volo" e raccogliere telemetria senza una singola riga di nuovo codice.

Cos'è questo agente e perché ti serve

Essenzialmente, è un file JAR che alleghi all'avvio della JVM. Usa l'iniezione dinamica di bytecode. Quando la tua applicazione carica classi da librerie popolari (per esempio, Spring, Hibernate, gRPC o Kafka), l'agente inietta accuratamente la logica per la creazione di span e la raccolta di metriche.

Questa è un'opzione ideale per due scenari. Primo, quando devi aggiungere rapidamente observability a un progetto legacy che fa paura toccare. Secondo, quando vuoi standardizzare la raccolta dati in tutta l'azienda senza far configurare manualmente l'SDK a ogni team.

Tre funzionalità cool che semplificano la vita

Magia automatica out of the box

L'agente supporta un enorme numero di librerie. Se usi uno stack standard come Spring Boot con PostgreSQL e Redis, non devi configurare nulla. Alleghi semplicemente l'agente e nel tuo sistema di monitoraggio (per esempio Jaeger o Zipkin) ottieni un albero delle chiamate: dalla richiesta HTTP in entrata alla query del database e alla risposta della cache.

Propagazione del contesto nei log (MDC)

Una delle cose più utili nel debugging quotidiano è l'inserimento automatico del Trace ID nei log. L'agente può trovare da solo i tuoi logger (Logback, Log4j2) e aggiungere l'identificatore della traccia corrente in MDC. Ora, quando vedi un errore nei log, puoi semplicemente copiare l'ID e trovare l'intero percorso di quella richiesta attraverso tutti i servizi. Niente più ipotesi su quale utente ha generato quel NullPointerException.

Configurazione flessibile senza ricompilazione

Tutti i parametri — dove inviare i dati, quanto spesso campionarli, quali attributi aggiungere agli span — vengono passati attraverso variabili d'ambiente o proprietà di sistema Java. Questo significa che lo stesso binario della tua applicazione può inviare dati alla console in dev e a un cluster OpenTelemetry Collector pesante in produzione.

Come farlo funzionare

Il processo di setup è sorprendentemente semplice. Prima, scarica l'ultima opentelemetry-javaagent.jar dalla pagina delle release. Poi aggiungi un flag al comando di avvio della tua applicazione:

java -javaagent:path/to/opentelemetry-javaagent.jar \
     -Dotel.resource.attributes=service.name=my-cool-service \
     -jar myapp.jar

Di default, l'agente si aspetta che un collector che accetta dati tramite il protocollo OTLP sia in esecuzione da qualche parte all'indirizzo localhost:4318. Se vuoi usare qualcos'altro, per esempio Zipkin, lo cambi con un flag: -Dotel.traces.exporter=zipkin.

Sotto il cofano ed estensibilità

Interessante, il progetto non ti limita solo all'"automazione." Se le funzionalità built-in non sono sufficienti, puoi usare il meccanismo delle estensioni. Puoi scrivere il tuo file JAR che aggiungerà regole di instrumentazione personalizzate o attributi specifici dell'azienda.

Per chi non si fida affatto della magia degli agent, il progetto distribuisce le stesse librerie di instrumentation separatamente. Puoi aggiungerle come dipendenze regolari e configurarle manualmente, ma poi dovrai accettare la necessità di modificare il codice.

Vale la pena usarlo

Spesso incontro l'opinione che gli agent Java siano una "black box" che può rallentare un'applicazione. C'è del vero: l'agente consuma risorse per la trasformazione del bytecode all'avvio e aggiunge un piccolo overhead nell'esecuzione delle richieste. Tuttavia, nel 95% dei casi, questo overhead è trascurabile rispetto al beneficio che ottieni quando cacci bug in un sistema distribuito.

A chi si adatterà particolarmente bene:

1. Team che passano ai microservizi e soffrono senza tracing.
2. Supporto che ha bisogno di "ieri" per capire perché il vecchio monolith è lento.
3. Architect che implementano uno standard di monitoraggio unificato.

Se non hai ancora provato OpenTelemetry nei tuoi progetti Java, questo agente è il modo più veloce e meno doloroso per iniziare. Prova semplicemente a eseguirlo localmente e guarda quante cose interessanti scopri sul comportamento del tuo codice sotto carico.