Modelli di osservabilità

Suggerimento

Questo contenuto è un estratto dell'eBook Architecting Cloud Native .NET Applications for Azure, disponibile in .NET Docs o come PDF scaricabile gratuito che può essere letto offline.

Scaricare il PDF

Proprio come sono stati sviluppati modelli per facilitare il layout del codice nelle applicazioni, esistono modelli per le applicazioni operative in modo affidabile. Sono stati illustrati tre modelli utili per la gestione delle applicazioni: registrazione, monitoraggio e avvisi.

Quando usare la registrazione

Indipendentemente dal modo in cui siamo attenti, le applicazioni si comportano quasi sempre in modi imprevisti nell'ambiente di produzione. Quando gli utenti segnalano problemi con un'applicazione, è utile essere in grado di vedere cosa stava accadendo con l'app quando si è verificato il problema. Uno dei modi più provati e veri per acquisire informazioni sulle operazioni eseguite da un'applicazione durante l'esecuzione consiste nell'avere l'applicazione a prendere nota delle operazioni eseguite. Questo processo è noto come registrazione. In qualsiasi momento si verificano errori o problemi nell'ambiente di produzione, l'obiettivo deve essere quello di riprodurre le condizioni in cui si sono verificati gli errori, in un ambiente non di produzione. L'uso di una buona registrazione fornisce agli sviluppatori una roadmap da seguire per duplicare i problemi in un ambiente con cui è possibile testare ed sperimentare.

Problemi durante la registrazione con applicazioni native del cloud

Nelle applicazioni tradizionali i file di log vengono in genere archiviati nel computer locale. Nei sistemi operativi simili a Unix, infatti, esiste una struttura di cartelle definita per contenere tutti i log, in genere in /var/log.

Figura 7-1. Registrazione in un file in un'app monolitica.

L'utilità della registrazione in un file flat in un singolo computer è notevolmente ridotta in un ambiente cloud. Le applicazioni che producono log potrebbero non avere accesso al disco locale oppure il disco locale potrebbe essere molto volatile perché i contenitori vengono spostati tra le macchine fisiche. Anche la semplice scalabilità verticale delle applicazioni monolitiche in più nodi può rendere difficile individuare il file di log appropriato basato su file.

Figura 7-2. Registrazione ai file in un'app monolitica ridimensionata.

Le applicazioni native del cloud sviluppate usando un'architettura di microservizi comportano anche alcune sfide per i logger basati su file. Le richieste degli utenti possono ora estendersi a più servizi eseguiti in computer diversi e possono includere funzioni serverless senza accesso a un file system locale. Sarebbe molto difficile correlare i log di un utente o di una sessione in questi numerosi servizi e computer.

Figura 7-3. Registrazione su file locali in un'app di microservizi.

Infine, il numero di utenti in alcune applicazioni native del cloud è elevato. Si supponga che ogni utente generi centinaia di righe di messaggi di log quando accedono a un'applicazione. In isolamento, questo è gestibile, ma moltiplicato per 100.000 utenti il volume dei registri diventa abbastanza grande da richiedere strumenti specializzati per supportare l'uso efficace dei registri.

Registrazione in applicazioni native del cloud

Ogni linguaggio di programmazione ha strumenti che consentono la scrittura dei log e in genere il sovraccarico per la scrittura di questi log è basso. Molte delle librerie di registrazione forniscono diversi tipi di criticità, che possono essere ottimizzate in fase di esecuzione. Ad esempio, la libreria Serilog è una libreria di registrazione strutturata comune per .NET che fornisce i livelli di registrazione seguenti:

• Verboso
• Correzione errori di programma
• Informazione
• Avvertimento
• Errore
• Fatale

Questi diversi livelli di log offrono una granularità nella registrazione. Quando l'applicazione funziona correttamente nell'ambiente di produzione, può essere configurata per registrare solo messaggi importanti. Quando l'applicazione non funziona correttamente, il livello di log può essere aumentato in modo da raccogliere più log dettagliati. Ciò bilancia le prestazioni rispetto alla facilità di debug.

Le prestazioni elevate degli strumenti di registrazione e la ottimizzabilità della verbosità dovrebbero incoraggiare gli sviluppatori a registrare frequentemente. Molti prediligono un modello di registrazione dell'ingresso e dell'uscita di ciascun metodo. Questo approccio può sembrare eccessivo, ma è poco frequente che gli sviluppatori desiderino meno registrazione. In effetti, non è insolito eseguire deployment per l'unico scopo di aggiungere il logging a un metodo problematico. Errare sul lato della registrazione troppo e non troppo poco. Alcuni strumenti possono essere usati per fornire automaticamente questo tipo di registrazione.

A causa dei problemi associati all'uso dei log basati su file nelle app native del cloud, è preferibile usare i log centralizzati. I log vengono raccolti dalle applicazioni e inviati a un'applicazione di registrazione centrale che indicizza e archivia i log. Questa classe di sistema può inserire decine di gigabyte di log ogni giorno.

È anche utile segui alcune pratiche standard durante l'implementazione del monitoraggio o registrazione dei log che si estende su molti servizi. Ad esempio, generando un ID di correlazione all'inizio di un'interazione lunga e quindi registrandolo in ogni messaggio correlato a tale interazione, semplifica la ricerca di tutti i messaggi correlati. È sufficiente trovare un singolo messaggio ed estrarre l'ID di correlazione per trovare tutti i messaggi correlati. Un altro esempio è garantire che il formato del log sia lo stesso per ogni servizio, indipendentemente dalla lingua o dalla libreria di registrazione usata. Questa standardizzazione semplifica la lettura dei log. La figura 7-4 illustra come un'architettura di microservizi può sfruttare la registrazione centralizzata come parte del flusso di lavoro.

Figura 7-4. I log provenienti da varie origini vengono inseriti in un archivio log centralizzato.

Problemi relativi al rilevamento e alla risposta a potenziali problemi di integrità delle app

Alcune applicazioni non sono cruciali. Forse vengono usati internamente e quando si verifica un problema, l'utente può contattare il team responsabile e l'applicazione può essere riavviata. Tuttavia, i clienti spesso hanno aspettative più elevate per le applicazioni usate. È necessario sapere quando si verificano problemi con l'applicazione prima che gli utenti eseseguono una notifica o prima che gli utenti avviscano l'utente. In caso contrario, la prima indicazione di un problema può essere quando noti un'infuriata ondata di post sui social media che deridono la tua applicazione o anche la tua organizzazione.

Alcuni scenari che potresti dover considerare includono:

• Un servizio nell'applicazione continua a fallire e a riavviarsi, provocando risposte lente intermittenti.
• In alcuni momenti del giorno, il tempo di risposta dell'applicazione è lento.
• Dopo una distribuzione recente, il carico sul database è aumentato di tre volte.

Implementato correttamente, il monitoraggio consente di conoscere le condizioni che causeranno problemi, consentendo di risolvere le condizioni sottostanti prima che comportino un impatto significativo sull'utente.

Monitoraggio delle app native del cloud

Alcuni sistemi di registrazione centralizzati assumono un ruolo aggiuntivo per la raccolta dei dati di telemetria al di fuori dei log puri. Possono raccogliere metriche, ad esempio il tempo necessario per eseguire una query di database, il tempo medio di risposta da un server Web e persino le medie di carico della CPU e la pressione della memoria, come indicato dal sistema operativo. In combinazione con i log, questi sistemi possono fornire una visualizzazione olistica dell'integrità dei nodi nel sistema e nell'intera applicazione.

Le funzionalità di raccolta delle metriche degli strumenti di monitoraggio possono anche essere inserite manualmente dall'interno dell'applicazione. I flussi aziendali di particolare interesse, ad esempio l'iscrizione o l'ordine dei nuovi utenti, possono essere instrumentati in modo da incrementare un contatore nel sistema di monitoraggio centrale. Questo aspetto sblocca gli strumenti di monitoraggio per monitorare non solo l'integrità dell'applicazione, ma anche l'integrità dell'azienda.

Le query possono essere create negli strumenti di aggregazione dei log per cercare determinate statistiche o modelli, che possono quindi essere visualizzate in forma grafica, nei dashboard personalizzati. Spesso, i team investono in schermi di grandi dimensioni montati su muro che ruotano attraverso le statistiche correlate a un'applicazione. In questo modo, è semplice vedere i problemi man mano che si verificano.

Gli strumenti di monitoraggio nativi del cloud forniscono dati di telemetria in tempo reale e informazioni dettagliate sulle app indipendentemente dal fatto che si tratti di applicazioni monolitiche a processo singolo o di architetture di microservizi distribuite. Includono strumenti che consentono la raccolta di dati dall'app, nonché strumenti per l'esecuzione di query e la visualizzazione di informazioni sull'integrità dell'app.

Sfide con la reazione a problemi critici nelle app native del cloud

Se è necessario reagire a problemi con l'applicazione, è necessario un modo per avvisare il personale corretto. Questo è il terzo modello di osservabilità dell'applicazione nativa del cloud e dipende dalla registrazione e dal monitoraggio. L'applicazione deve avere la registrazione per consentire la diagnosi dei problemi e, in alcuni casi, di inserire gli strumenti di monitoraggio. È necessario monitorare al fine di aggregare le metriche delle applicazioni e i dati sullo stato di salute in un unico luogo. Una volta stabilita questa impostazione, è possibile creare regole che attiveranno avvisi quando determinate metriche non rientrano nei livelli accettabili.

In genere, gli avvisi vengono sovrapposti al monitoraggio in modo che determinate condizioni attivino avvisi appropriati per notificare ai membri del team problemi urgenti. Alcuni scenari che potrebbero richiedere avvisi includono:

• Uno dei servizi dell'applicazione non risponde dopo 1 minuto di inattività.
• L'applicazione sta inviando risposte HTTP non riuscite a più di 1% di richieste.
• Il tempo medio di risposta dell'applicazione per gli endpoint chiave supera i 2000 ms.

Avvisi nelle app native del cloud

È possibile creare query sugli strumenti di monitoraggio per cercare condizioni di errore note. Ad esempio, le query potrebbero cercare nei log in ingresso indicazioni del codice di stato HTTP 500, che indica un problema in un server Web. Non appena viene rilevato uno di questi, è possibile inviare un messaggio di posta elettronica o un SMS al proprietario del servizio di origine che può iniziare a indagare.

In genere, tuttavia, un singolo errore 500 non è sufficiente per determinare che si è verificato un problema. Potrebbe significare che un utente ha digitato erroneamente la password o immesso alcuni dati in formato non valido. Le query di avviso possono essere create per essere attivate solo quando viene rilevato un numero di errori maggiore di 500.

Uno dei modelli più dannosi nell'invio di avvisi è quello di generare troppi avvisi per gli esseri umani da analizzare. I proprietari dei servizi diventeranno rapidamente desensibili agli errori che in precedenza hanno esaminato e hanno scoperto di essere benigni. Quindi, quando si verificano errori veri, andranno persi nel rumore di centinaia di falsi positivi. La parabola del Ragazzo che gridava al lupo viene spesso raccontata ai bambini per avvertirli di questo pericolo. È fondamentale garantire che gli avvisi che si attivano siano indicativi di un problema reale.

PrecedenteAvanti