Cosa sono le metriche di OpenTelemetry?

Come i log e le tracce di OpenTelemetry e le metriche OTel forniscono segnali di telemetria standardizzati che utilizzano un modello di dati e un protocollo di trasmissione comune, neutrali rispetto al linguaggio (OpenTelemtetry Protocol o OTLP, per essere precisi) per inserire dati da diverse fonti, sistemi e formati e inviarli ai backend di observability. 

Le metriche OTel si basano sullo strumentazione OpenTelemetry per raccogliere dati di serie temporali come uso di CPU e memoria, throughput, tassi di errore, conteggio delle richieste e tempi di risposta, da applicazioni e componenti infrastrutturali durante l'esecuzione. Dopo che gli sviluppatori hanno strumentato il codice per registrare le metriche necessarie, OTel consente di aggregarle ed esportarle verso qualsiasi strumento di observability di backend per il storage, la query e la visualizzazione, il tutto senza modificare la strumentazione.

Le metriche sono tipicamente i primi segnali di telemetria a rivelare un problema di sistema. Nel framework OTel, sono integrate con log (record immutabili di eventi di sistema discreti) e tracce (il percorso end-to-end di una richiesta dati) che si basano sugli stessi concetti e metadati.

Queste dinamiche consentono agli sviluppatori e ai tecnici dell'affidabilità dei siti (SRE) di utilizzare le metriche come sistema di allerta precoce di alto livello. Possono seguire l'intero percorso di un guasto (incluse le metriche per ogni servizio che il componente guasto ha interagito con) in una sola visione coerente e spostarsi rapidamente su tracce e log per l'analisi della causa principale.

In pratica, ciò significa che i team IT possono passare da "questo endpoint è lento" a "queste specifiche richieste e dipendenze sono il problema" in pochi clic.

Inoltre, i protocolli di standardizzazione di OTel facilitano la correlazione automatica dei segnali tra i fornitori di observability, offrendo alle aziende la flessibilità di cambiare gli strumenti di observability ogni volta che scelgono o utilizzano più strumenti contemporaneamente.

Le metriche sono un componente fondamentale di OpenTelemetry. OpenTelemetry è un framework di observability open source che include una raccolta di kit di sviluppo software (SDK), application programming interface (API) neutrali rispetto al fornitore e altri strumenti per la strumentazione di applicazione, sistema e dispositivo.

Il codice della strumentazione variava notevolmente e nessun fornitore commerciale offriva uno strumento in grado di raccogliere dati da ogni app e servizio su una rete. Questa lacuna di funzionalità rendeva difficile (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.

Supponiamo che un team di sviluppo voglia cambiare gli strumenti di backend. Dovrebbero ristrumentare completamente il loro codice e configurare nuovi agenti (componenti software che eseguono compiti automatici di build e release) per inviare dati di telemetria ai nuovi server. Gli approcci frammentati hanno creato silos di dati e confusione, rendendo difficile risolvere efficacemente i problemi di performance.

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 dei sistemi, aiutando i team a semplificare il monitoraggio e l'observability negli ecosistema distribuiti.

Le metriche di OpenTelemetry si basano su un gruppo di componenti correlati che, insieme, definiscono come le metriche vengono prodotte, descritte e inviate ai backend di observability. Ecco alcuni esempi:

Gli strumenti sono gli strumenti che il codice utilizza per registrare i valori delle metriche. Registrano i valori in due modi: in modo sincrono (direttamente nel percorso di esecuzione, durante l'esecuzione del codice) e in modo asincrono (ogni volta che l'SDK richiede valori dal codice).

Poiché si seguono in linea con l'operazione, gli strumenti sincroni possono catturare il contesto attuale delle tracce e gli attributi relativi all'evento, rendendo più facile il correlare delle metriche raccolte con log e tracce.

Gli strumenti asincroni vengono aggiornati da funzioni di callback basate su pull che l'SDK richiama in base a un intervallo di raccolta predeterminato. Questi strumenti sono utili per registrare valori che vengono campionati periodicamente, invece che su richiesta di ogni utente (ad esempio l'uso della CPU o la memoria). 

La strumentazione OTel si colloca tra l'applicazione e la pipeline delle metriche, trasformando eventi, come "richiesta HTTP completata", in misurazioni strutturate che l'SDK può aggregare ed esportare. Ogni tipo di strumento metrico è ottimizzato per un modello di misura specifico e ha una strategia di aggregazione associata che descrive come l'SDK dovrebbe combinare le singole misurazioni in metriche esportate.

Alcuni tipi di strumenti comuni sono:

• I contatori sono strumenti sincroni che registrano gli incrementi che aumentano nel tempo (come il numero totale di richieste o il numero totale di byte inviati dall'inizio del processo). Anche i contatori sono monotoni, quindi ogni volta che registrano una nuova misura, la aggiungono al valore esistente invece di sostituirlo.

• I contatori UpDown sono strumenti sincroni che registrano valori che possono aumentare o diminuire nel tempo (numero di utenti attivi o dimensione della coda, ad esempio). A differenza dei Counter standard, gli UpDown Counter non sono monotoni, quindi regolano i totali verso l'alto o verso il basso sostituendo i valori esistenti.

• I Contatori asincroni e i contatori asincroni UpDown sono simili ai loro corrispettivi sincroni, ma registrano i valori una volta per ogni esportazione invece di raccoglierli durante l'esecuzione del codice.

• Gli indicatori sono strumenti sincroni che registrano valori che possono aumentare o diminuire arbitrariamente ad ogni invio di dati, rappresentando i valori nel momento in cui vengono raccolti dal codice. Oltre agli indicatori sincroni, la raccolta delle metriche richiede indicatori osservabili, ovvero strumenti asincroni che estraggono valori correnti ogni volta che il backend delle metriche raccoglie dati.
  
  I misuratori catturano istantanee dei valori più o meno nello stesso modo in cui le fotocamere catturano le istantanee del soggetto previsto. E poiché i calibri non sono cumulativi, vengono tipicamente applicati a valori non additivi dove la somma non avrebbe senso (ad esempio l'uso della memoria o la temperatura).  

• Gli istogrammi sono strumenti sincroni che rilevano quante misurazioni rientrano in diversi intervalli di valori, invece di tracciare un singolo numero (come un valore totale o corrente). Hanno suddiviso i valori in "categorie", consentendo ai team IT di calcolare i percentili e comprendere la distribuzione dei valori per metriche quali la durata della richiesta, la latenza e la dimensione del payload.

OTel definisce un modello dati e una serie temporale standardizzata per metriche che trasformano eventi metrici individuali in serie di numeri puliti, interrogabili e basate sul tempo, che i team IT possono memorizzare e analizzare su piattaforme di observability.

OpenTelemetry descrive le metriche utilizzando tre modelli correlati: il modello Eventi (misurazioni grezze dagli strumenti), il modello di flusso OTLP (come queste misurazioni vengono raggruppate e inviate) e il modello delle serie temporali (come i backend le memorizzano).

In pratica, il codice dell'applicazione registra eventi utilizzando il modello Eventi, l'SDK/Collector li trasforma in flussi OTLP e la piattaforma backend li memorizza come serie temporali, come "richieste al secondo per il servizio X con stato 200" nel tempo.

Le convenzioni semantiche, chiamate anche convenzioni di denominazione, definiscono nomi standardizzati, unità e chiavi di attributo per metriche comuni in modo che servizi e librerie diversi producano telemetria coerente. Ad esempio, le convenzioni prescrivono nomi come "http.server.duration" per la latenza delle richieste del HTTP Server e consiglia unità come secondi o millisecondi per la durata.

L'uso delle convenzioni semantiche di OTel permette ai team di inserire metriche in dashboard predefiniti e sistemi di allerta che si aspettano uno schema specifico, riducendo così il tempo trascorso a configurazioni personalizzate. Rende anche più facile la collaborazione tra team perché tutti parlano lo stesso "linguaggio delle metriche" tra i microservizio.

Inoltre, le caratteristiche di propagazione del contesto possono collegare metriche con tracce correlate (usando esemplari) e log trasportando contesto condiviso, come identificatori di traccia o span, attraverso i boundary del servizio.

Ad esempio, un propagatore OTel può estrarre il contesto in entrata da un gestore di richieste, avviare un intervallo di traccia con esso e utilizzare lo stesso contesto per registrare le metriche di latenza e scrivere voci di log. In questo modo, sia il punto di metriche che la linea di log vengono etichettati con la traccia corrente.

Quando il codice dell'app effettua una chiamata a valle, il propagatore inserisce lo stesso contesto nella richiesta in uscita. Il codice lo estrae, avvia un proprio span figlio e utilizza tale contesto per le proprie metriche e i propri log, mantenendo così tutto, da entrambi i servizi, collegato alla stessa traccia end-to-end.

Gli attributi, noti anche come etichette, tag o dimensioni, sono coppie chiave-valore associate a singole misurazioni o punti dati aggregati. Definiscono completamente o parzialmente una serie temporale insieme al nome delle metriche, al tipo di aggregazione e all'unità. Senza attributi, tutte le misurazioni per una metrica collasserebbero in una serie indifferenziata.

Aggiungere attributi (come nome del servizio, endpoint, codice di stato HTTP, regione o ID tenant) trasforma metriche semplici in flussi di metriche dimensionali e specializzati che i team possono analizzare e selezionare negli strumenti di observability. I team possono ottenere visualizzazioni ad alta risoluzione filtrate o raggruppate in base a qualsiasi dimensione scelgano.

Un buon design degli attributi bilancia anche il dettaglio con la cardinalità delle metriche (il numero di valori unici che un attributo può assumere), così i team possono evitare l'esplosione delle etichette pur eseguendo query utili.

Una misurazione è una singola lettura a livello di evento effettuata da uno strumento in un momento specifico e spesso accompagnata da attributi. Ad esempio, al termine di una richiesta HTTP, potresti registrare una latenza di 120 millisecondi con attributi come route="/login" e status_code=200 che rappresentano il percorso e il codice di stato.

Ogni singola registrazione rappresenta una misurazione separata che descrive quanto accaduto durante quella specifica operazione.

Le misurazioni vengono brevemente memorizzate all'interno dell'SDK, che poi converte le misurazioni grezze in punti dati all'interno di flussi metrici più grandi. Invece di mostrare ogni singola richiesta, un dato aggregato potrebbe mostrare "per route /login con stato 200, dalle 10:00:00 alle 10:00:10, ci sono state 500 richieste con una durata totale di 25 secondi." Sono questi punti dati che vengono infine esportati e memorizzati nei backend di observability.

L'API di metriche OpenTelemetry è l'insieme di interfacce che il codice di applicazione chiama per produrre metriche. È progettato per essere indipendente dal fornitore, disaccoppiando la strumentazione dall'implementazione concreta dell'SDK. I team IT possono scrivere strumentazione una volta (usando l'API standard) e poi scambiare SDK, esportatori e backend senza dover fare passaggi aggiuntivi.

La struttura dell'API OTel per le metriche è costituita da tre interfacce principali: i fornitori di contatori, i contatori e gli strumenti di metriche.

I fornitori di contatori sono il punto di ingresso dell'API e sono responsabili della creazione delle istanze dei contatori. Determinano quali lettori di metriche ed esportatori utilizzare, quali visualizzazioni e aggregazioni applicare e con quale frequenza raccogliere ed esportare dati. Il Meter Provider in genere si carica una volta durante l'avvio dell'applicazione (spesso come fornitore globale), quindi tutti i contatori e gli strumenti condividono definizioni di risorse e pipeline di esportazione coerenti.

I misuratori sono gli oggetti utilizzati dal codice dell'applicazione per creare contatori, istogrammi e indicatori. Ogni contatore è in genere chiamato per una libreria o un servizio (ad esempio, "bank.payment"), Quindi le metriche provenienti da quel codice possono essere raggruppate e identificate in modo coerente.

I misuratori non memorizzano i dati da soli; invece, servono come stabilimenti per strumenti e trasmettono misurazioni registrate all'SDK sottostante per aggregazione ed esportazione. Poiché i contatori vengono forniti da un provider di contatori, funzionano sempre con la configurazione, le viste e gli esportatori definiti da tale provider.

Gli strumenti forniscono quindi istruzioni in modo che il codice possa riportare le misurazioni con attributi.

L'SDK OpenTelemetry è un'implementazione concreta dell'API OpenTelemetry che trasforma le chiamate API in veri e propri punti dati di telemetria. Fornisce una libreria specifica per linguaggio (come Java™ o Python) che raccoglie, aggrega e prepara dati metrici per l'esportazione.

Gli SDK gestiscono i cicli di vita della strumentazione, gestiscono lo storage in-memory per le misurazioni, eseguono callback per strumenti asincroni, applicano aggregazioni e viste configurate e controllano gli intervalli di raccolta delle metriche (in genere 10-60 secondi).

All'interno dell'SDK, i processori applicano l'aggregazione e la logica aggiuntiva, tra cui il filtro, la limitazione della velocità o la trasformazione dei flussi metrici prima di inviarli successivamente.

Gli esportatori convertono i punti dati metrici elaborati in formati specifici del backend e li inviano a backend esterni o piattaforme di observability utilizzando protocolli supportati (come OTLP).

I team potrebbero scegliere di concatenare più esportatori nell'SDK per il supporto multi-backend in ambienti che richiedono alta disponibilità e ridondanza. In questi casi, gli OpenTelemetry Collectors agiscono come proxy intelligenti in grado di inviare metriche a più backend contemporaneamente, riprova i tentativi di esportazione o autenticare i dati su larga scala. 

Le aggregazioni definiscono il modo in cui le singole misurazioni grezze vengono combinate matematicamente in statistiche riepilogate che i backend memorizzano e interrogano come punti dati di serie temporali. I dati non elaborati vengono accumulati dall'aggregatore dell'SDK in un singolo punto dati per ogni intervallo di raccolta per ogni serie temporale unica.

I modelli di aggregazione più comuni includono:

• Somma, che somma tutti i valori per le quantità cumulative (come i byte trasferiti).

• LastValue, che conserva solo la misura più recente, scartando quelle precedenti.

• Aggregazione di istogrammi, che raggruppa i valori in bucket così che i team possano calcolare percentili e rilevare outlier.

• Drop, che scarta tutti i valori per protezione contro dati ad alta cardinalità (dati con un alto numero di valori unici).

Le aggregazioni contengono anche metadati di temporalità, che indicano ai backend come interpretare un valore di metriche nel tempo. I due tipi principali sono:

• I valori cumulativi riflettono il totale dall'inizio del processo. Questi valori si azzerano solo al riavvio del processo e i backend calcolano le velocità di calcolo differenziando i punti dati.

• I valori Delta riflettono le modifiche rispetto all'ultima raccolta di dati. I backend possono sommare direttamente i delta per determinare i tassi.

Gli SDK applicano automaticamente l'aggregazione corretta in base al tipo di strumento. Consentono inoltre ai team IT di passare da semplici totali a istogrammi ricchi o altri algoritmi lasciando invariati gli strumenti.

Le metriche mostrano tendenze e inviano avvisi, le tracce rivelano il percorso delle richieste e i log forniscono un ricco contesto a livello di evento. Corrispondere metriche con tracce e logs collega i tre principali segnali di observability (noti come "pilastri dell'observability") in modo che i team possano ottenere una visione stratificata del comportamento del sistema.

Le metriche possono, ad esempio, mostrare tendenze aggregate come "il tasso di errore ha raggiunto il picco alle 14:15", ma non possono rivelare quali richieste sono fallite o perché. Le tracce fanno luce sui percorsi problematici delle singole richieste tra i servizi, ma senza metriche non possono aiutare i team a determinare se una richiesta errata sia un outlier o un problema sistemico. I log forniscono messaggi di errore ed eventi dettagliati, ma senza contesto sono solo rumore.

Correlare tutti e tre i segnali consente ai team IT di spostare senza problemi dalle tendenze delle metriche di alto livello alla traccia interessata e ai relativi log in pochi secondi.

Le metriche OTel differiscono fondamentalmente dalle metriche tradizionali. Le metriche tradizionali si riferiscono tipicamente ad approcci di monitoraggio legacy che si concentrano su semplici e predefiniti contatori per l'uso delle risorse. Queste metriche enfatizzano misurazioni a livello di host o specifiche per applicazione. 

Le metriche OpenTelemetry, al contrario, fanno parte di un framework unificato di observability indipendente dal fornitore che standardizza la raccolta tra trace, log e metriche per ambienti IT distribuiti. Si basano sulle metriche tradizionali, fornendo un modello di dati e una strumentazione più flessibili, tra cui UpDownCounters per le variazioni bidirezionali e istogrammi che supportano intervalli esponenziali. Forniscono inoltre attributi, unità e timestamp espliciti per arricchire le metriche.

Le metriche di OTel si differenziano anche dalle metriche tradizionali in termini di progettazione, metodi di raccolta e applicabilità ai sistemi moderni.

Le caratteristiche metriche presentano un modello full stack rigido che accoppia strettamente raccolta, storage e interrogazione, spesso utilizzando valori cumulativi da contatori di base, indicatori, riassunti e istogrammi con bucket espliciti (che richiedono il bucketing manuale).

Le metriche OpenTelemetry impiegano un design modulare, a tre livelli (con un'API, un SDK e un protocollo) che separa la generazione del segnale dall'elaborazione e dall'esportazione. Questa configurazione consente alle metriche OTel di supportare caratteristiche avanzate, come temporalità delta, valori interi, metadati minimi e massimi sugli istogrammi e istogrammi esponenziali per la scala dinamica.

Gli approcci tradizionali si basano sullo scraping dei dati basato su pull dagli endpoint API esposti, principalmente per le metriche isolate. Utilizzano strumentazione manuale e offrono un supporto limitato per tracce o registri, il che porta a pipeline di telemetria e observability frammentate.

OpenTelemetry utilizza OTLP (un protocollo binario) per la raccolta dati basata su push, consentendo la raccolta unificata di tracce, metriche e log tramite strumenti automatici e manuali. OTel fornisce anche un Collector per facilitare la trasformazione dei dati, il batching e il routing verso gli strumenti backend, che aiuta i team IT ad affrontare le preoccupazioni relative allo storage delle applicazioni.

I dati di telemetria tradizionali funzionano bene per configurazioni semplici e monolitiche. Tuttavia, fallisce negli ambienti di microservizi a causa di scarse funzionalità di tracciamento, problemi di blocco da fornitore e segnali isolati che oscurano le dipendenze e non riescono a scoprire guasti a cascata.

OpenTelemetry eccelle in ambienti cloud-native e distribuiti, perché fornisce telemetria correlata e indipendente dal fornitore per una visibilità end-to-end dei flussi di richieste tra servizi, colli di bottiglia di latenza e diagnostiche delle risorse. OTel supporta anche il campionamento e l'integrazione di strumenti ibridi, che aiutano la telemetria e la strumentazione a scalare insieme all'ambiente IT. 

Le metriche OpenTelemetry forniscono misurazioni quantitative standardizzate che aiutano a migliorare l'observability nelle architetture moderne. Offrono insight dettagliati sulle prestazioni del sistema, consentendo a sviluppatori e ingegneri di implementare strategie proattive di risoluzione dei problemi e ottimizzazione.

Gli altri benefici includono: