OpenTelemetry è il risultato della fusione tra due progetti precedenti, OpenTracing e OpenCensus. Entrambi questi progetti sono stati creati per risolvere lo stesso problema: la mancanza di uno standard per la strumentazione di codice e l'invio dei dati telemetrici a un backend di osservabilità. Tuttavia, nessuno dei due progetti è stato in grado di risolvere il problema da solo, e così i due progetti sono stati fusi per dare vita a OpenTelemetry, in modo da poter combinare i loro punti di forza e offrire davvero uno standard unico.

Fondamentalmente, OpenTelemetry è indipendente da fornitori e strumenti, e ciò significa che può essere utilizzato con un'ampia varietà di backend di osservabilità, inclusi strumenti open source come Jaeger e Prometheus, nonché offerte commerciali. OTel è un progetto Cloud Native Computing Foundation (CNCF), pensato per funzionare come soluzione robusta, portatile e facile da strumentare, in molte lingue. Fornisce un unico set di API, librerie, agenti e servizi di raccolta per acquisire tracce e parametri distribuiti, direttamente dalla propria applicazione. OpenTelemetry rende possibile una vera osservabilità.

"Osservabilità" è un termine che ha catturato un'attenzione significativa nel mondo dell'ingegneria dei software e dell'amministrazione dei sistemi, quasi al punto di perdere parte del suo significato. Oggi, anche molti di coloro che lavorano nel settore IT utilizzano il termine in modo approssimativo per indicare qualsiasi tipo di visibilità del sistema. Ma che cos'è esattamente l'osservabilità e in che modo si differenzia dal monitoraggio tradizionale?

L'osservabilità non equivale al monitoraggio

Il monitoraggio è il processo che consiste nel guardare e controllare attivamente lo stato del sistema, in genere utilizzando soglie e avvisi predefiniti. Sebbene questo approccio possa richiamare l'attenzione sui sistemi interessati quando qualcosa va storto, il monitoraggio spesso non fornisce informazioni approfondite sul perché il problema si sta verificando o su come risolverlo al meglio.

L'osservabilità, d'altro canto, è un approccio più completo. Il termine fa riferimento alla capacità di comprendere che cosa sta accadendo all'interno di un sistema analizzandone gli output esterni. L'osservabilità consente di porre domande di qualsiasi tipo in merito a ciò che è accaduto, in qualunque momento, senza avere predefinito ciò che si desiderava sapere in anticipo. Essenzialmente, il monitoraggio è in grado di indicare quando esiste un problema, ma l'osservabilità aiuta a capire perché tale problema si è verificato.

Tracce, parametri e registri

Esistono tre pilastri principali che sono essenziali per l'osservabilità:

• Tracce
  Una traccia rappresenta il percorso di una richiesta in un sistema e può fornire un quadro dettagliato delle interazioni con i servizi. Le tracce di OpenTelemetry sono organizzate in span che contengono attributi ed eventi, e descrivono e contestualizzano il lavoro svolto in vari processi e servizi.
• Parametri
  I parametri sono rappresentazioni numeriche dei dati misurati in intervalli di tempo. Consentono il monitoraggio continuo delle prestazioni e del comportamento del sistema. In OpenTelemetry, la Metrics API può essere utilizzata per registrare, impostare e aggiungere parametri di sistema, offrendo strumenti per filtrare e aggregare l'analisi in un secondo momento.
• Registri
  I registri sono record basati su testo, generati da sistemi e applicazioni. Forniscono un resoconto cronologico degli eventi e possono essere fondamentali per il debugging e la comprensione del comportamento del sistema.

Sebbene questi tre elementi siano considerati da tempo i fattori più essenziali per l'osservabilità, l'aumento della scala e della complessità dei moderni sistemi distribuiti ha costretto questo modello tradizionale a evolversi. I professionisti hanno iniziato a riconoscere che i tre pilastri non sono isolati, bensì fondamentalmente interconnessi, e dovrebbero essere utilizzati in coordinamento tra loro.

OpenTelemetry svolge un ruolo cruciale nel consentire l'osservabilità nei sistemi distribuiti basati su microservizi. L'enfasi che mette sulla portabilità, la disponibilità di implementazioni e i kit di sviluppo software (SDK) nella maggior parte delle lingue, e in particolare i modelli di esportazione e raccolta, lo rendono uno strumento chiave per la raccolta e la distribuzione di dati appropriati per il sistema.

Con OpenTelemetry, i team possono raccogliere in modo efficiente i dati chiave di tracce e parametri, necessari per analizzare il comportamento del sistema. Questo allineamento con le pratiche di osservabilità consente una comprensione più profonda delle prestazioni del sistema, migliorando così la capacità di diagnosticare e risolvere i problemi.

Che cos'è il tracciamento in OpenTelemetry?

Proprio come le tracce sono uno dei tre pilastri dell'osservabilità, il tracciamento è una pratica cruciale all'interno dello sviluppo software, utilizzata in genere per la profilazione e l'analisi del codice delle applicazioni attraverso strumenti di debugging specializzati. Nel contesto di OpenTelemetry, il tracciamento assume un significato più sfumato e coincide più di frequente con il tracciamento distribuito, un concetto essenziale nelle architetture complesse di oggi.

Tracciamento distribuito

Il tracciamento distribuito rappresenta l'applicazione delle tecniche di tracciamento tradizionali alle moderne applicazioni basate su microservizi. A differenza delle applicazioni monolitiche in cui la diagnosi di un errore potrebbe prevedere di seguire una singola traccia dello stack, i sistemi distribuiti sono semplicemente troppo complessi per questo approccio: quando un'applicazione è costituita potenzialmente da migliaia di servizi eseguiti su numerosi host, le singole tracce diventano insufficienti. Il tracciamento distribuito risolve questo problema profilando le richieste man mano che si spostano attraverso i diversi confini del servizio, generando dati di alta qualità per l'analisi. Questo metodo fornisce funzionalità quali:

• Rilevazione di anomalie 
• Modellazione del carico di lavoro 
• Diagnosi dei problemi allo stato stazionario

Tracce e span

In OpenTelemetry, una traccia è un insieme di span collegati, ovvero operazioni denominate e temporizzate che rappresentano un'unità di lavoro in una richiesta. Uno span può avere uno span principale oppure può essere un root span, che descrive la latenza end-to-end dell'intera traccia. Gli span secondari rappresentano le operazioni secondarie all'interno della traccia.

• Root span
  Il punto di origine o di inizio della traccia, che rappresenta l'intera latenza della richiesta. 
• Span secondario
  Una determinata operazione secondaria all'interno della traccia.

Gli span incapsulano le informazioni essenziali, tra cui il nome dell'operazione, i timestamp di inizio e fine, gli eventi e gli attributi che si sono verificati durante lo span. Contengono inoltre collegamenti ad altri span e allo stato dell'operazione.

Attributi ed eventi

Data la complessità dei dati delle tracce dei sistemi distribuiti, avere accesso al contesto e ad altri dettagli pertinenti può fare una grande differenza in positivo nell'analisi dei dati. In OpenTelemetry, questi tag sono noti come attributi ed eventi:

• Attributi
  Coppie di valori chiave (note su OpenTracing come "tag") che possono essere aggiunte a uno span per facilitare l'analisi dei dati delle tracce.
• Eventi
  Stringhe con timestamp e con una serie opzionale di attributi che forniscono una descrizione più approfondita, consentendo un'analisi più dettagliata.

Tracer e propagatori

Gli span in OpenTelemetry sono generati dal Tracer, un oggetto che tiene traccia dello span al momento attivo e consente la creazione di nuovi span. Gli oggetti propagatori supportano il trasferimento del contesto oltre i confini dei processi, un aspetto fondamentale del tracciamento nei sistemi distribuiti. Il Tracer invia gli span completati all'esportatore dell'SDK di OTel, responsabile dell'invio degli span a un sistema backend per un'ulteriore analisi.

Sebbene il tracciamento fornisca informazioni dettagliate sulle singole richieste e operazioni, si lega anche al contesto più ampio di osservabilità all'interno di OpenTelemetry, inclusi i parametri. Collegando i dati delle tracce ai parametri pertinenti, le organizzazioni possono ottenere una comprensione completa del comportamento e delle prestazioni del sistema.

Nel contesto di OpenTelemetry, la Metrics API è progettata per elaborare e riepilogare continuamente le misurazioni non elaborate. Ciò offre alle organizzazioni una maggiore visibilità sui parametri operativi fondamentali, tra cui l'utilizzo della memoria dei processi, i tassi di errore e altro ancora. I parametri possono essere inviati a vari strumenti per l'aggregazione e la registrazione. L'OpenTelemetry Metrics API classifica gli strumenti metrici in base al loro significato semantico anziché al tipo finale di valore che esportano.

Strumenti metrici in OpenTelemetry

La Metrics API fornisce sei strumenti metrici distinti, ciascuno dei quali svolge una funzione specifica. Questi strumenti vengono creati e definiti tramite chiamate a una API Meter, il punto di ingresso dell'utente all'SDK. Gli strumenti metrici possono essere sincroni o asincroni.

Strumenti sincroni

Gli strumenti sincroni vengono richiamati all'interno di una richiesta e possiedono un contesto distribuito associato. Gli strumenti sincroni includono:

• Contatore
  Lo strumento Contatore accetta valori positivi con la funzione Add(). Ciò è ideale per il conteggio di dati come i byte ricevuti, le richieste completate e la misurazione dell'incidenza degli errori, ed è particolarmente adatto per le misurazioni della frequenza.
