Cloud
Questa è la prima parte di un blog in due parti, nel prossimo post descriveremo come stiamo realizzando l'osservabilità e il monitoraggio dei servizi Managed Service per i nostri clienti nell'ambito della nostra offerta di servizi Managed.
I nostri clienti dipendono sempre di più dalle architetture distribuite per consumare i servizi applicativi. La diversificazione degli impianti infrastrutturali e delle applicazioni in termini di luoghi di hosting e di modalità di comunicazione è in costante aumento. Questa tendenza si è accentuata negli ultimi anni, grazie ai grandi passi avanti compiuti nella facilità di adozione dei cloud. Da un lato, i clienti scelgono la posizione e la categoria delle loro risorse in base ai prezzi, alle caratteristiche e ai requisiti di conformità all'interno dello stesso fornitore di public cloud; dall'altro, si orientano verso architetture multi-cloud o hybrid cloud per dare impulso alla trasformazione digitale, migliorare l'agilità, passare da CapEx a OpEx, ecc.
Queste tendenze hanno portato a progressi sia nell'osservabilità che nel Monitoring. Ma esattamente, cos'è il monitoring e cos'è l'osservabilità? Sì, sono molto diversi e mi infastidisce quando sento o leggo che il monitoraggio è stato sostituito dall'osservabilità; non è così, anzi l'osservabilità migliora e amplifica il monitoraggio. Mi spiego meglio.
Una delle migliori spiegazioni sullo schermo e l'osservabilità che ho letto è stata fornita da Morgan Willis, Senior Cloud Technologist di AWS.
"Il monitoring è l'atto di riscossione di crediti. Quali tipi di dati raccogliamo, cosa facciamo con i dati e se questi dati sono prontamente analizzati o disponibili è un'altra storia. È qui che entra in gioco l'osservabilità. L'osservabilità non è un verbo, non è qualcosa che si fa. L'osservabilità è piuttosto un terreno di un sistema"
Secondo questa spiegazione, strumenti come CloudWatch, Azure Monitor, X-Ray e App Insights possono essere classificati come strumenti di monitoraggio o tracciamento. Ci permettono di riscossione di crediti e metriche sul nostro sistema e di inviare avvisi su errori e incidenti. Pertanto, il monitoraggio è una parte attiva della riscossione di dati che ci aiutano a valutare la salute del nostro sistema e il funzionamento dei suoi diversi componenti. Una volta stabilito un sistema di sorveglianza che raccoglie continuamente log, output di sistema, metriche e tracce, il nostro sistema diventa osservabile.
La mia comprensione del significato di monitoraggio è stata in continua trasformazione nel corso della mia carriera; attualmente mi piace pensare al monitoraggio come alla parte di ingestione dei dati dell'ETL (extract, transform, load). In altre parole, si raccolgono dati da più fonti (log, tracce, metriche) e li si inserisce in un archivio dati. Una volta che tutti questi dati sono disponibili, un analista esperto può trarne spunti di riflessione e costruire bellissime dashboard che raccontano la storia che questi dati trasmettono. Le piattaforme di osservabilità come Elasticsearch Kibana svolgono il ruolo di un analista esperto. Ti forniscono visualizzazioni e approfondimenti sullo stato di salute del tuo sistema.
L'osservabilità, nata dalla teoria del controllo, risulta di misurazione della capacità di comprendere gli stati interni di un sistema a partire dalle sue uscite esterne. L'osservabilità utilizza la strumentazione per
Questa è telemetria, non osservabilità.
forniscono informazioni che aiutano lo schermo. In altre parole, il Monitoring è ciò che si fa dopo che un sistema di sorveglianza è osservabile. Senza un certo livello di osservabilità, lo schermo è impossibile.
Si tratta di telemetria, non di osservabilità.
Molto spesso noto la tendenza a confondere l'osservabilità con la telemetria. O, almeno, con le interfacce utente poco integrate costruite su silos di telemetria, come mostrato nel diagramma precedente. In questa formulazione, l'osservabilità viene in qualche modo spiegata come la semplice coesistenza di uno strumento di metrica, uno strumento di registrazione e uno strumento di tracciamento.
In breve: non confondere la coesistenza di metriche, tracing/APM e logging con l'"Osservabilità".
Come la maggior parte delle idee sbagliate che prendono piede, c'è un fondo di verità: in particolare, le tracce, le metriche e i log hanno tutti un posto nella soluzione. Ma non sono il prodotto; sono solo i dati grezzi. La telemetria.
L'anatomia dell'osservabilità.
Il primo livello è la telemetria; non possiamo avere l'osservabilità senza i dati telemetrici grezzi. A seconda dell'impianto infrastrutturale e dei mezzi di esercizio disponibili, esistono molti strumenti per la raccolta della telemetria grezza. L'obiettivo principale del primo livello dovrebbe essere sempre quello di accedere a una telemetria di alta qualità.
Il secondo livello è lo storage: non solo come lo conserviamo, ma anche per quanto tempo. Quando si considerano gli archivi di dati per l'osservabilità, trovare il giusto equilibrio può essere un problema. Fondamentalmente, se vogliamo impugnare in modo efficiente i dati ad alta velocità di trasmissione (ad esempio, la fatturazione del 100% di tutti i messaggi passati in un'applicazione scalata, o anche i risultati di misurazione ad alta fedeltà come il carico della CPU o l'uso della memoria per contenitore), dobbiamo registrare le statistiche in un database a serie temporali. Altrimenti, sprechiamo troppo nel trasferire e nello storage dei singoli avvenimenti. E mentre alcuni potrebbero suggerire di campionare gli avvenimenti, per i dati a bassa frequenza nascosti nel flusso ad alta frequenza, è possibile perderli del tutto. Questa situazione chiama un DB dedicato alle serie temporali (TSDB): un archivio di dati progettato appositamente per lo storage, l'indicizzazione e l'interrogazione di statistiche sulle serie temporali come queste.
E ancora! Se vogliamo impugnare dati ad alta cardinalità (ad esempio tag per cliente, id univoci per impianti infrastrutturali effimeri o frammenti di URL), un TSDB è un vero disastro. L'esplosione della cardinalità dei tag comporta un'esplosione delle serie temporali uniche e, di conseguenza, un'esplosione dei costi. Per questo motivo, deve essere presente anche un Transaction DB; tradizionalmente si trattava di un database di log, anche se è più saggio costruire un Transaction DB distribuito e tracciante (di cui parleremo più avanti) che può prendere due piccioni (log e tracce) con una fava.
Tuttavia, trovare database di transazioni e serie temporali all'avanguardia è necessario ma non sufficiente. Per rendere il pezzo di "Osservabilità" senza interruzioni, anche il livello dei dati deve essere integrato e incrociato, preferibilmente con un'integrazione profonda.
Le sfide di cui sopra possono rendere difficile l'osservabilità e a volte possono sembrare inafferrabili. Questo ci porta al terzo livello, le prestazioni effettive; nel regno della Corporate Governance, queste vengono chiamate semplicemente risultati di business e sono una parte essenziale della value proposition canvas quando vendiamo osservabilità e monitoraggio ai nostri clienti commerciali.
In fin dei conti, la telemetria, sia in movimento che a riposo, non ha un valore intrinseco. Sono solo i flussi di lavoro e le applicazioni costruite sopra che possono avere valore. Eppure, nella presentazione convenzionale di "Osservabilità come metriche, log e tracce", non sappiamo nemmeno quale problema stiamo risolvendo! Tanto meno come lo stiamo risolvendo.
Quando si tratta di applicazioni software moderne e distribuite, ci sono due problemi generali che vale la pena risolvere con l'Osservabilità:
Per concludere, Monitoring e Osservabilità vanno di pari passo: uno non sostituisce l'altro, ma insieme permettono di migliorare i risultati aziendali definiti.
Per maggiori informazioni visita il sito Public Cloud Services di Swisscom. Puoi anche contattarci contattando i nostri esperti che ti aiuteranno a far decollare le tue soluzioni basate su cloud.
Questa è la prima parte di un blog diviso in due parti; nel prossimo post descriveremo come stiamo facendo l'osservabilità e il monitoraggio presso i Public Cloud Service Manager per i nostri clienti nell'ambito della nostra offerta di servizi Managed.
DevOps Engineer
Trova il lavoro o il mondo della carriera che fa per te. In cui vuoi contribuire a plasmare e sviluppare te stesso.
Ciò che ne fai è ciò che ci definisce.
