Tecniche di statistica avanzata e di apprendimento automatico per la RUE
Nell’era del cloud l’ottimizzazione della real end-user experience (RUE) sta diventando essenziale per il successo delle aziende. Da un lato gli utenti si aspettano che le applicazioni funzionino senza alcun errore indipendentemente dal luogo, momento o dispositivo utilizzato per accedervi. Application performance monitoring (APM) è perciò spesso basato sulle metriche prestazionali di utenti reali. D’altro canto, il network performance monitoring (NPM) ricopre un ruolo sempre più importante per la comprensione del reale funzionamento di un applicativo all’interno di una rete e dei potenziali impatti sulle prestazioni causate dai server o dalla rete stessa – application-aware network performance monitoring (ANPM). Obiettivi comuni dell’APM e del NPM sono l’utilizzo di metriche prestazionali misurate dalla RUE per assicurare la soddisfazione dell’utente finale identificando problemi all’occorrenza per risolvere potenziali rallentamenti o malfunzionamenti ancora prima che gli utenti possano percepirli.
Con lo sviluppo della versione 1.9 di WÜRTHPHOENIX NetEye RUE ci siamo focalizzati su richieste specifiche e abbiamo voluto semplificare il processo per la loro individuazione. Sebbene una visualizzazione molto dettagliata del maggior numero possibile di key performance indicators (KPI) è un passaggio importante per identificare la soluzione per specifiche problematiche, una visualizzazione più astratta e generica delle prestazioni della rete o degli applicativi e della percezione del livello qualitativo dell’utente finale potrebbe essere più vantaggiosa in una fase iniziale prima di analizzare in dettaglio i dati. Per questo motivo nel corso degli utlimi mesi ci siamo occupati di tecniche statistica avanzata e di apprendimento automatico che possono essere utilizzate per portare i dati archiviati al livello di astrazione desiderato.
Funzioni di densità di probabilità
Innanzitutto, abbiamo risposto al bisogno di coloro che già utilizzano il monitoraggio dei dati del traffico di rete e degli applicativi con WÜRTHPHOENIX NetEye RUE con una distribuzione dei dati meno distinta. Abbiamo pensato ad un’alternativa per gli allarmi di criticità (critical warning) ogniqualvolta i dati ricercati non abbiano delle medie ben distinte. Invece di caratterizzare il traffico standard come “traffico all’interno di un range attorno alla media” abbiamo iniziato ad esplorare la distribuzione dei dati attraverso la funzione di densità di probabilità. La nuova definizione di traffico standard è stata cambiata come “traffico all’interno di un certo range di uno dei massimi più prominenti della funzione di densità di probabilità” (vedi subnet 1). Specialmente in casi dove la media dei valori cade all’interno di due massimi locali (vedi subnet2), la qualità degli allarmi ci si aspetta che cresca notevolmente. Questo miglioramento è bidirezionale, infatti da un lato ridefinisce le baselines (valori base) evitando che il traffico standard venga falsato e considerato “al di fuori del suo range” e dall’altra parte i range più realistici migliorano la qualità degli allarmi ogniqualvolta valori cadano all’interno di regioni non consuete.
Apprendimento non supervisionato
Secondariamente, abbiamo provato la tecnica di apprendimento non supervisionato per dividere il traffico di rete in attività dense o sparse. L’apprendimento non supervisionato è una tecnica di apprendimento automatico che consiste nel fornire al sistema informatico una serie di input (esperienza del sistema) che egli riclassificherà ed organizzerà sulla base di caratteristiche comuni per cercare di effettuare ragionamenti e previsioni sugli input successivi. Un approccio comune è il raggruppamento dei dati in modo tale che i dati appartenenti allo stesso gruppo siano più simili tra loro che non con quelli in altri gruppi (clustering o analisi dei gruppi). Nel clustering density-based tali gruppi vengono definiti come aree con una maggior densità rispetto al resto dei dati. Si può assumere che richieste durante prestazioni standard possono essere più simili tra loro che richieste fatte da attività random o causate da problemi. Per questo motivo l’analisi della rete attraverso il clustering density-based può portare il vantaggio che le attività normali, standard possono essere separate da quelle del traffico irregolare.
Similmente alle baselines le regioni multi-dimensionali di traffico denso possono essere definite come regioni base (base regions), mentre qualcuno potrebbe voler eseguire analisi dettagliare delle regioni di traffico sparse, specialmente dove la regione sparsa mostra valori negativi per una o più KPI. Il seguente esempio vuole illustrare i vantaggi di una base region multidimensionale: per facilità ci limiteremo a considerare due dimensioni come metriche prestazionali, ovvero la latenza applicativa e il throughput.
L’application 1 – a sinistra – ha un range di dati ben definito in entrambe le dimensioni. Ci si può aspettare che gli allarmi basati sulle medie possano funzionare correttamente per entrambe le metriche. Questo non è il caso per l’application 2 – a destra. Non ci sono massimi locali distinti per il thorughput e le regioni, dove l’andamento del traffico è denso, le baselines non possono essere definite per ogni singola metrica prestazionale, ma attraverso l’apprendimento non supervisionato con gli algoritmi di clustering density-based in spazi multidimensionali che contengono tutte le metriche prestazionali. Per esempio la regione chiara delle attività sparse al centro del grafico dell’application 2 è circondata da regioni blu di attività dense.
Andamento prestazionale
Stiamo lavorando ad un nuovo strumento grafico che ci consenta di visualizzare un livello più alto dell’andamento prestazionale performance trend (PT) che può essere utilizzato sia per l’APM sia per l’NPM. Il PT utilizza entrambi i concetti illustrati sopra per portare enormi quantità di dati al livello di astrazione desiderato. Questa modalità offre la possibilità di controllare le prestazioni ad alto livello e consente allo stesso tempo di analizzare i dati sempre più nel dettaglio attraverso i vari drill down. In pratica il PT mostra i cambiamenti di una funzione di probabilità di densità stimata dei dati delle richieste attraverso il tempo. Un PT di traffico denso può visualizzare il quadro più ampio autentico delle prestazioni. Accanto al monitoraggio delle prestazioni nel tempo di potenziali problemi prestazionali questo tipo di tecnica può anche essere utilizzata in modo comparativo per valutare i dati di traffico della rete e degli applicativi prima e dopo certi interventi infrastrutturali.
L’interpretazione dei diagrammi PT è presto fatta. I colori più scuri (vedi a)) mostrano una frequenza di richieste inferiore, colori più chiari (vedi b)) indicano invece una maggior frequenza. Aree più vaste e strisce verticali sono causate da traffico costante (vedi b)). Aree più ristrette, macchie o punti si formano ogniqualvolta vi siano delle interruzioni nel traffico di rete o applicativi (vedi c)).
Concetto di utilizzo
Spiegheremo di seguito una possibile modalità di utilizzo delle nuove statistiche avanzate e tecniche di apprendimento automatico. Per esempio potrebbero esserci alcuni utenti all’interno di una rete aziendale che si lamentano di rallentamenti prestazionali di un determinato applicativo durante un giorno lavorativo specifico. Un diagramma PT del traffico di rete creato dall’applicazione di interesse durante il giorno lavorativo in questione potrebbe essere in grado di mostrare che non vi siano anomalie visibili ad alto livello eccetto alcune macchie lontane dal traffico standard per la latenza del client. Dopo un primo sospiro di sollievo si potrebbe voler analizzare ulteriormente la situazione applicando la tecnica di apprendimento non supervisionato attraverso il clustering density-based per scoprire che l’86% delle richieste del giorno sono concentrate per densità all’interno di un piccolo gruppo mentre il 14% delle richieste sono inserite in un traffico sparso. Il traffico denso standard può essere utilizzato come base per calcolare le nuove baseline o anche le regioni multidimensionali di base. Il traffico sparso invece contiene con molta probabilità informazioni relative a potenziali problemi e tutte quelle richieste responsabili per le macchie sospette. Per questo motivo una prima analisi all’interno dei dati potrebbe essere circoscritta nel traffico sparso. Per esempio attraverso il drill down a livello di richiesta. Uno studio più approfondito del traffico sparso potrebbe rivelare dati preziosi circa le cause del traffico non-standard. Conviene, infatti, analizzare il 14% dei dati che molto probabilmente sarà collegato a potenziali problemi, come nel caso di alcuni applicativi che dispongono di decine di migliaia di richieste al giorno, invece che svolgere un’analisi completa di tutte le informazioni che richiederebbe sicuramente troppo tempo.
Potete trovare maggiori dettagli ed un caso di utilizzo concreto nel Whitepaper.
Susanne Greiner
Author
