Il monitoraggio delle infrastrutture informatiche negli ultimi anni si sta spingendo sempre di più verso il controllo delle prestazioni percepite dall’utente finale. L’obiettivo della Real User Experience sussiste nell’analisi della rete e degli applicativi per identificare tempestivamente eventuali disservizi. In questo contesto viene presentato l’esempio di Würth Phoenix, che con NetEye adotta nuove tecniche di statistica e di apprendimento automatico per identificare il vero andamento del traffico di rete
Di Georg Kostner, responsabile del reparto di System Integration in Würth Phoenix
Nell’era del cloud l’ottimizzazione della Real User Experience (RUE) sta diventando essenziale per il successo delle aziende. Gli utenti si aspettano che le applicazioni funzionino senza alcun errore indipendentemente dal luogo, momento o dispositivo utilizzato per accedervi. Tale disponibilità viene garantita da un lato dall’Application Performance Monitoring (APM), che è perciò spesso basato sulle metriche prestazionali di utenti reali, dall’altro dal network performance monitoring (NPM), che 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 e per risolvere potenziali rallentamenti o malfunzionamenti ancora prima che gli utenti possano percepirli.
I valori medi e l’andamento reale
Questi metodi tuttavia possono presentare degli svantaggi, infatti in alcune circostanze le baseline vengono calcolate come la media dei valori registrati non rispecchiando esattamente il comportamento reale del servizio. Per determinare le prestazioni dei vari servizi, il sistema di monitoraggio infatti misura la latenza media in un determinato periodo. Quindi il valore medio è calcolato in fasce orarie lavorative in cui si presume che i sistemi operino nella normalità. Nel momento in cui il sistema di monitoraggio entra in operatività, ogniqualvolta si registrano delle deviazioni dai range delle baseline vengono segnalati possibili errori di rete, server o applicativi. Nonostante questi allarmi non è possibile comprendere il reale comportamento dell’intero sistema. Infatti i valori medi calcolati non escludono dal calcolo possibili eccezioni che si sono verificate durante la misurazione delle baseline, perciò questi range di riferimento non sono del tutto attendibili per identificare in modo preciso un reale malfunzionamento.
L’ottimizzazione nella generazione degli allarmi
Per una maggior comprensione del significato di tali affermazioni, è possibile valutare come le soluzioni di monitoraggio presenti sul mercato affrontano tale tematica. In questo contesto NetEye, ad esempio, si pone come una soluzione che si focalizza nell’identificare tutte quelle richieste utente considerate al di fuori della normale operatività. Per ottenere questi risultati sono state utilizzate tecniche di statistica avanzata e apprendimento automatico che riescono a portare i dati archiviati al livello di astrazione desiderato. In particolare si possono rilevare valori di interferenza con le funzioni di densità di probabilità, un metodo che consente di analizzare la probabilità della distribuzione dei valori entro un certo range. In base a questa analisi quindi, il traffico standard non viene più considerato come “traffico all’interno di un range attorno alla media”. La nuova definizione di traffico standard diventa “traffico all’interno di un certo range di uno dei massimi più prominenti della funzione di densità di probabilità”. Specialmente nei casi in cui la media dei valori cade all’interno di due massimi locali, la qualità degli allarmi aumenta 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.
Andamenti positivi e negativi del traffico dati
Il secondo metodo utilizzato da NetEye consiste nell’apprendimento non supervisionato (machine learning), utilizzato al fine di dividere il traffico di rete in flussi di dati densi o sparsi. I dati vengnon raggruppati in modo tale che i dati appartenenti allo stesso gruppo siano più simili tra loro che non con quelli in altri gruppo. Si può assumere che richieste avvenute durante delle prestazioni standard possono essere più simili tra loro che le richieste eseguite da attività random o che causano problemi di disservizio. 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.
I vantaggi del nuovo approccio di analisi
Il vantaggio di questo nuovo approccio si può comprendere meglio con un esempio: gli utenti lamentano rallentamenti prestazionali su un certo applicativo durante un giorno lavorativo specifico. Un diagramma 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. Analizzando ulteriormente la situazione si può applicare la tecnica di apprendimento non supervisionato attraverso il clustering density-based per scoprire che l’85% delle richieste del giorno sono concentrate per densità all’interno di un piccolo gruppo mentre il 15% delle richieste sono inserite in un traffico sparso. Il traffico denso standard può essere utilizzato come base per calcolare le nuove baseline. Il traffico sparso invece contiene con molta probabilità informazioni relative a potenziali problemi e tutte quelle richieste responsabili di eventuali rallentamenti o disservizi. 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 15% 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.
In conclusione
La combinazione tra la funzione di densità di probabilità e l’apprendimento automatico consente di separare il traffico dati regolare da quello anomalo, che può essere preso in considerazione per analizzare possibili fonti di errore. Inoltre questo approccio fornisce importanti informazioni circa la proporzione delle richieste di un’applicazione che costituiscono traffico normale e quindi non significante per aventuali attività di troubleshooting – da quello che contiene informazioni più interessanti, ovvero il traffico sparso e le anomalie registrate. Quindi il traffico denso si differenzia dal traffico sparso rappresentando in modo multidimensionale esattamente ciò che gli utenti verificano durante la loro operatività sul posto di lavoro – la vera Real User Experience.