• UpDownCounter
  Un'estensione della funzionalità del contatore, UpDownCounter elabora incrementi sia positivi che negativi tramite la funzione Add(). È utile per monitorare le quantità come le richieste attive, la memoria in uso e le dimensioni della coda.
• ValueRecorder
  Lo strumento ValueRecorder acquisisce i valori per gli eventi discreti utilizzando la funzione Record(). Viene utilizzato per acquisire latenza, dimensioni della richiesta e lunghezza della coda, enfatizzando una distribuzione dei valori.

Strumenti asincroni

A differenza degli strumenti sincroni, gli strumenti asincroni non hanno un contesto associato. Questi strumenti vengono segnalati da una callback e chiamati solo una volta per intervallo di raccolta. Gli strumenti sincroni includono:

• SumObserver
  Lo strumento SumObserver utilizza la funzione Observe() per le somme monotone asincrone ed è adatto soprattutto per dati come mancati risconti nella cache e CPU di sistema. 
• UpDownSumObserver
  UpDownSumObserver è un contatore asincrono e non monotono che accetta somme positive e negative con la funzione Observe(). Questo strumento viene utilizzato per misurazioni che registrano l'aumento e il calo delle somme, come la dimensione dell'heap del processo.
• ValueObserver
  Infine, ValueObserver consente alle organizzazioni di avere un controllo capillare sulle misurazioni non additive utilizzando la funzione Observe(). Ciò è ideale quando le misurazioni si concentrano su una distribuzione.

La composizione degli eventi metrici

Gli eventi metrici acquisiti da qualsiasi strumento consistono in un timestamp, una definizione dello strumento (nome, tipo, descrizione, unità di misura), set di etichette (chiavi e valori), valore (numero intero o a virgola mobile), risorse associate all'SDK e contesto distribuito (solo per eventi sincroni). La varietà di strumenti metrici disponibili offre flessibilità nell'acquisizione di diversi tipi di dati, agevolando l'analisi e il monitoraggio di vari attributi del sistema.

Che si tratti del monitoraggio dei tassi di errore, della latenza o dell'utilizzo delle risorse, gli strumenti metrici di OpenTelemetry offrono diverse opzioni per consentire agli sviluppatori di ottenere informazioni fondamentali sulle loro applicazioni.

L'esportatore è responsabile della divisione in batch e del trasporto dei dati telemetrici in un sistema backend per l'analisi e l'invio di avvisi. Il modello di esportazione di OpenTelemetry supporta l'integrazione della strumentazione a tre diversi livelli:

• Integrazione a livello del servizio
  Ciò comporta la dichiarazione di una dipendenza dal pacchetto OpenTelemetry pertinente all'interno del codice e la sua conseguente implementazione.
• Dipendenze dalle librerie
  Simili all'integrazione a livello del servizio, ma specifiche per le librerie, che in genere dichiarano solo una dipendenza dall'OpenTelemetry API.
• Dipendenze della piattaforma
  Si tratta di componenti software indipendenti che supportano il proprio servizio, come Envoy e Istio. Implementano la loro copia di OpenTelemetry ed emettono un contesto di tracce utili per il proprio servizio.

L'interfaccia dell'esportatore, implementata dagli SDK di OpenTelemetry, utilizza un modello plugin che traduce i dati telemetrici nel formato richiesto per un particolare sistema backend, prima di trasmettere i dati. Questo modello supporta anche la composizione e il concatenamento degli esportatori, facilitando la condivisione delle funzionalità tra diversi protocolli.

Uno dei vantaggi significativi dell'approccio di OpenTelemetry è la facilità di cambio o aggiunta di componenti di esportazione. Ciò lo distingue da OpenTracing, in cui cambiare il sistema richiede la sostituzione dell'intero componente del Tracer.

Sebbene il modello di esportazione offra una grande comodità, alcuni vincoli di natura organizzativa o tecnica possono impedire il facile reimpiego di un servizio per aggiungere un nuovo esportatore. Il collettore di OpenTelemetry è progettato per fungere da "sink" per i dati telemetrici provenienti da più processi, esportandoli in vari sistemi backend, come Osservabilità del cloud ServiceNow, Jaeger o Prometheus. Il collettore può essere impiegato come agente insieme a un servizio o come applicazione remota:

• Agente
  Implementato con il proprio servizio, eseguito come processo separato o sidecar. 
• Collettore remoto
  Implementato separatamente in un container o in una macchina virtuale, riceve i dati telemetrici da ciascun agente e li esporta nei sistemi backend.

OpenTelemetry è composto dai seguenti componenti principali:

