L’importanza dell’osservabilità è ormai ben consolidata, con le organizzazioni che si affidano a metriche, log e registri per rilevare, diagnosticare e isolare i problemi nei loro ambienti. Ma, come la maggior parte degli aspetti dell’IT, l’osservabilità continua a evolversi rapidamente, sia in termini di come le persone la definiscono, sia di come la si può migliorare nella pratica.

L’osservabilità è, in sostanza, una questione che riguarda l’analisi dei dati. La definizione formale di osservabilità tende a centrarsi sugli output esterni dei sistemi informatici. Personalmente uso una definizione leggermente più ampia di osservabilità: “la capacità di consentire a un essere umano di porre e rispondere a domande sul sistema”. Mi piace questa definizione perché suggerisce che l’osservabilità dovrebbe essere incorporata come parte della progettazione del sistema (piuttosto che essere appiccicata su di esso come una sorta di ripensamento) e perché sottolinea la necessità per ingegneri e amministratori di sistema di portare una mentalità analitica alla sfida di consentire l’osservabilità.

Quest’anno molte organizzazioni approfondiranno e diversificheranno l’utilizzo dei dati di telemetria, consolidando al contempo i loro strumenti nel tentativo di aumentare la loro osservabilità. Tecnologie come eBPF e OpenTelemetry abbasseranno la barriera di accesso alla strumentazione e le pratiche di analisi dei dati e consentiranno ai team IT e DevOps di identificare e rispondere ai problemi in modo più rapido ed efficace.

Adozione più ampia della tracciamento distribuito

Molti leader IT e aziendali non si rendono ancora conto di quanto potenziale abbia il tracciamento distribuito e ciò rappresenta un’enorme opportunità persa nella ricerca per ottimizzare l’osservabilità. Tuttavia, è probabile che il 2022 le cose cambieranno. Man mano che sempre più organizzazioni migrano i propri carichi di lavoro verso architetture cloud native e di microservizi, il tracciamento distribuito diventerà sempre più prevalente come mezzo per individuare dove si verificano gli errori e quali sono le cause delle scarse prestazioni. Il recente sondaggio DevOps Pulse mostra un aumento del 38% anno su anno nell’uso del tracciamento da parte delle organizzazioni e il 64% degli intervistati che non stanno ancora utilizzando il tracciamento ha dichiarato di aver pianificato di implementarlo entro i prossimi due anni.

Il tracciamento distribuito può aprire un mondo completamente nuovo di osservabilità in numerosi processi oltre al monitoraggio IT, in aree diverse come l’esperienza degli sviluppatori, il business e le FinOps. Il tracciamento distribuito si basa sulla strumentazione dell’applicazione con i meccanismi di propagazione del contesto durante l’esecuzione delle richieste. È possibile utilizzare facilmente il meccanismo di propagazione del contesto per molti altri processi, come il monitoraggio dell’attribuzione delle risorse o le informazioni sulla pianificazione della capacità per linea di prodotti o per account cliente.

La conformità alla privacy dei dati è un’altra applicazione estremamente utile del tracciamento distribuito. Alla luce delle normative di conformità emergenti come GDPR e CCPA, la privacy dei dati è un’enorme priorità e questa sfida è esacerbata dal fatto che l’archiviazione di basso livello spesso non è a conoscenza del contesto dell’utente. Propagando gli ID utente dai livelli downstream ai livelli di storage dati, il tracciamento distribuito può aiutare le organizzazioni a far rispettare meglio le proprie policy sulla privacy dei dati.

Andare oltre i “tre pilastri” dell’osservabilità

Le discussioni sull’osservabilità spesso iniziano e finiscono con quelli che sono stati definiti i “tre pilastri dell’osservabilità”, ovvero metriche, log e tracce. Le metriche aiutano a rilevare i problemi e consentono a DevOps o agli ingegneri dell’affidabilità del sito di capire cosa è successo. I registri aiutano quindi a diagnosticare i problemi, fornendo il “perché” dietro il “cosa”. Infine, le tracce aiutano gli ingegneri a individuare e isolare i problemi indicando dove si sono verificati.

Questi elementi continuano ad essere di fondamentale importanza, ma è importante non essere confinati dal paradigma dei “tre pilastri” e scegliere i dati di telemetria giusti per le proprie esigenze. Quest’anno vedremo più organizzazioni optare per ulteriori tipi di segnali di osservabilità, inclusi eventi e profilazione continua.

