In passato, quando parlavamo di backend, di solito facevamo riferimento a una grande applicazione con un singolo, grande database, e il logging era sufficiente per il monitoraggio. Ora, grazie a tecnologie come   ,   sono diventati lo standard. Le applicazioni sono più numerose e distribuite, e il logging tradizionale non è più sufficiente per   e la diagnosi dei problemi nelle nostre applicazioni. Kubernetes i microservizi il debug  Un'ottima soluzione per organizzare il monitoraggio è OpenTelemetry, un moderno toolkit che può essere utilizzato per il debug e l'analisi delle prestazioni dei sistemi distribuiti.  Questo articolo è destinato ai professionisti IT che desiderano ampliare le proprie conoscenze in materia di ottimizzazione del backend. Di seguito, spiegheremo in dettaglio cos'è OpenTelemetry, i suoi concetti chiave e i problemi che aiuta a risolvere. Se sei interessato a come OpenTelemetry può cambiare il tuo approccio al monitoraggio e al debug dei sistemi backend, migliorandone l'affidabilità e l'efficienza, continua a leggere.  Una breve storia di OpenTelemetry  Le grandi aziende tecnologiche hanno affrontato per la prima volta la sfida della registrazione e del tracciamento distribuiti alla fine degli anni 2000. Nel 2010, Google ha pubblicato un documento,  , che ha gettato le basi per lo strumento di tracciamento di Twitter, Zipkin, rilasciato nel 2012.   Dapper, un'infrastruttura di tracciamento di sistemi distribuiti su larga scala  Nel 2014 è emerso Kubernetes, semplificando notevolmente lo sviluppo di microservizi e altri sistemi distribuiti nel cloud. Ciò ha portato molte aziende a riscontrare problemi con il logging e il tracciamento distribuiti nei microservizi. Per standardizzare il tracciamento distribuito, è stato creato lo standard OpenTracing, adottato da CNCF, e dal progetto OpenCensus di Google.  Nel 2019, i progetti OpenTracing e OpenCensus hanno annunciato una fusione sotto il nome di OpenTelemetry. Questa piattaforma combina le best practice accumulate nel corso di molti anni, consentendo un'integrazione fluida di tracciamento, registrazione e metriche in qualsiasi sistema, indipendentemente dalla loro complessità.  Oggi, OpenTelemetry non è solo un progetto; è uno standard di settore per la raccolta e la trasmissione di dati di telemetria. È sviluppato e supportato da una comunità di specialisti e aziende leader di mercato come Google e Microsoft. Il progetto continua a evolversi, acquisendo nuove capacità per semplificare il processo di integrazione e utilizzo.    Cosa c'è dentro?  OpenTelemetry è un set completo di pratiche e strumenti che definiscono quali segnali un'applicazione può generare per interagire con il mondo esterno e come questi segnali possono essere raccolti e visualizzati per monitorare lo stato delle applicazioni e del sistema nel suo complesso. I tre tipi principali di segnali sono   e   . tracciamento, registrazione raccolta di metriche  **Diamo un'occhiata più da vicino a ciascun componente: \   Contesti  OpenTelemetry introduce il concetto di contesti operativi. Un contesto include principalmente attributi come   (identificatore per l'operazione corrente) e   (identificatore per una sotto-richiesta, con ogni nuovo tentativo di una sotto-richiesta avente un   univoco). `trace_id` `span_id` `span_id`  Inoltre, un contesto può contenere informazioni statiche, come il nome del nodo in cui è distribuita l'applicazione o il nome dell'ambiente (prod/qa). Questi campi, noti come risorse nella terminologia OpenTelemetry, sono allegati a ogni log, metrica o traccia per una ricerca più semplice. I contesti possono anche includere dati dinamici, come l'identificatore dell'endpoint corrente (   ), che può essere selettivamente allegato a gruppi di log, metriche o tracce. `http_path: "GET /user/:id/info"`  I contesti OpenTelemetry possono essere passati tra diverse applicazioni utilizzando protocolli di propagazione del contesto. Questi protocolli consistono in set di intestazioni che vengono aggiunti a ogni richiesta HTTP o gRPC o alle intestazioni dei messaggi per le code. Ciò consente alle applicazioni downstream di ricostruire il contesto dell'operazione da queste intestazioni.   Ecco alcuni esempi di propagazione del contesto:    Questo è un set di intestazioni (   ) originariamente sviluppato per il sistema di tracciamento Zipkin. È stato adattato in OpenTracing e utilizzato da molti strumenti e librerie. B3-Propagation trasporta   /   e un flag che indica se il campionamento è necessario. B3-Propagation x-b3-* trace_id span_id    Sviluppato dal gruppo di lavoro W3C, questo standard unifica vari approcci di propagazione del contesto in un unico standard ed è l'impostazione predefinita in OpenTelemetry. Un buon esempio di applicazione di questi standard è il tracciamento dell'esecuzione di una richiesta che passa attraverso microservizi implementati con tecnologie diverse senza compromettere l'accuratezza del monitoraggio e del debug. Contesto di traccia W3C   Tracciamento     Il tracciamento è il processo di registrazione e successiva visualizzazione della cronologia del percorso di una richiesta attraverso più microservizi.  Nella visualizzazione, ogni barra è chiamata "span" e ha un   univoco. Lo span radice è chiamato   e ha un   , che funge da identificatore per l'intera richiesta. "span_id" "trace" "trace_id"   Questo tipo di visualizzazione consente di:  Analizzare il tempo di esecuzione delle richieste su diversi sistemi e database per identificare i colli di bottiglia che necessitano di ottimizzazione.  Rileva le dipendenze cicliche tra i servizi.  Trova richieste duplicate. Utilizzando i dati di tracciamento, puoi anche creare analisi aggiuntive, come la creazione di una mappa di microservizi o la distribuzione del tempo tra sistemi diversi durante l'elaborazione delle operazioni. Anche se non utilizzi i dati di tracciamento per visualizzare le linee temporali, OpenTelemetry genera comunque   e   da utilizzare in altri segnali. trace_id span_id   Registri  Nonostante la sua apparente semplicità, la registrazione rimane uno degli strumenti più potenti per la diagnosi dei problemi. OpenTelemetry migliora la registrazione tradizionale aggiungendo informazioni contestuali. In particolare, se è presente una traccia attiva, gli attributi `trace_id` e `span_id` vengono aggiunti automaticamente ai registri, collegandoli alla cronologia della traccia. Inoltre, gli attributi del registro possono includere informazioni statiche dal contesto OpenTelemetry, come l'identificativo del nodo, nonché informazioni dinamiche, come l'identificativo dell'endpoint HTTP corrente (`http_path: "GET /user/:id"`).  Utilizzando `trace_id`, puoi trovare i log di tutti i microservizi associati alla richiesta corrente, mentre `span_id` ti consente di distinguere tra sotto-richieste. Ad esempio, nel caso di nuovi tentativi, i log di tentativi diversi avranno `span_id` diversi. Utilizzando questi identificatori è possibile analizzare rapidamente il comportamento dell'intero sistema in tempo reale, velocizzando la diagnosi dei problemi e migliorando stabilità e affidabilità.   Metrica  La raccolta di metriche fornisce dati quantitativi sulle prestazioni del sistema, come latenza, tassi di errore, utilizzo delle risorse e altro. Il monitoraggio in tempo reale delle metriche consente di rispondere prontamente ai cambiamenti delle prestazioni, prevenire guasti ed esaurimento delle risorse e garantire elevata disponibilità e affidabilità dell'applicazione per gli utenti.  L'integrazione con sistemi di visualizzazione e archiviazione delle metriche come Prometheus e Grafana semplifica la visualizzazione di questi dati, semplificando notevolmente il monitoraggio.   Collezionisti di dati metrici  I collettori di metriche OpenTelemetry sono compatibili con gli standard Prometheus e OpenMetrics, consentendo una facile transizione alle soluzioni OpenTelemetry senza modifiche significative. L'SDK OpenTelemetry consente di esportare esempi trace_id insieme alle metriche, rendendo possibile la correlazione delle metriche con esempi di log e tracce.  Correlazione del segnale   Insieme, registri, metriche e tracciamento creano una visione completa dello stato del sistema:  I registri forniscono informazioni sugli eventi di sistema, consentendo una rapida identificazione e risoluzione degli errori.  Le metriche riflettono gli indicatori di prestazione qualitativi e quantitativi del sistema, come i tempi di risposta o i tassi di errore.  Il tracciamento integra questa visualizzazione mostrando il percorso di esecuzione della richiesta attraverso vari componenti di sistema, aiutando a comprendere le loro interrelazioni. La chiara correlazione tra log, tracce e metriche è una caratteristica distintiva di OpenTelemetry. Ad esempio, Grafana consente agli utenti di vedere le metriche di traccia e richiesta corrispondenti quando visualizzano un log, migliorando notevolmente l'usabilità e l'efficienza della piattaforma.   Oltre ai tre componenti principali, OpenTelemetry include i concetti di campionamento, bagaglio e gestione del contesto operativo.   Campionamento  Nei sistemi ad alto carico, il volume di log e tracce diventa enorme, richiedendo risorse sostanziali per l'infrastruttura e l'archiviazione dei dati. Per risolvere questo problema, gli standard OpenTelemetry includono il campionamento del segnale, ovvero la possibilità di esportare solo una parte di tracce e log. Ad esempio, è possibile esportare segnali dettagliati da una percentuale di richieste, richieste di lunga durata o richieste di errore. Questo approccio consente un campionamento sufficiente per creare statistiche risparmiando risorse significative.  Tuttavia, se ogni sistema decide in modo indipendente quali richieste monitorare in dettaglio, si finisce per avere una visione frammentata di ogni richiesta. Alcuni sistemi possono esportare dati dettagliati, mentre altri possono esportare solo parzialmente o non esportare affatto.  Per risolvere questo problema, i meccanismi di propagazione del contesto di OpenTelemetry trasmettono un flag di campionamento insieme a `trace_id`/`span_id`. Ciò garantisce che se il servizio iniziale che riceve la richiesta dell'utente decide che la richiesta deve essere monitorata in dettaglio, tutti gli altri sistemi seguiranno l'esempio. Altrimenti, tutti i sistemi dovrebbero esportare parzialmente o non esportare segnali per conservare risorse. Questo approccio è chiamato "Head Sampling", una decisione presa all'inizio dell'elaborazione della richiesta, in modo casuale o in base ad alcuni attributi di input.  Inoltre, OpenTelemetry supporta il "Tail Sampling", in cui tutte le applicazioni esportano sempre tutti i segnali in dettaglio, ma esiste un buffer intermedio. Dopo aver raccolto tutti i dati, questo buffer decide se conservare i dati completi o solo un campione parziale. Questo metodo consente un campione più rappresentativo di ogni categoria di richiesta (riuscito/lungo/errore), ma richiede un'ulteriore configurazione dell'infrastruttura.   Bagaglio  Il meccanismo Baggage consente di trasmettere coppie chiave-valore arbitrarie insieme a   /   , passando automaticamente tra tutti i microservizi durante l'elaborazione della richiesta. Ciò è utile per trasmettere informazioni aggiuntive necessarie durante il percorso della richiesta, come informazioni utente o impostazioni dell'ambiente di runtime. trace_id span_id     Esempio di intestazione per la trasmissione dei bagagli secondo lo standard W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5   Ecco alcuni esempi di utilizzo dei bagagli:    come   ,   o   può essere passato attraverso tutti i microservizi. Le applicazioni possono registrare automaticamente queste informazioni, consentendo ricerche di log in base al contesto utente per la richiesta originale. Passaggio di informazioni di contesto aziendale userId productId deviceId  Impostazioni   per SDK o infrastruttura. specifiche dei parametri di configurazione  Flag   Flag che aiutano i bilanciatori di carico a prendere decisioni di routing. Durante i test, alcune richieste potrebbero dover essere instradate a finti backend. Poiché il bagaglio viene trasmesso automaticamente tramite tutti i servizi, non c'è bisogno di creare protocolli aggiuntivi: basta impostare una regola sul bilanciatore di carico. di routing  Nota che, sebbene l'impatto sulle prestazioni di Baggage sia minimo, un uso eccessivo può aumentare significativamente il carico di rete e di servizio. Scegli attentamente quali dati devi realmente far passare attraverso Baggage per evitare problemi di prestazioni.   Implementazione dell'infrastruttura  L'implementazione di OpenTelemetry a livello di infrastruttura comporta l'integrazione dei backend di OpenTelemetry nell'architettura dell'applicazione e la configurazione dell'infrastruttura per l'aggregazione dei dati.   Il processo si compone di quattro fasi:    Nella prima fase, gli SDK di OpenTelemetry vengono integrati direttamente nelle applicazioni per raccogliere metriche, registri e tracce, garantendo un flusso continuo di dati sulle prestazioni di ciascun componente del sistema. Integrazione delle applicazioni    I dati raccolti vengono instradati dalle applicazioni tramite gli esportatori verso sistemi esterni per un'ulteriore elaborazione, ad esempio tramite sistemi di registrazione, monitoraggio, tracciamento o analisi, a seconda delle esigenze. Configurazione degli esportatori    Questa fase può comportare la normalizzazione dei dati, l'arricchimento con informazioni aggiuntive e l'unione di dati provenienti da diverse fonti per creare una vista unificata dello stato del sistema. Aggregazione e archiviazione    Infine, i dati elaborati vengono presentati come dashboard in sistemi come Grafana (per metriche e tracce) o Kibana (per i log). Ciò consente ai team di valutare rapidamente lo stato di salute del sistema, identificare problemi e tendenze e impostare avvisi in base ai segnali generati. Visualizzazione dei dati  Implementazione dell'applicazione  Per integrare un'applicazione, è necessario collegare l'OpenTelemetry SDK appropriato per il linguaggio di programmazione in uso o impiegare librerie e framework che supportano direttamente OpenTelemetry. OpenTelemetry implementa spesso interfacce ampiamente utilizzate da librerie note, consentendo sostituzioni drop-in. Ad esempio, la libreria Micrometer è comunemente utilizzata per la raccolta di metriche nell'ecosistema Java. L'OpenTelemetry SDK fornisce le sue implementazioni di interfacce Micrometer, consentendo l'esportazione di metriche senza modificare il codice dell'applicazione principale. Inoltre, OpenTelemetry offre implementazioni di vecchie interfacce OpenTracing e OpenCensus, facilitando una migrazione fluida a OpenTelemetry.  Conclusione  Nei sistemi IT, OpenTelemetry può diventare la chiave per il futuro di backend affidabili ed efficienti. Questo strumento semplifica il debug e il monitoraggio e apre anche opportunità per una profonda comprensione delle prestazioni e dell'ottimizzazione delle applicazioni a un nuovo livello. Unisciti alla community di OpenTelemetry per contribuire a dare forma a un futuro in cui lo sviluppo del backend è più semplice ed efficace!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Even

Google

Microsoft

Real

reflect

Trace

Read My Stories

Questo audio è prodotto nella lingua originale della storia!

Che cos'è OpenTelemetry e come può migliorare la qualità del tuo backend?

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

Indian PM Woos Tech CEOs During U.S. State Visit

I Tried Perplexity For a Week, And I Don't Think AI Search Engines Can Replace Google.. Yet

HackerNoon - A User Experience Analysis: Part 2

The Ultimate FAQ Guide to HackerNoon's Business Blogging

Indian PM Woos Tech CEOs During U.S. State Visit

I Tried Perplexity For a Week, And I Don't Think AI Search Engines Can Replace Google.. Yet

HackerNoon - A User Experience Analysis: Part 2

The Ultimate FAQ Guide to HackerNoon's Business Blogging

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps