Anche in questo caso si tratta di una soluzione di packet analysis, ovvero il traffico copiato sul NGINX viene inoltrato da Gigamon Cloud Suite verso la virtual appliance vStream di Netscout che si occuperà di effettuare l’analisi dei pacchetti ricevuti e produrre una serie di metriche che verranno visualizzate dalla console nGeniusONE.
La peculiarità di nGeniusONE è quella di caratterizzare le performance di un servizio, per cui esistono engines ad-hoc da utilizzare per analizzare specifici servizi per poi rappresentarne lo stato mediante una Service Dashboard, come si evince dall’immagine di seguito riportata che evidenzia lo stato del servizio chiamato “LoadBalancer”, costituito dal servizio “LoadBalancer-FrontEnd” e “LoadBalancer-BackEnd”.
Altra caratteristica estremamente interessante, è quella di poter ottenere la mappa automatica delle interconnessioni tra client e servers, chiamata Service Dependency, che ne evidenzi l’interazione nonché lo stato mediante le metriche di performance.
Dal punto di vista dell’analisi ricordo che il servzio “LoadBalancer-FrontEnd” pur avendo utilizzato l’engine “Web Service Monitor” ha di fatto analizzato l’applicazione a livello layer 4 in quanto trattasi di traffico criptato, di seguito se ne riporta l’aggregato nonché il dettaglio per i clients.
Di seguito si riportano le metriche principali per l’applicazione a livello di frontend.
- Latency = 8,92ms
- Requests = 984
- Failures = 0
Pur producendo innumerevoli metriche a livello TCP, a differenza della soluzione AppResponse di Riverbed, in questo caso il focus della soluzione è il servizio, ovvero il “server”, quindi in questo caso non abbiamo a disposizione delle metriche che cercano di rappresentare l’esperienza dell’utente, perché le metriche tipiche di TCP, come pacchetti trasmessi, pacchetti persi ed altro sono utilizzati solo al fine di determinarne lo stato ma non il tempo impiegato per rispondere alle richieste dei clients. L’unica metrica che evidenzia un delay è la latency dell’applicazione.
Per quanto riguarda il servizio “LoadBalancer-BackEnd”, ovvero l’applicazione di backend che utilizza il protocollo http, questi sono i dati di sintesi evidenziati :
- Latency = 2,90ms
- Requests = 1537
- Failures = 0
Anche in questo caso, pur utilizzando l’engine “Web Server Monitor” che è in grado di analizzare nel dettaglio il protocollo http, la sola metrica rilevante ai fini del delay è la latency dell’applicazione a differenza della soluzione AppResponse di Riverbed che è in grado di rappresentare l’esperienza dell’utente mediante la metrica Page Time.
Il fatto che la latency sia simile al valore Page Time di AppResponse è solo dovuto alle caratteristiche della pagina web utilizzata per il test nonché alle modalità di esecuzione.
Le immagini che seguono evidenziano rispettivamente l’aggregato a livello di BackEnd e il dettaglio per i due server di BackEnd.
In conclusione la soluzione vStream-nGeniusONE di Netscout è maggiormente indicata per esprimere lo status di un servizio mediante la “Service Dashboard”, in quanto le metriche dei diversi engine di analisi non forniscono un valore di “Digital Experience” confrontabile con quanto realmente percepito da un utilizzatore relativamente al tempo di caricamento di una pagina web.
Per continuare a leggere :