In generale, l'observability è la misura in cui puoi capire lo stato o la condizione interni di un sistema complesso basati solo sulla conoscenza degli output esterni. Più un sistema è osservabile, più rapidamente e accuratamente puoi navigare da un problema di prestazioni identificato alla sua causa ultima, senza ulteriori test o codifica.

Nell'IT e nel cloud computing, l'observability si riferisce anche a strumenti software e prassi per aggregare, correlare e analizzare un flusso costante di dati sulle prestazioni da un'applicazione distribuita insieme all'hardware e alla rete su cui viene eseguita, al fine di monitorare, risolvere i problemi ed eseguire il debug dell'applicazione in modo più efficace, per soddisfare le aspettative dei clienti, gli accordi sui livelli di servizio (SLA) e altri requisiti di business.

L'observability, un argomento IT relativamente nuovo, è spesso descritta in modo errato come una parola in voga esageratamente pubblicizzata, o un "rebranding" del sistema di monitoraggio,  monitoraggio delle prestazioni di un'applicazione (application performance monitoring, APM), e  gestione delle prestazioni di rete (network performance management, NPM). In effetti, l'observability è un'evoluzione naturale dei metodi di raccolta dei dati APM ed NPM che risponde meglio alla natura sempre più rapida, distribuita e dinamica delle implementazioni di applicazioni native del cloud. L'observability non sostituisce il monitoraggio: consente un migliore monitoraggio e APM ed NPM migliori.

Il termine "observability" proviene dalla teoria del controllo, un'area dell'ingegneria che si occupa dell'automatizzazione del controllo di un sistema dinamico - ad esempio, il flusso di acqua in un tubo o la velocità di un'automobile su salite e discese - in base al feedback del sistema.

Negli ultimi 20 anni circa, i team IT si sono affidati principalmente ad APM per monitorare e risolvere i problemi delle applicazioni. APM campiona e aggrega periodicamente i dati di applicazioni e sistemi, chiamati telemetria, di cui è nota la correlazione a problemi di prestazioni delle applicazioni. Analizza la telemetria relativa agli indicatori di prestazioni chiave (key performance indicator, KPI) e assembla i risultati in un dashboard per avvisare i team di supporto e delle operazioni su condizioni anomale di cui è necessario occuparsi per risolvere o prevenire i problemi.

APM è abbastanza efficace per il monitoraggio e la risoluzione dei problemi delle applicazioni monolitiche o delle applicazioni distribuite tradizionali, dove il nuovo codice viene rilasciato periodicamente e i flussi di lavoro e le dipendenze tra i componenti dell'applicazione, i server e le risorse correlate sono ben noti o facili da tracciare.

Ma oggi le organizzazioni stanno rapidamente adottando prassi di sviluppo moderne - sviluppo agile, integrazione continua e implementazione continua (continuous integration/continuous deployment, CI/CD), DevOps, più linguaggi di programmazione - e tecnologie native del cloud come microservizi, container Docker, Kubernetes e funzioni serverless. Come risultato, stanno portando più servizi sul mercato più velocemente che mai. Ma, nel farlo, stanno implementando nuovi componenti applicativi così spesso, in così tanti posti, in così tanti linguaggi diversi e per periodi di tempo così ampiamente variabili (per secondi o frazioni di secondo, nel caso delle funzioni serverless) che il campionamento dei dati di APM una volta al minuto non può tenere il passo.

Ciò di cui c'è bisogno è una telemetria di qualità superiore, che possa essere usata per creare un record molto fedele, ricco di contesto e completamente correlato di ogni richiesta o transazione dell'utente dell'applicazione. È qui che entra in scena l'observability.

Le piattaforme di observability individuano e raccolgono continuamente la telemetria delle prestazioni integrandosi con la strumentazione esistente integrata nei componenti delle applicazioni e dell'infrastruttura e fornendo strumenti per aggiungere la strumentazione a questi componenti. L'observability si concentra su quattro tipi principali di telemetria:

• Log. I log sono registrazioni granulari, temporizzate, complete e immutabili degli eventi delle applicazioni. Tra le altre cose, i log possono essere utilizzati per creare una registrazione molto fedele, millisecondo per millisecondo, di ogni evento, completa del contesto circostante, che gli sviluppatori possono "riprodurre" per la risoluzione dei problemi e il debug.
• Metriche. Le metriche (a volte chiamate metriche di serie temporali) sono misure fondamentali dello stato di integrità dell'applicazione e del sistema in un dato periodo di tempo, come ad esempio la quantità di memoria o capacità di CPU utilizzata da un'applicazione in un arco di cinque minuti, o la quantità di latenza sperimentata da un'applicazione durante un picco di utilizzo.
• Tracce. Le tracce registrano il "percorso" end-to-end di ogni richiesta dell'utente, dall'IU o dall'applicazione per dispositivi mobili attraverso l'intera architettura distribuita e di nuovo all'utente.
• Dipendenze. Le dipendenze (chiamate anche mappe di dipendenza) rivelano in che modo ogni componente dell'applicazione dipende da altri componenti, applicazioni e risorse IT.

Dopo aver raccolto questa telemetria, la piattaforma la mette in correlazione in tempo reale per fornire ai team DevOps, ai team di SRE (site reliability engineering) e al personale IT informazioni complete e contestuali: il cosa, il dove e il perché di qualsiasi evento che potrebbe indicare, causare o essere utilizzato per risolvere un problema di prestazioni dell'applicazione. 

Molte piattaforme di observability individuano automaticamente nuove fonti di telemetria che potrebbero emergere all'interno del sistema (come una nuova chiamata API a un'altra applicazione software). E poiché trattano molti più dati di una soluzione APM standard, diverse piattaforme includono funzionalità AIOps (AI per le operazioni) che separano i segnali - indicazioni di problemi reali - dal rumore (dati non correlati ai problemi).

Il vantaggio principale dell'observability è che, a parità di altre condizioni, un sistema più osservabile è più facile da capire (in generale e in grande dettaglio), più facile da monitorare, più facile e più sicuro da aggiornare con nuovo codice e più facile da riparare rispetto a un sistema meno osservabile. Più specificamente, l'observability supporta direttamente gli obiettivi Agile/DevOps/SRE di distribuzione di software di qualità superiore più velocemente, permettendo a un'organizzazione di:

• Individuare e affrontare le "incognite sconosciute", vale a dire, problemi di cui non si conosce l'esistenza. Una delle principali limitazioni degli strumenti di monitoraggio è che controllano solo le "incognite conosciute", condizioni eccezionali che sai già di dover controllare. L'observability rileva condizioni che potresti non conoscere o pensare di cercare mai, poi traccia la loro relazione con specifici problemi di prestazioni e fornisce il contesto per identificare le cause ultime e accelerare la risoluzione.
• Individuare e risolvere i problemi nella fase iniziale dello sviluppo. L'observability porta il monitoraggio nelle prime fasi del processo di sviluppo software. I team DevOps possono identificare e risolvere i problemi nel nuovo codice prima che abbiano un impatto sull'esperienza cliente o sugli SLA.
• Scalare l'observability automaticamente. Ad esempio, puoi specificare la strumentazione e l'aggregazione dei dati come parte della configurazione di un cluster Kubernetes e iniziare a raccogliere la telemetria dal momento in cui si attiva e fino a quando si interrompe.
• Abilitare una correzione automatizzata e un'infrastruttura delle applicazioni che si ripara automaticamente. Combina l'observability con le funzionalità di ML (machine learning) e automazione AIOps per prevedere i problemi sulla base degli output di sistema e risolverli senza l'intervento della gestione.