Observability è l’ultima parola d’ordine quando si parla di monitoraggio IT. Ma cosa serve per ottenerla? E come si fa a sapere se ti stanno vendendo una buzzword invece di funzionalità davvero importanti?
Attingendo alla letteratura disponibile, in questo articolo diamo un’occhiata a cosa significa “osservabilità” nella pratica e se i tre pilastri su cui si regge (logs, metrics, tracing) hanno senso.
Che cos’è l’osservabilità?
In termini strettamente tecnici, observability è la capacità di determinare cosa sta accadendo all’interno di un sistema in base ai dati che il sistema evidenzia all’esterno. In altre parole, se un sistema software è osservabile, si possono utilizzare misure esterne, come log file e metriche, per capire cosa sta succedendo al suo interno.
Come concetto generale, nel campo dell’ingegneria, l’osservabilità risale a decenni fa. Tuttavia, è soprattutto negli ultimi anni che i software vendor di strumenti di monitoraggio e troubleshooting degli ambienti applicativi hanno rispolverato il termine.
Osservabilità vs monitoraggio vs visibilità
Molti fornitori di strumenti software affermano che il monitoraggio si concentra sull’avviso che qualcosa non va nel sistema, mentre l’osservabilità segnala ciò che sta accadendo nel sistema. Pertanto, l’osservabilità fornisce un livello di conoscenza più profondo rispetto al monitoraggio.
I vendor spesso accostano anche l’observability alla visibility, affermando che la visibilità si concentra su singole fonti di dati, mentre l’osservabilità mette in correlazione più tipi di dati per ottenere informazioni approfondite.
Detto questo, è discutibile fino a che punto l’osservabilità differisca veramente dal monitoraggio e dalla visibilità. Sebbene gli strumenti e le tecniche si siano evoluti negli ultimi anni per soddisfare gli ambienti cloud-native basati su microservizi, l’osservabilità non è fondamentalmente diversa da altri processi associati al monitoraggio. È solo un po’ più sofisticata.
Nella pratica, il monitoraggio è molto più della semplicistica idea di un campanello che ti avvisa solo quando qualcosa non va. Lo scopo del monitoraggio è identificare la causa degli errori di sistema e quindi fornire soluzioni. Implica anche la previsione anticipata di questi problemi in modo che possano essere risolti in modo proattivo. Queste attività non sono iniziate quando sul mercato è arrivata l’osservabilità: gli uomini dell’IT le fanno già da molto tempo, ma le chiamano monitoraggio.
Inoltre, le parole chiave associate all’osservabilità – i tre pilastri di cui parliamo in seguito – fanno parte da tempo delle routine di monitoraggio. L’osservabilità non ha il monopolio di log, metrics e tracing.
Per dirla tutta, il dibattito tra observability, monitoring e visibility è una questione di semantica e marketing. Per semplificare le cose, con buona dei marketer, si può pensare all’osservabilità come a una forma evoluta di monitoraggio, non a un fondamentale balzo in avanti. Gli strumenti, i processi e le data source associati al monitoraggio e all’osservabilità sono abbastanza simili.
I tre pilastri dell’osservabilità
La discussione sull’osservabilità è spesso basata sull’idea che essa si basi su tre pilastri principali, o data source, che forniscono informazioni sui sistemi:
- Informazioni sull’infrastruttura e sull’attività delle applicazioni che catturano un singolo punto nel tempo
- Dettagli dalle prestazioni delle applicazioni e dei cloud service
- Distributed traces. Tracciare le richieste all’interno di un sistema distribuito
Questi pillar sono le data source essenziali su cui si basano i moderni strumenti di monitoraggio o osservabilità. E qui attenzione: non è un caso che i termini monitoring e observability vengano usati in modo intercambiabile dagli analisti da cui abbiamo preso le considerazioni di cui parliamo. Questo succede perché, come spiegato sopra, essi non sono d’accordo che ci sia sempre una distinzione fondamentale tra i due concetti. Dunque, concentrarsi solo su questi tre pilastri è un po’ limitante, per diversi motivi.
Non tutti i sistemi dispongono di log, metriche e tracce
Alcuni cloud service potrebbero esporre solo metriche e non fornire log data con cui lavorare, ed è un esempio abbastanza comune. Sistemi di questo tipo sono osservabili, ma la loro osservabilità non si basa su ciascuno dei tre pilastri.
Ci sono anche le applicazioni monolitiche
Il distribuited tracing funziona solo per le applicazioni di microservizi, non per le applicazioni monolitiche. Posto questo, non ha senso pensare al tracing come a un pillar immancabile dell’osservabilità. A meno che non si pensi che le applicazioni monolitiche non siano osservabili.
Monitoraggio sintetico
Le tecniche di monitoraggio sintetico, che aiutano a valutare e prevedere le prestazioni del sistema prima che il software venga distribuito in produzione, in genere si concentrano sulla raccolta di dati dai test, piuttosto che su log, metriche e tracce convenzionali.
Si potrebbe sostenere che l’osservabilità è distinta dal monitoraggio sintetico, nel qual caso sarebbe corretto trattare i log, le metriche e le tracce come le principali fonti di dati per l’osservabilità. Ma si potrebbe anche sostenere che il monitoraggio sintetico è un modo per ottenere l’osservabilità prima di mettere in produzione il sistema. In quest’ultimo caso, è sbagliato definire solo log, metriche e tracce come fonti di osservabilità.
Altre fonti di dati
L’IT a volte deve contestualizzare i log, le metriche e le tracce con i dati di altri sistemi, come i sistemi di ticketing o le prestazioni della pipeline CI/CD, per ottenere il quadro più completo dello stato di salute della software delivery complessiva. Concentrarsi soltanto su quelli che sono considerati i tre pilastri dell’osservabilità rischia di trascurare altre importanti fonti di visibilità nei propri sistemi.
L’IT observability è negli occhi di chi guarda
Come la bellezza, l’observability è negli occhi di chi guarda. Meglio allora non impantanarsi in dibattiti semantici su cosa sia e cosa non sia l’osservabilità o se log, metriche e tracce da soli siano i pilastri essenziali dell’osservabilità. È più salutare considerare l’osservabilità come il modo per raggiungere gli stessi obiettivi finali di quel processo che viene chiamato monitoraggio.
L’osservabilità utilizza una moltitudine di data source. I log, le metriche e le tracce potrebbero essere i più comuni, ma è sbagliato limitarsi in questo perimetro. Meglio, concordano gli analisti, utilizza i pillar dell’osservabilità più sensati in base all’architettura dell’applicazione, all’ambiente di hosting e alle priorità dell’utente finale.
