Sempre più spesso le aziende stanno adottando microservizi per l'architettura del proprio software, estendendo e rimpiazzando i vecchi monoliti.
Ci sono indubbi benefici in questa architettura, facilità di sviluppo, deployment, scaling, ma l'avere un gran numero di microservizi che parlano tra loro può portare problemi nell'individuare la causa di un malfunzionamento o di una latenza.
Per risolvere questa situazione si è sentita quindi la necessità di reperire e combinare i dati di monitoraggio delle varie applicazioni, così da avere la visibilità dell'intero sistema.
Questa è conosciuta come Observability
La Observability si compone di metrics, logs e distributed tracing
Le metrics misurano un valore temporale, ad esempio la quantità di CPU usata da un'applicazione nel tempo
I logs servono a salvare messaggi dell'applicazione in un determinato istante. Possono contenere un errore che l'applicazione ha ricevuto, piuttosto che un'informazione utile ai fini del debug.
Una trace rappresenta i dettagli su una transazione, come quanto tempo ci è voluto per chiamare una specifica funzione. Una trace è divisa in span, cioè in operazioni tra segmenti contigui di lavoro.
Nel distributed tracing ogni servizio contribuisce al suo span o set di span.
Esistono strumenti diversi per ognuno dei 3 aspetti dell'Observability, con protocolli diversi e librerie proprietarie.
Per uniformare questi tre aspetti si è dunque deciso di farli afferire sotto un protocollo comune, detto OpenTelemetry. La Cloud Native Computing Foundation ha creato il progetto OTEL, un insieme di API, SDK e Tools per la gestione delle metriche.
A valle del collettore ci sono strumenti open source come Jaeger, Prometheus, Loki e Grafana, piuttosto che soluzioni proprietarie che permettono il salvataggio dei dati, la visualizzazione e anche un sistema di alerting
Nessun commento:
Posta un commento