È anche importante ricordare che i “tre pilastri” o qualsiasi altro segnale di telemetria sono solo dati grezzi. Come ho scritto sopra, credo fermamente che l’osservabilità sia un problema di analisi dei dati e, in quanto tale, si tratta di estrarre in modo proattivo informazioni da quei dati grezzi, in modo simile a quanto fanno gli analisti di BI. Secondo Frederic Branczyk, il fondatore di Polar Signals e appassionato sostenitore dell’osservabilità, “facciamo finta nella nostra bolla di osservabilità che tutti abbiano applicazioni con tracciamento distribuito e logging strutturato. Ma la realtà è che, quando guardo a una tipica startup, potrebbe non esserci alcun tipo di monitoraggio perché magari ci si aspetta che siano i clienti a dire che qualcosa non va prima che sia la stessa startup a indagare”.

big-data

L’ascesa dell’eBPF

Extended Berkeley Packet Filter, o eBPF, è una tecnologia che consente ai programmi di essere eseguiti nello spazio del kernel del sistema operativo senza dover modificare il codice sorgente del kernel o aggiungere moduli aggiuntivi. Attualmente, la pratica dell’osservabilità si basa in gran parte sulla strumentazione manuale, che richiede l’aggiunta di codice in punti rilevanti per generare dati di telemetria; ciò spesso rappresenta una barriera significativa e può persino impedire ad alcune organizzazioni di implementare l’osservabilità.

Sebbene esistano agenti di autostrumentazione, questi tendono ad essere adattati a linguaggi e framework di programmazione specifici. Tuttavia, eBPF consente alle organizzazioni di adottare la strumentazione senza codice nell’intero stack software, fornendo un’osservabilità più semplice nei loro ambienti Kubernetes e offrendo vantaggi in termini di networking e sicurezza.

Poiché eBPF funziona su diversi tipi di traffico, aiuta le organizzazioni a raggiungere il loro obiettivo di osservabilità unificata. Ad esempio, gli ingegneri DevOps potrebbero utilizzare eBPF per raccogliere query di database, richieste HTTP o flussi gRPC. Possono anche utilizzare eBPF per raccogliere le metriche di utilizzo delle risorse, incluso l’utilizzo della CPU o i byte inviati, consentendo all’organizzazione di calcolare le statistiche pertinenti e profilare i propri dati per comprendere il consumo di risorse di varie funzioni. Inoltre, eBPF può gestire il traffico crittografato.

Netflix ha recentemente pubblicato un blog su come l’azienda utilizza eBPF per acquisire informazioni dettagliate sulla rete. Secondo l’azienda, l’uso di eBPF è risultato molto efficiente, consumando meno dell’uno per cento di CPU e memoria in ogni singola istanza.

Unificazione dei tool isolati

Man mano che l’osservabilità matura, le organizzazioni guarderanno sempre più a piattaforme di osservabilità olistiche, favorendo queste soluzioni integrate rispetto agli strumenti più isolati che hanno utilizzato in passato. Rispetto agli strumenti di osservabilità autonomi, queste piattaforme più olistiche possono aiutare sviluppatori, DevOps e SRE ad affrontare query, visualizzazione e correlazione tra tutti i loro diversi tipi e sorgenti di segnali di telemetria.

Nell’ultimo anno abbiamo assistito a questa tendenza all’unificazione, con fornitori come Grafana Labs, Datadog, AppDynamics che sono usciti dai rispettivi domini specializzati in analisi dei log, monitoraggio dell’infrastruttura, APM o altri e si sono espansi verso un’offerta di osservabilità più completa. Questa tendenza prenderà ulteriore slancio nel 2022 e si adatterà alle mutevoli esigenze di osservabilità cambiando il panorama competitivo.

Adozione continua di strumenti e standard open source

La comunità open source ha creato Kubernetes (e, essenzialmente, l’intero concetto di “cloud native”). La stessa comunità ora fornisce strumenti e standard open source per monitorare questi ambienti. Nuovi standard aperti come OpenMetrics e OpenTelemetry matureranno diventando standard di settore. Non a caso OpenMetrics potrebbe essere adottato già quest’anno come standard formale da IETF, la principale organizzazione di standard Internet. L’ascesa degli strumenti open source non solo offre alle aziende opzioni aggiuntive per consentire l’osservabilità, ma impedisce anche il lock-in dei fornitori che storicamente ha afflitto alcuni reparti del settore IT.

Al momento, il panorama dell’osservabilità open source è piuttosto dinamico, con una serie di importanti progetti emersi solo negli ultimi due anni. A volte può essere difficile per DevOps e amministratori di sistema mantenere queste soluzioni sulla retta via (soprattutto perché molti hanno adottato la denominazione di “OpenSomething”), ma le cose stanno migliorando e ci avviciniamo sempre di pèiù a qualcosa di simile alla standardizzazione open source e all’ideale dell’osservabilità unificata.