Registrazione di OpenTelemetry: un'introduzione

La registrazione OTel offre ai team IT una struttura di mappatura unificata e univoca per convertire i dati di log provenienti da diverse fonti, sistemi e formati in un unico modello indipendente dalla lingua, preservando al contempo i significati semantici originali.

Con un modello di dati strutturati e indipendente dal fornitore, gli strumenti di observability possono analizzare i log in modo più semplice e affidabile, allegare metadati e correlare log con metriche e tracce per una visibilità profonda e end-to-end.

OTel registrazione consente alle aziende di commutare e mixare backend di observability senza dover rimettere in scena l'intera architettura IT, motivo per cui è diventato lo standard di settore per la strumentazione nei sistemi cloud-native. Queste funzionalità aiutano i team IT e gli ingegneri di affidabilità del sito (SRE) a evitare le lacune di observability e i problemi di frammentazione dei dati che si verificano quando ogni fornitore, stack e dispositivo ha il proprio schema di registrazione e protocolli di trasmissione.

La registrazione OTel facilita inoltre la correlazione automatica dei segnali incrociati, migliorando notevolmente il debug e riducendo il blocco da fornitore di observability.

I log di OpenTelemetry sono un componente fondamentale di OpenTelemetry. OpenTelemetry è un framework open source di observability che include una raccolta di kit di sviluppo software (SDK), application programming interface (API) indipendenti dal fornitore e altri strumenti per la strumentazione di applicazioni, sistemi e dispositivi.

Il codice di strumentazione variava ampiamente e nessun singolo fornitore commerciale offriva uno strumento in grado di raccogliere dati da ogni app e servizio su una rete. Questa lacuna di funzionalità rendeva difficile (e spesso impossibile) per i team raccogliere dati da diversi linguaggi di programmazione, formati e tempo di esecuzione.

Gli approcci tradizionali di observability hanno inoltre reso la modifica dell'infrastruttura e dei componenti backend un processo che richiede molto tempo e molta fatiga.

Se, ad esempio, un team di sviluppo volesse sostituire gli strumenti backend, dovrebbe ristrutturare completamente il proprio codice e configurare nuovi agenti (componenti software che eseguono compiti automatici di build e release) per inviare dati di telemetria ai nuovi server. Approcci frammentati hanno creato silos di dati e confusione, rendendo difficile risolvere efficacemente i problemi di prestazioni.

OpenTelemetry ha rappresentato un avanzamento significativo nel campo degli strumenti di observability, in quanto ha standardizzato il modo in cui i dati di telemetria vengono raccolti, analizzati e trasmessi alle piattaforme di backend. Ha fornito una soluzione open source, cioè basata su standard guidati dalla comunità, per raccogliere dati sul comportamento e la sicurezza del sistema, aiutando i team a semplificare monitoring and observability negli ecosistema distribuiti.

La registrazione OpenTelemetry si basa su diversi componenti che creano, strutturano, trasportano e forniscono record di log come parte di una pipeline di observability unificata. Eccone alcune:

Un record di log è una struttura di dati centrale che rappresenta un singolo evento di log in OpenTelemetry. Segue un modello di dati standard che definisce campi e semantica, quindi i log di diversi linguaggi e sistemi possono essere interpretati in modo coerente dai backend.

I record di log appaiono come righe strutturate in un foglio di calcolo che descrivono un evento e rispondono a domande di base, come "cosa è successo", "quando è successo", "quanto è importante" e "da dove proviene".

Il modello dati dei log è il modello comune che ogni record segue, indipendentemente dal linguaggio e dal sistema operativo. Definisce quali campi di alto livello esistono e cosa significa ciascuno di essi.

Un tipico modello di dati di log richiede che i record includano:

• Un timestamp e un timestamp osservato (quando è avvenuto l'evento e quando è stato visto)

• Numeri e testo relativi alla gravità (chiamati anche livelli di registro), che descrivono il livello di gravità di un evento.

• Il corpo (il messaggio di log principale, spesso una stringa breve o un oggetto JSON)

• Attributi, che aggiungono dettagli più dettagliati su ogni evento (come dati utente o HTTP)

• Informazioni sulle risorse che identificano il servizio emittente e l'ambiente di distribuzione

• Trace ID e span ID che collegano l'evento a una richiesta specifica (semplifica la correlazione dei dati)

I modelli di dati strutturali imposti trasformano i log di diversi servizi e tecnologie in entità di telemetria ricche e interrogabili che appaiono e si comportano allo stesso modo quando entrano nella pipeline di observability. I modelli di dati di log consentono ai team IT di correlare i log con le tracce, di raggrupparli per servizio o utente e di eseguire gli stessi tipi di query in tutto l'ambiente IT, invece di avere a che fare con una serie di formati di log incompatibili.

E poiché il modello di log è aperto e guidato dalla comunità, la strumentazione e le pipeline di log di OTel sono portatili (non legate a un singolo prodotto software-as-a-service (SaaS) o a un agente proprietario). Lavorano su framework e piattaforme, cosa particolarmente preziosa negli ambienti di microservizio poliglotti.

Un Logger è l'oggetto che scrive i record di registrazione, simile alle istanze logger in altri framework di registrazione (come Java e Python). Quando una piattaforma di observability invia un comando "registra questo errore" o "registra questo messaggio informativo", invia il messaggio a un logger.

Parti diverse di un'applicazione o di un sistema possono richiedere i propri logger (ad esempio, uno per il "checkout" e uno per i "pagamenti"), ma seguono tutte le stesse regole per la generazione dei log.

I logger vengono forniti da un Logger Provider, responsabile della loro creazione e configurazione con la pipeline, gli attributi e gli exporter corretti.​ Quando il codice software richiede un logger, il Provider ne fornisce uno già opportunamente configurato.

Questo design consente a diverse parti di un sistema di utilizzare logger diversi che condividono comunque una configurazione comune e sono tutti gestiti centralmente dal provider di logger. Rende inoltre più facile per i team IT cambiare implementazioni e modificare il comportamento di registrazione a livello globale senza modificare ogni sito di chiamata.

L'OTel Collector è un servizio separato che riceve, elabora ed esporta dati di telemetria, inclusi i registri di log, da molte fonti. Le applicazioni inviano i loro log (e tracce e metriche) al collector, che può ricevere dati in diversi formati, standardizzarli e poi inviarli a uno o più backend.

I collettori supportano pipeline di log dedicate, strutturate attorno a tre componenti principali: ricevitori, processori ed esportatori.

I ricevitori inseriscono i log da vari input, come i flussi OpenTelemtetry Protocol (OTLP) e i file di log dai ricevitori di coda di file. I processori eseguono operazioni come batching, modifica degli attributi, arricchimento del contesto (ad esempio aggiunta di metadati dei pod Kubernetes ), filtraggio e campionamento sui record di log. Gli esportatori all'interno del Collector inoltrono quindi i log processati a una o più destinazioni.

Gli esportatori di record di log si trovano all'interno di un collettore OTel o di un SDK di applicazione e definiscono dove e come i dati di telemetria vengono consegnati ai sistemi backend.

Dopo che Logs SDK ha creato ed elaborato un record di registro, l'esportatore codifica il modello di dati di registro in un protocollo o formato specifico e invia il record a un "consumatore" a valle. Tra i consumatori possono rientrare, ad esempio, i collettori OTel, le soluzioni di observability o i negozi open source.

Gli esportatori possono essere di tipo push o pull, e possono essere scambiati e combinati per trasmettere simultaneamente gli stessi record di log a backend diversi senza modificare il codice dell'applicazione. La flessibilità offerta dagli esportatori rende più facile per le aziende evolvere la propria architettura di observability man mano che i requisiti cambiano.

L'API dei Logs e l'SDK dei Logs funzionano come una presa su una Power strip: l'API è il tipo di presa e l'SDK è la Power strip che trasporta l'elettricità.

Le API OpenTelemetry comprendono un insieme di funzioni che le librerie di codice e registrazione utilizzano per creare voci di log uniformi. In sostanza, l'API Logs determina la "forma" che un log deve assumere per "collegarsi" a OTel. L'API Logs aiuta a garantire che le stesse chiamate API funzionino indipendentemente dal backend di observability o dal fornitore scelto dal team IT in seguito.

Tuttavia, l'API è solo un'interfaccia. Non può decidere dove vanno i log o come vengono inviati. È qui che entra in gioco l’OpenTelemetry SDK, o Logs SDK.

Il Logs SDK prende i log dall'endpoint dell'API e fa il vero lavoro con essi. Riceve i registri, li arricchisce (aggiungendo nome di servizio o ambiente, ad esempio), li aggrega e li prepara per la spedizione. Successivamente, utilizza gli exportec per inviare i log processati a un Collector o a una piattaforma di log.

I log appender, chiamati anche log bridge, collegano le librerie di registrazione esistenti (come Log4j, SLF4J o framework simili) al modello di dati di log di OpenTelemetry.

Invece che gli sviluppatori di software chiamino direttamente l'API dei log, possono configurare il loro framework di registrazione esistente per utilizzare un appender che trasforma ogni evento log tradizionale in un record OTel.

I log bridge possono anche iniettare il contesto di span e trace nei record di log, consentendo la correlazione tra i log e le tracce anche quando il codice dell'applicazione stessa non è a conoscenza dei dettagli di tracciamento.

La propagazione del contesto e i meccanismi di correlazione sono componenti essenziali della registrazione OpenTelemetry. Quando una traccia di span è attiva, un ponte di registrazione o SDK può assegnare automaticamente l'attuale ID di traccia e l'ID di span a ciascun record di log emesso.

La correlazione aiuta i backend di observability a collegare i log con le tracce distribuite che rappresentano la stessa richiesta o lo stesso workflow. Queste connessioni permettono ai team di navigare direttamente da una voce di log problematica a una traccia che mostra il percorso completo della richiesta. Facilita inoltre l'analisi cross-signal per metriche, tracce e log che condividono campi comuni di risorse e contesto.

OTel descrive i "tipi" di log in diversi modi: in base alla struttura, alla sorgente e al protocollo di codifica o trasmissione.

I log strutturati hanno uno schema coerente: gli stessi campi, con nomi stabili e tipi di dati, così gli strumenti di observability possono analizzarli e interrogarli in modo affidabile. I log possono essere codificati con JSON o un altro formato, ma ciò che li rende strutturati è il set prevedibile di campi dati.

I log semi-strutturati contengono una struttura riconoscibile (ad esempio coppie chiave-valore o blob simili a JSON), ma lo schema non è coerente nel tempo. Sono più leggibili da una macchina rispetto al testo in formato libero, ma richiedono un'analisi e una normalizzazione aggiuntive prima che i team possano analizzarli in modo efficace.

I log non strutturati sono messaggi di testo liberi senza uno schema stabile (come istruzioni print ad hoc o log server in testo semplice). Sono facili da scrivere e da leggere per gli esseri umani, ma più difficili da ricercare, correlare e aggregare per i sistemi automatici, senza un considerevole parsing aggiuntivo. 

I log di sistema e infrastruttura sono prodotti da sistemi operativi, dispositivi di rete, servizi di infrastruttura cloud e altri componenti della piattaforma, invece che dal codice applicativo. Essi catturano eventi come errori del sistema operativo, problemi di rete e stato dell'infrastruttura per aiutare i team a comprendere la salute e le prestazioni dell'ambiente sottostante

I log delle applicazioni di prima parte provengono da servizi e applicazioni interni, in genere tramite un SDK OTel, una libreria di registrazione, un sidecar (un secondo container di app che funziona insieme al container primario e che utilizza le stesse risorse) o un agente. Descrivono eventi aziendali, gestione delle richieste, azioni degli utenti ed errori interni. Possono essere arricchiti con attributi di risorsa e ambito di strumentazione (che descrive l'origine del log all'interno dell'entità che li ha generati) per fornire un quadro più completo del comportamento dell'applicazione.

I log di terze parti vengono emessi dai servizi esterni, dai componenti gestiti e dai prodotti SaaS da cui dipendono molti ambienti IT aziendali (ad esempio API e database esterni). OTel può assorbire questi log insieme a quelli interni in modo che i team IT possano vedere come le dipendenze esterne influenzano l'ecosistema.

I log OTLP sono rappresentati nel modello dati OTLP nativo e inviati tramite OTLP gRPC o HTTP. Ogni registro è standardizzato per garantire la neutralità rispetto al fornitore e una rapida correlazione con tracce e metriche.

I log basati su file vengono scritti su file (file di log delle applicazioni o log di accesso del server web), mentre i log in stile syslog sono messaggi emessi utilizzando il protocollo syslog. OTel tipicamente raccoglie questi log utilizzando ricevitori che affiano file o ascoltano i messaggi syslog e poi li converte in record OTel per un'elaborazione unificata.

I log HTTP e JSON vengono trasmessi tramite HTTP in formato JSON. OpenTelemetry supporta anche i formati CSV, Common Log Format (CLF), LTSV e coppie chiave-valore. Questi formati vengono analizzati dal sistema di raccolta e convertiti nel modello dati di log OTel standard, in modo da poter essere interrogati e correlati nello stesso modo dei log OTLP nativi.

Immagina che gli SRE vedano un aumento degli errori di "checkout non riuscito" sulle dashboard di observability per un microservizio di checkout. Potrebbero iniziare il processo di risoluzione dei problemi esaminando i registri OTel, che sono già standardizzati e includono attributi strutturati (tra cui l'importo dell'ordine, il conteggio degli articoli e l'ID di tracciamento) per ogni record di registro "ordine effettuato".

Gli ingegneri possono verificare rapidamente se i guasti sono correlati a volumi di ordini elevati, a un metodo di spedizione specifico o a una regione particolare, semplicemente interrogando gli attributi dei log. Possono anche allineare la finestra temporale tra log, tracce e metriche, poiché OTel utilizza timestamp e metadati delle risorse coerenti in tutti i segnali di telemetria.

Gli ingegneri confermano che solo gli ordini indirizzati a uno specifico fornitore di servizi di pagamento presentano problemi. Seguono un percorso a ritroso verso tutti i registri che condividono l'attributo del provider, dove trovano ripetuti timeout sessione. Con queste prove, il team IT può rapidamente instradare l'incidente al proprietario giusto e implementare una strategia di mitigazione (ad esempio, passando a un altro fornitore).

La registrazione OTel si differenzia in modo significativo dalla registrazione tradizionale per le procedure di raccolta, standardizzazione, correlazione e trasmissione dei log.  

I sistemi di registrazione tradizionali si concentrano sull'aggregazione dei log, indicizzazione, ricerca e allerta basati su pattern di log. Sono strumenti potenti per la ricerca testuale e l'analisi storica, ma di solito esaminano i log isolatamente da altri dati di telemetria.

Gli approcci tradizionali di logging si concentrano principalmente sulla registrazione localmente dei messaggi di testo, così gli sviluppatori possono risolvere problemi in un'unica applicazione o host. Presuppongono che gli utenti leggano i file, li filtrino e, eventualmente, li inviino a un aggregatore di log in un secondo momento. Inoltre, in genere utilizzano formati ad hoc, come righe di testo semplice, JSON con struttura flessibile o modelli specifici di un framework, senza uno standard inter-servizio.

E poiché ogni team di sviluppo può scegliere i propri campi e denominazioni, l'analisi intersistemica è un processo complicato.

Gli strumenti di registrazione tradizionali spesso non includono funzionalità integrate di correlazione o migrazione, quindi la correlazione dei dati e l'integrazione con i backend di observability richiedono processi manuali e passaggi aggiuntivi. I team IT devono creare convenzioni personalizzate e regole di parsing per unire eventi tra i servizi, e l'integrazione dei dati di log nello stack di observability generalmente richiede mittenti personalizzati o adattatori di formato.

OpenTelemetry registrazione fa parte di un framework unificato di observability che tratta log, metriche e tracce come segnali di prima classe, interoperabili, governati da convenzioni semantiche condivise. Fin dall'inizio, progetta i log da correlare e analizzare tra sistemi distribuiti, perché l'obiettivo è comprendere il comportamento del sistema end-to-end.

Dove il logging tradizionale è specifico per stack e backend, il logging OTel è volutamente agnostico. Fornisce bridge e appender in modo che i framework di logging esistenti possano emettere dati nel formato OTel senza dover riscrivere ogni chiamata di log.

Questo ambito e approccio unificati consente ai team IT di creare workflow olistici per la risoluzione dei problemi, in cui possono spostarsi senza problemi tra dashboard e tipi di dati per comprendere guasti complessi e distribuiti.

OTel registrazione fornisce log standardizzati e ricchi di contesto che si integrano strettamente con tracce e metriche, rendendo la risoluzione dei problemi e l'analisi molto più efficaci rispetto agli approcci tradizionali. Questi vantaggi includono: