Oggi pi\u00f9 che mai, l\u2019erogazione di servizi web \u00e8 parte sempre pi\u00f9 centrale di ogni progetto.<\/p>\n\n\n\n
I clienti si aspettano di fruire in modo fluido ed ininterrotto dei servizi messi a loro disposizione, indipendentemente dal momento della giornata o dal traffico gestito. <\/p>\n\n\n\n
Mantenere un’esperienza utente di buona qualit\u00e0 \u00e8 diventato quindi un elemento essenziale all\u2019interno di un mercato altamente competitivo, dove qualsiasi interruzione o rallentamento nell’erogazione dei servizi pu\u00f2 avere serie conseguenze, come la perdita di clienti, di opportunit\u00e0 di vendita o il peggioramento della reputazione aziendale. <\/p>\n\n\n\n
L’esperienza utente non riguarda solo la facilit\u00e0 d’uso di un’applicazione, ma anche la velocit\u00e0 di risposta e l’affidabilit\u00e0 percepita. In questo contesto, il monitoraggio dei sistemi e delle applicazioni a diretto contatto con il pubblico \u00e8 un aspetto critico per permettere alle aziende di reagire prontamente ad eventi avversi che potrebbero compromettere la disponibilit\u00e0 e fruibilit\u00e0 dei servizi che offrono.<\/p>\n\n\n\n
Esistono svariate soluzioni di monitoraggio che promettono di fornire un quadro completo sull\u2019operativit\u00e0 dei sistemi in modo semplice e senza richiedere particolari interventi.<\/p>\n\n\n\n
Tuttavia, l\u2019impiego di una soluzione generica \u00e8 solo parzialmente preferibile alla totale assenza di monitoraggio. Infatti, un monitoraggio approssimativo e generico pu\u00f2 dare la falsa sicurezza di avere tutto sotto controllo, pur essendo ciechi a situazioni che impattano l\u2019esperienza utente e che sono visibili dagli utenti. Utilizzare metriche \u201cdi default\u201d o pi\u00f9 in generale non adatte al monitoraggio del caso specifico, fornisce una visione parziale o distorta della realt\u00e0, che pu\u00f2 facilmente portare a mancate segnalazioni.<\/p>\n\n\n\n
Questo tipo di situazioni, in cui i clienti sperimentano rallentamenti o errori durante la fruizione dei servizi, sono deleterie per la retention e la reputazione aziendale; diventano ancora pi\u00f9 gravi se l\u2019organizzazione non \u00e8 a conoscenza della situazione, e di conseguenza non pu\u00f2 gestirla tempestivamente.<\/p>\n\n\n\n
Fortunatamente, la maggior parte delle soluzioni di monitoraggio possono essere personalizzate per monitorare metriche e KPI personalizzati, che siano veramente indicativi della salute dell\u2019applicazione. Questo tipo di configurazione \u00e8 generalmente time consuming e richiede un\u2019attenta analisi dei flusso utente e degli eventi applicativi per determinare quali grandezze sono realmente rappresentative del buon funzionamento del servizio erogato, tuttavia \u00e8 un\u2019attivit\u00e0 essenziale per avere un\u2019immagine veritiera dello stato di salute del servizio.<\/p>\n\n\n\n
Il sistema di monitoring ideale raccoglie e mette in relazione sia le metriche applicative, personalizzate e pertinenti al caso specifico, sia quelle infrastrutturali, in modo da avere un\u00a0quadro completo e veritiero di come stia funzionando l’applicazione. Vedremo come l’importanza delle metriche applicative non possa essere sottovalutata per avere una visione completa e accurata dello stato di salute di un workload.\u00a0<\/p>\n\n\n\n
Mentre estrarre metriche infrastrutturali \u00e8 solitamente assistito dal Cloud provider, non vi \u00e8 nulla di standard per quanto riguarda le metriche applicative.<\/p>\n\n\n\n
In questo articolo, parleremo dell\u2019importanza di monitorare metriche che riflettano il reale funzionamento di un’applicazione, vedremo come definire e raccogliere metriche generate dall\u2019applicazione che siano pertinenti al dominio e al contesto del servizio.<\/p>\n\n\n\n
Nella trattazione racconteremo inoltre alcuni esempi concreti di come le metriche applicative possono rivelare insidie altrimenti nascoste.<\/p>\n\n\n\n
Senza ulteriori indugi iniziamo ad approfondire i concetti fondamentali per arrivare alla definizione di un buon sistema di monitoring.<\/p>\n\n\n\n
Un sistema di monitoring \u00e8 un insieme di strumenti e di processi progettati per raccogliere, analizzare e presentare dati rilevanti sull’applicazione e sull’infrastruttura cloud. <\/p>\n\n\n\n
I dati dovrebbero consentire agli amministratori e agli sviluppatori di profilare le performance della soluzione, identificare potenziali problemi e risolverli tempestivamente, garantendo un’esperienza utente priva di criticit\u00e0. Gli stessi dati possono essere sfruttati per capire pi\u00f9 profondamente le implicazioni delle scelte infrastrutturali e di architettura del software, e per apportare miglioramenti e ottimizzazioni.<\/p>\n\n\n\n
Un buon sistema di monitoring dovrebbe offrire visibilit\u00e0 in near real-time sull’operativit\u00e0 dell’applicazione e dell’infrastruttura, e dovrebbe essere facilmente integrabile sia con l\u2019applicazione che con eventuali strumenti di gestione preesistenti.<\/p>\n\n\n\n
Come precedentemente accennato, possiamo identificare due principali categorie di metriche: quelle infrastrutturali, e quelle applicative.<\/p>\n\n\n\n
Il monitoring pi\u00f9 diffuso e di immediata adozione \u00e8 quello di tipo infrastrutturale, che si concentra sull\u2019estrazione di metriche relative all’infrastruttura a sostegno degli applicativi. Include metriche come l’utilizzo della CPU, la larghezza di banda utilizzata, il throughput del disco, l\u2019utilizzo di RAM, il numero di richieste HTTP o di connessioni in ingresso.<\/p>\n\n\n\n
Spesso, queste metriche possono essere fornite direttamente dal cloud provider, e non \u00e8 richiesta alcuna modifica applicativa per raccoglierle.<\/p>\n\n\n\n
Le metriche infrastrutturali possono fornire una visione dettagliata delle risorse fisiche e virtuali utilizzate dall’applicazione all’interno dell’ambiente Cloud, sono essenziali per garantire che l’infrastruttura fornisca le risorse necessarie all\u2019applicazione e che quest’ultima operi in modo efficiente.<\/p>\n\n\n\n
Le principali metriche che i cloud provider mettono a disposizione sono:<\/p>\n\n\n\n
Un sistema di monitoraggio infrastrutturale, sebbene fondamentale, pu\u00f2 risultare non sufficiente per ottenere un quadro generale veritiero dello stato di salute e delle performance di un servizio. Esistono infatti situazioni in cui un monitoraggio esclusivamente infrastrutturale pu\u00f2 non essere in grado di rilevare problemi che impattano l\u2019esperienza utente, fino, in casi estremi, in cui risultano bloccanti per gli utenti finali.<\/p>\n\n\n\n
Occorre considerare che le metriche infrastrutturali forniscono solo una parte del quadro complessivo delle prestazioni dell’applicazione, pertanto \u00e8 necessario pensare ad un modo per ottenere maggiori insight su come l\u2019applicazione stia performando.<\/p>\n\n\n\n
A questo punto, \u00e8 lecito domandarsi quali situazioni possono sfuggire ad un sistema di monitoraggio dell\u2019infrastruttura.<\/p>\n\n\n\n
Per capire in quali situazioni le metriche infrastrutturali non sono sufficienti, possiamo esplorare due scenari tipici.<\/p>\n\n\n\n
Ipotizziamo che con il rilascio di una nuova versione dell\u2019applicazione sia stato introdotto un baco che impedisce agli utenti finali di svolgere un\u2019azione, per esempio per un problema di rendering del front-end.<\/p>\n\n\n\n
Dal punto di vista delle metriche infrastrutturali, tale errore non sarebbe rilevabile, se non forse in seguito all\u2019abbandono da parte degli utenti, che provocherebbe un utilizzo di risorse inferiore alla norma. In questa situazione, \u00e8 probabile che si venga a conoscenza del problema dalle segnalazioni degli utenti prima che sia deducibile dalle metriche raccolte, decretando, di fatto, il fallimento simultaneo delle procedure di rilascio e quality control, sia del sistema di monitoraggio.<\/p>\n\n\n\n
Possiamo anche immaginare uno scenario in cui il rilascio sembra essere andato a buon fine, con un funzionamento regolare di giorni o settimane, fino a quando una condizione non prevista rende inutilizzabile alcune funzioni del servizio. Mentre una parte degli errori non gestiti pu\u00f2 essere intercettato dalle metriche infrastrutturali, per esempio conteggiando il numero di errori HTTP, molti altri errori vengono \u201cgestiti\u201d mostrando un messaggio all\u2019utente, e se l\u2019applicazione non \u00e8 progettata per emettere una metrica specifica, o una notifica di errore, il sistema di monitoraggio non avr\u00e0 alcun modo di rilevare la criticit\u00e0.<\/p>\n\n\n\n
Infine, il caso pi\u00f9 banale \u00e8 la semplice propagazione di una versione che contiene un errore logico, dove una o pi\u00f9 funzioni dell\u2019applicazione non registrano errori, ma forniscono un risultato errato all\u2019utente, che gli impedisce quindi di continuare a fruire correttamente del servizio.<\/p>\n\n\n\n
Molte applicazioni fanno affidamento su servizi di terze parti, per esempio per la gestione dei pagamenti online, oppure per l\u2019autenticazione degli utenti. Problemi di integrazione o malfunzionamenti nei servizi di terze parti possono influenzare notevolmente l’esperienza utente, ed \u00e8 facile che tali situazioni non vengano rilevate dalle metriche infrastrutturali.<\/p>\n\n\n\n
Supponiamo, ad esempio, che l\u2019applicazione utilizzi un servizio di pagamento, e che quest’ultimo smetta di processare correttamente i pagamenti relativi ad un circuito di pagamento. Spesso, l\u2019errore di pagamento viene restituito direttamente all\u2019utente, mentre l\u2019applicazione non subisce un fallimento e continua ad operare correttamente invitando l\u2019utente a riprovare. In questo scenario, le metriche infrastrutturali,potrebbero non rendere visibile che una porzione dell\u2019utenza non riesce a finalizzare il pagamento.<\/p>\n\n\n\n
Le metriche dell\u2019infrastruttura sono un aspetto fondamentale del monitoraggio delle applicazioni cloud, tuttavia non sono sufficienti a garantire che gli utenti stiano fruendo del servizio in modo soddisfacente. Per ottenere una visione completa delle prestazioni dell’applicazione e garantire un’esperienza utente di alta qualit\u00e0, \u00e8 essenziale predisporre anche il monitoraggio delle metriche applicative per valutare l’applicazione in modo pi\u00f9 completo e accurato.<\/p>\n\n\n\n
Arriviamo infine a parlare delle metriche applicative. Queste sono essenzialmente delle metriche che possono essere estrapolate dall\u2019applicazione,per esempio effettuando il parsing dei log, oppure facendo query sul database.<\/p>\n\n\n\n
Nelle applicazioni pi\u00f9 moderne, o in fase di sviluppo, \u00e8 possibile fare in modo che l\u2019applicazione stessa emetta in modo esplicito le metriche di interesse, inviandole regolarmente al servizio di monitoring che le raccoglie e le rende disponibili agli operatori.<\/p>\n\n\n\n
Le metriche applicative forniscono informazioni sul funzionamento interno dell\u2019applicazione, dando visibilit\u00e0 su elementi vicini alla business logic e sull’interazione che il cliente ha con il software. <\/p>\n\n\n\n
Per entrare nell\u2019ottica del tipo di metriche che dobbiamo imparare ad estrarre, supponiamo di gestire un e-commerce; l\u2019obiettivo del nostro servizio \u00e8 quindi quello di vendere il pi\u00f9 possibile e di soddisfare i clienti con una buona esperienza utente.<\/p>\n\n\n\n
In questo scenario, una metrica applicativa interessante potrebbe essere il numero di utenti loggati che stanno facendo shopping, misurato dall\u2019applicazione emettendo il numero di sessioni attive che hanno fatto richieste negli ultimi 30 minuti. La stessa informazione potrebbe anche essere ricavata da un servizio dedicato, che esegue periodicamente query sul database dell’e-commerce al fine di ottenere la metrica, e provvede ad emetterla verso il sistema di monitoraggio.<\/p>\n\n\n\n
Un\u2019altra metrica rappresentativa dello stato dell\u2019applicazione potrebbe essere il numero di carrelli con almeno un articolo, che ci da un\u2019idea di quante persone abbiano intenzione di acquistare qualcosa, e quindi della pipeline delle potenziali vendite. E ancora, il numero totale di articoli nei carrelli di tutta la base utenti, o l\u2019importo totale delle vendite potenziali. Infine, la metrica pi\u00f9 rappresentativa del raggiungimento dell\u2019obiettivo \u00e8 sicuramente il numero di acquisti finalizzati.<\/p>\n\n\n\n
Per scegliere le metriche pi\u00f9 adatte da far emettere all’applicazione, bisogna considerare il tipo di applicazione e gli obiettivi che l\u2019organizzazione vuole raggiungere mediante l\u2019esposizione del servizio ai clienti. Occorre quindi individuare le funzioni chiave, quelle pi\u00f9 importanti e collegate al raggiungimento degli obiettivi. <\/p>\n\n\n\n
In altre parole bisogna identificare il valore <\/strong>che il servizio offre ai clienti, e definire come misurarlo con i dati a disposizione del software. Per fare un\u2019altro esempio in un campo diverso, supponiamo di voler raccogliere metriche per un servizio di streaming musicale: il valore \u00e8 certamente il numero di brani ascoltati, ma anche il tempo di ascolto. Altre metriche utili potrebbero rendere visibile il tasso di fidelizzazione e di acquisizione di nuovi clienti, per esempio misurando il tasso di abbonamento, il tasso di disiscrizione, ecc. <\/p>\n\n\n\n Una volta che \u00e8 chiaro il valore che si vuole offrire ai clienti, si possono definire delle metriche che riflettano gli aspetti pi\u00f9 rilevanti del proprio business per il monitoraggio dell’applicazione e la valutazione delle sue performance.<\/p>\n\n\n\n In secondo luogo, occorre identificare i processi <\/strong>aziendali che sono coinvolti nell\u2019erogazione del servizio, e capire se parte del loro output pu\u00f2 essere misurato usando dati ed eventi cui il servizio ha visibilit\u00e0.<\/p>\n\n\n\n Tornando all\u2019esempio dell\u2019e-commerce, i processi che incidono visibilmente sull\u2019esperienza utente, e di cui \u00e8 facilmente possibile ottenere informazioni sulle performance mediante il servizio potrebbero essere il tempo di preparazione dei pacchi, il tempo di consegna, il numero di ordini, il numero di reclami, e cos\u00ec via. Monitorare questa tipologia di metriche permette di identificare una possibile inefficienza o un problema in modo automatico, e di agire tempestivamente.<\/p>\n\n\n\n A questo punto dovrebbe essere chiaro che raccogliendo in modo centralizzato metriche applicative, pi\u00f9 vicine al business, e metriche infrastrutturali, il quadro sulla salute dell\u2019applicazione diventa molto pi\u00f9 chiaro e completo. Diventa possibile mettere in relazione entrambi le tipologie di metriche, per identificare una vasta gamma di criticit\u00e0 ed intervenire in modo mirato.<\/p>\n\n\n\n La maggior parte delle soluzioni di monitoring permettono la raccolta di metriche personalizzate, \u00e8 quindi una buona pratica utilizzare l\u2019applicazione, agent o moduli addizionali per emettere le metriche applicative, ed inviarle al sistema di monitoring centralizzato.<\/p>\n\n\n\n In conclusione, abbiamo visto come le metriche applicative siano uno strumento fondamentale per valutare il reale funzionamento di un servizio, da abbinare anche alle metriche infrastrutturali per ottenere il quadro completo dello stato dell\u2019applicazione. <\/p>\n\n\n\n Abbiamo anche parlato di come definire e raccogliere metriche che siano allineate agli obiettivi di business, in modo da poter monitorare gli aspetti pi\u00f9 critici e rilevanti per il successo dell’applicazione. <\/p>\n\n\n\n Infine, abbiamo presentato alcuni esempi di come le metriche applicative possano rivelare insidie altrimenti nascoste, come errori silenziosi, degradazioni progressive o anomalie comportamentali.<\/p>\n\n\n\n Speriamo che questo deep-dive sia stato utile.<\/p>\n\n\n\n Ci vediamo tra 14 giorni con un nuovo articolo!<\/p>\n\n\n\nConclusioni<\/h2>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n