• Una specifica per tutti i componenti
• Un protocollo standard che definisce la forma dei dati telemetrici
• Convenzioni semantiche che definiscono uno schema di denominazione standard per i tipi di dati telemetrici comuni
• API che definiscono come generare dati telemetrici
• Un ecosistema di librerie che implementa la strumentazione per librerie e framework comuni
• Componenti di strumentazione automatica che generano dati telemetrici senza richiedere modifiche al codice
• SDK linguistici che implementano la specifica, le API e l'esportazione dei dati telemetrici
• Collettore OpenTelemetry, un proxy che riceve, elabora ed esporta i dati telemetrici
• Altri strumenti vari, come OpenTelemetry Operator per Kubernetes

Compatibilità

Compatibile con una vasta gamma di integrazioni degli ecosistemi open source, OpenTelemetry è supportato anche da un elevato numero di fornitori, molti dei quali forniscono supporto commerciale per OpenTelemetry e contribuiscono direttamente al progetto.

Possibilità di estensione

OpenTelemetry è progettato per essere estensibile. Alcuni esempi di come può essere esteso includono:

• Aggiunta di un ricevitore a OpenTelemetry Collector per supportare i dati telemetrici provenienti da una fonte personalizzata
• Caricamento della strumentazione personalizzata in un SDK
• Creazione della distribuzione di un SDK o di OpenTelemetry Collector personalizzata in base a un caso di utilizzo specifico
• Creazione di un nuovo esportatore per un backend personalizzato che non supporta ancora il protocollo OpenTelemetry (OTLP)
• Creazione di un propagatore personalizzato per un formato di propagazione del contesto non standard

Sebbene la maggior parte degli utenti non debba estendere OpenTelemetry, il progetto è pensato per renderlo possibile a quasi tutti i livelli.

Perché OpenTelemetry è importante?

Con l'ascesa del cloud computing, delle architetture dei microservizi e di requisiti aziendali sempre più complessi, la necessità di ottenere l'osservabilità non è mai stata così grande.

Per rendere un sistema osservabile, deve essere strumentale. In altre parole, il codice deve emettere tracce, parametri e registri. I dati strumentali devono quindi essere inviati a un backend di osservabilità.

OpenTelemetry fa due cose importanti:

• Consente di possedere i dati generati anziché rimanere bloccati su un formato o uno strumento dati proprietario.
• Consente di apprendere un'unica serie di API e convenzioni

Questi due aspetti, uniti tra loro, offrono a team e organizzazioni la flessibilità di cui hanno bisogno nel mondo informatico di oggi.

OpenTelemetry non è un backend di osservabilità come Jaeger, Prometheus o i fornitori commerciali. OpenTelemetry si concentra sulla generazione, la raccolta, la gestione e l'esportazione dei dati telemetrici. L'archiviazione e la visualizzazione di tali dati sono intenzionalmente lasciate ad altri strumenti.

La necessità di avere una visibilità end-to-end è più importante che mai. OpenTelemetry offre un approccio standardizzato alla raccolta di dati telemetrici in applicazioni e linguaggi di programmazione differenti. Offrendo informazioni complete sul comportamento del sistema, OTel consente alle organizzazioni di ottimizzare le prestazioni, risolvere i problemi e offrire un'esperienza utente fluida. Ma quando si parla di osservabilità, ci sono sempre margini di miglioramento.

Osservabilità del cloud ServiceNow, noto in precedenza come Lightstep, supporta OpenTelemetry come metodo per ottenere dati telemetrici (tracce, registri e parametri) mentre le richieste viaggiano attraverso servizi e altre infrastrutture. Osservabilità del cloud acquisisce i dati OpenTelemetry tramite il protocollo OpenTelemetry (OTLP) nativo. I dati OTLP possono quindi essere esportati in Osservabilità del cloud tramite HTTP o gRPC.

Per migliorare ulteriormente l'osservabilità e la governance negli ambienti cloud nativi, ServiceNow ha lanciato inoltre il Connettore Service Graph per OpenTelemetry (SGC). Sfruttando i dati di OpenTelemetry e il backend di Osservabilità del cloud ServiceNow, questa soluzione rivoluziona il modo in cui le aziende ottengono visibilità e informazioni approfondite sulle proprie applicazioni cloud native e sull'infrastruttura Kubernetes. SGC rileva e mappa automaticamente le dipendenze a livello del servizio, creando una topologia del servizio accurata e aggiornata. Consentendo alle organizzazioni di valutare l'impatto dei cambiamenti, semplificando la gestione degli incidenti e promuovendo la collaborazione interfunzionale, questa soluzione migliora l'efficienza, riduce i rischi e contribuisce a garantire la miglior osservabilità possibile in ambienti IT complessi.

Scopri le funzionalità trasformative del Connettore Service Graph per OpenTelemetry; contatta ServiceNow oggi stesso!