Dopo i due precedenti casi di : web browser extension e JavaScript injection nelle pagine web, vediamo ora una soluzione che si basa sulla packet analysis. Come già detto i pacchetti sono intercettati sul NGINX di frontend che è anche il terminatore SSL/TLS delle sessioni e vengono copiati mediante la soluzione Gigamon Cloud Suite verso la virtual appliance Alluvio AppResponse di Riverbed, che riceverà dunque sia il traffico https dei client verso il frontend che verrà analizzato mediante la feature ASA (Application Stream Analysis), nonché il traffico http di backend consentendo in questo modo di poter sfruttare la funzionalità Web Transaction Analysis (WTA) di AppResponse.
L’engine ASA (Application Stream Analysis) analizza il traffico a livello layer 4 e mostra la digital experience dell’utente evidenziando la metrica User Response Time che è calcolata come la somma di : Connection Setup Time + Rquest Payload Transfer Time + Response Payload Transfer Time + Server Response Time + Retransmission Delay .
E’ pertanto possibile individuare eventuali modifiche dell’esperienza digitale di un utente imputabile a problemi di rete, nonché a problemi a livello server, senza tuttavia avere la possibilità immediata di poterne individuare la causa, ma saranno necessarie ulteriori investigazioni più approfondite e soprattutto la necessità di correlare tali metriche con altre.
Grazie al supporto di REST API da parte di Alluvio AppResponse ho creato un import automatico di tutte le metriche di interesse nell’analytic OpenSearch, in questo modo ho avuto la possibilità di correlare i dati di performance a livello di frontend con quelli di backend e con le metriche specifiche del servizio NGINX nonché di sistema acquisite mediante MetricBeat di Elastic ed esportate verso un modulo di Logstash per fare la digital transformation ed aggiungere ulteriori dati prima di fare l’ingestion nella pipeline di OpenSearch.
Di seguito si riporta il dettaglio dell’applicazione a livello di frontend.
- User Response Time = 13,22ms
- Connection Setup Time = 0,46ms – 3,48%
- Request Payload Transfer Time = 0,43ms – 3,25%
- Response Payload Transfer Time = 0,92ms – 6,96%
- Server Response Time = 11,48ms – 86,84%
- Retransmission Delay = 0 – 0%
- Turns = 1437
L’analisi del traffico http di backend, consente alla feture WTA (Web Transaction Analysis) di poter evidenziare le page families, ovvero le url e mostrare dei dati relativamente alla digital experience, basati sulla metrica Page Time che esprime la quantità totale di tempo trascorso dall’utente finale/browser per ricevere le risposte HTTP per tutte le richieste HTTP che costituivano una singola visualizzazione di pagina, questo tempo include tutto il tempo necessario per ricevere tutti gli oggetti facenti parte della pagina. Il Page Time, è la somma di Client Busy Time, Network Busy Time e Server Busy Time.
Il Client Busy Time è Il tempo calcolato trascorso dall’utente finale/browser tra la ricezione di una risposta HTTP e l’invio di una successiva richiesta HTTP.
Il Network Busy Time è il tempo calcolato impiegato dalla rete per trasportare richieste e risposte HTTP. Questo è distinto dai tempi di elaborazione nell’utente finale / browser e nel server web.
Il Server Busy Time è il tempo impiegato da un server Web per iniziare a inviare risposte HTTP dopo aver ricevuto le richieste HTTP corrispondenti. Questo è distinto dai tempi di elaborazione nell’utente finale / browser e nella rete.
Di seguito si riporta il dettaglio dell’applicazione a livello di backend.
- Page Time = 2,93ms
- Client Busy Time = 0 – 0%
- Network Busy Time = 0 – 0%
- Server Busiy Time = 2,93ms – 100%
- Page Views = 1408
Di seguito si riporta la correlazione tra frontend e backend, ciò consente di poter apprezzare il bilanciamento sui due server di backend.
Le immagini di seguito riportano i dettagli relativi alla applicazione di frontend, nonché la correlazione della stessa con le metriche di NGINX e di sistema.
Le immagini seguenti riportano i dettagli relativi alla applicazione di backend, nonché la correlazione della stessa con le metriche di sistema per ognuno dei due servers.
In conclusione possiamo affermare che le potenzialità offerte dalla soluzione Alluvio AppResponse di Riverbed, tramite le sue feature ASA e WTA se utilizzate per monitorare un applicazione sia a livello di frontend che di backend, permettono di ottenere metriche estremamente utili anche se ovviamente essendo l’analisi di frontend, condotta a livello layer 4 in quanto trattasi di traffico crittografato, non può produrre numeri di digital experience simili a quanto un utente potrebbe realmente percepire come accade nel caso di web browser extension o JavaScript agent. Tuttavia la capacità intrinseca di fornire un numero incredibile di metriche permette di poter compiere un’analisi molto dettagliata ed un troubleshooting molto efficace partendo dai dati di rete. L’utilizzo della feature WTA su dati di traffico consente solitamente di poter ottenere metriche che esprimono valori di digital experience assolutamente interessanti, in quanto in questo caso le singole transazioni sono correlate a livello di pagina oltre che evidenziate singolarmente nella specifica sezione di analisi, consentendo di fatto un risultato molto simile a quello generalmente offerta dagli strumenti di sviluppo dei browser web.
Nel caso in cui ovviamente il traffico indirizzato al frontend potesse essere decryptato, allora in quel caso la feature WTA esprimerebbe dei valori di digital experience a livello di frontend simili a quanto fornito dalla soluzione con browser extension e dal javascript iniettato nelle pagine.
Il tema della decryption del traffico https esula dallo scopo di questo documento e vista la complessità necessiterebbe di una apposita trattazione.
Per continuare a leggere :