L’ambiente di test utilizzato consente a chiunque di poter facilmente comprendere cosa si intende per End User Experience, Real User Monitor ecc., in sostanza una metrica che evidenzi l’esperienza di un utente quando naviga utilizzando un web browser, ovvero quanto tempo si impiega ad ottenere una pagina completa di tutte le informazioni richieste da un’azione richiamata da un web browser.
Nel nostro caso la pagina web contiene semplicemente delle immagini, 5 per l’esattezza, e viene richiamata da due PC mediante una connessione HTTPS con il bilanciatore NGINX che bilancerà il carico http su due server di backend.
Il tempo impiegato per restituire la pagina richiesta dal browser è frutto della interazione di tutti i componenti sia infrastrutturali che applicativi, posti lungo il percorso tra il client e il server di backend che dovrà restituire il dato richiesto. Nel nostro caso, il tutto è relativamente semplice, ma provate a pensare ad una applicazione magari in cloud acceduta da client in giro per il modo, che possono collegarsi in molteplici modalità, nonché ad un applicazione assai più complessa della mia, che coinvolge svariati server o magari decine e decine di microservizi, le latenze di rete oltre che le latenze dei sistemi stessi possono avere un peso significativo in talune circostanze, pertanto avremo anche la necessità non solo di disporre di una soluzione che sia in grado di esprimere con un numero la metrica che evidenzia il livello di digital experience percepita dall’utente, ma anche elementi essenziali per individuare nel più breve tempo possibile il cosiddetto fault domain per poi indirizzare le nostre attenzioni di analisi nel contesto del domain identificato, ecco perché l’observability intesa come correlazione di diverse metriche acquisite anche con tecniche differenti, risulta essere molto utile.
Al riguardo avremo modo di vedere in azione anche una tecnologia fondamentale come REST API, che ci permetterà di acquisire dati da sorgenti esterne e portarle all’interno del nostro analytic per consentirci di poter correlare metriche differenti.
Dobbiamo a questo punto sottolineare un aspetto estremamente importante troppo spesso sottovalutato o mal interpretato, ovvero monitoring passivo vs active testing.
Se vogliamo rilevare l’esperienza digitale dei nostri utilizzatori, ovunque essi siano ed indipendentemente dalla modalità di connessione utilizzata per raggiungere la nostra applicazione, non potremo certo utilizzare una tecnica che si basa sull’active testing, ovvero interrogazioni sintetiche più o meno complesse estremamente utili ma che hanno lo scopo eventualmente di monitorare la disponibilità di una applicazione o di un servizio o tutti i processi che lo costituiscono, ma che non riflette l’esperienza reale di tutti gli utenti di quella applicazione o di quel servizio.
L’esperienza digitale dei nostri utenti si ottiene dunque analizzando i flussi di traffico reali che gli utenti stessi generano con la loro attività. Detto questo dobbiamo a questo punto porre l’accento su quel’è il nostro punto di osservazione.
Client side
Nel caso in cui il nostro punto di osservazione fosse il client dell’utente, significa che dovremo installare qualcosa su ogni singolo client, indipendentemente dal sistema operativo dello stesso e indipendentemente dal browser utilizzato al fine di acquisire le informazioni necessarie per rilevare la digital experience di tutti gli utenti.
Esistono diverse soluzioni commerciali e non, che permettono di fare questo, la più semplice che chiunque ha utilizzato almeno una volta è quella di sfruttare gli strumenti di sviluppo offerti dai diversi web browser, Google Chrome, Microsoft Edge, Mozilla Firefox. Strumenti ideali per fare troubleshohting applicativo, ma non idonei per evidenziare l’esperienza digitale realmente percepita dagli utenti nel tempo.
Nel mio caso utilizzeremo una estensione per i browser Chrome/Edge/Firefox che permetterà tutto questo e vedremo quali sono le metriche che ci verranno messe a disposizione, si rimanda all’apposita sezione.
Questa tecnica richiede l’installazione di sw ad-hoc sui client, ma qualora avessimo un servizio che fosse acceduto non solo dagli utenti interni ma da clienti esterni su cui ovviamente non potremmo installare nulla, la soluzione che punta al client come punto di osservazione non è praticabile, sarebbe sostanzialmente inutilizzabile.
Server Side
Spostiamo a questo punto il focus sul server.
Spesso, direi troppo spesso molti clienti pongono la loro attenzione al server o ai servers facenti parte del servizio da monitorare, utilizzando le metriche che gli applicativi e i sistemi operativi mettono loro a disposizione e valutano la bontà o meno della qualità del servizio erogato basandosi su queste metriche, che non necessariamente riflettono la digital experience percepita dagli utenti, che la percepiscono sui loro client.
Abbiamo a questo punto due possibili opzioni, ovvero guardare al server/applicazione gestita dal server o guardare al traffico di rete generato dall’interazione del server con i client.
- La prima consiste nell’inserire ad esempio del codice java nelle pagine richiamate dai client, ciò permetterà di ottenere informazioni a livello di client, un po’ come abbiamo visto nel caso delle estensioni per i web browser utilizzati dai client.
Queste operazioni possono essere anche automatizzate, al fine di non richiedere di apportare modifiche all’applicazione. Queste tecniche consentono altresì di superare eventuali problemi dovuti al traffico crittografato tra client e server. Al riguardo esistono sia soluzioni commerciali che soluzioni opensource, rimando all’apposita sezione al riguardo.
- La seconda è quella di analizzare i flussi di traffico lato server per intercettare le richieste di tutti i client, ovvero un monitoring passivo fatto mediante la cosiddetta packet analysis, tecnica che ci porta a dover analizzare le modalità di acquisizione dei flussi e il punto dove intercettare il traffico di interesse. Al riguardo esistono soluzioni sia commerciali che opensource, molto diverse tra loro in termini di usabilità dell’informazione in certi contesti, rimando all’apposita sezione.
Le diverse soluzioni a confronto.
| Monitoring Solution | Vendor | Observation Point | Analysis Type |
| Web Browser APM Analysis | Netperf Consulting | Client | Browser Extension |
| APM (RUM-JS) | ElasticSearch | Server | Java Code |
| Alluvio AppResponse | Riverbed | Network – Server Side | Packet Analysis |
| vStream – nGeniusONE | Netscout | Network – Server Side | Packet Analysis |
| Packetbeat | ElasticSearch | Network – Server Side | Packet Analysis |
Le soluzioni di analisi che si basano sulla packet analysis, possono esprimere innumerevoli metriche, ma non sempre sono in grado di evidenziare l’esperienza digitale di un utente con un valore che sia simile alla percezione soggettiva che ognuno di noi potrebbe avere, questo perché le informazioni che vengono evidenziate dipendono come già detto dal punto di osservazione e soprattutto possono risentire del fatto che il traffico analizzato sia in chiaro o crittografato. Oggi l’adozione di tecniche di encryption asimmetriche ha complicato ulteriormente questo aspetto, ed in taluni casi potrebbe risultare pressoché impossibile disporre del traffico in chiaro, ecco perché è molto importante analizzare bene il punto di osservazione del traffico.
Nel caso dei test in lab, la scelta di copiare il traffico sul NGINX è risultata vincente perché ci permette di poter disporre sia del traffico crittografato verso il frontend che del traffico in chiaro verso il backend e ciò ci permette di evidenziare che nel caso dell’analisi del traffico verso il frontend, si tratta di un analisi fatta a livello Layer 4, quindi molto diversa da ciò che potremmo fare nel caso in cui il traffico fosse in chiaro, come il traffico di backend (http) che verrà analizzato a livello applicativo.
Quando siamo in presenza di un traffico crittografato, l’analisi layer4 produce metriche e valori molto diverse da quello che potremmo definire End User Experience/Real User Monitor/Page Load Time, perché appunto le transazioni che costituisco una singola pagina vengono misurate singolarmente e non sono correlate al contesto a cui appartengono.
Rimando alle apposite sezioni il dettaglio di questi aspetti, mi limito qui ad osservare semplicemente che l’analisi Layer 4, potrebbe tuttavia risultare estremamente utile ed apprezzata, per la sua capacità di individuare eventuali scostamenti dalle baseline ed evidenziare i fault domain più appropriati per investigare un eventuale problema. Quanto testé affermato è avvalorato dal fatto che spesso e volentieri i clienti scelgono di introdurre comunque un’analisi Layer 4 nella loro strategia complessiva, il perché lo capiremo quando affronteremo le specifiche sezioni.
Per continuare a leggere :