Una riflessione di Joseph Hoffmann, Director, Sales Engineering, Dynatrace, sull’utilizzo della correlazione e della causalità nell’analisi delle prestazioni digitali
A cura di Joseph Hoffmann, Director, Sales Engineering, Dynatrace
Nell’analisi delle prestazioni digitali, molti vendor utilizzano il principio di correlazione per legare tra loro gli eventi osservati a partire da set di dati diversi e sostenere che esiste una connessione tra due insiemi. In questa mia riflessione dimostrerò come questo approccio sia viziato e porti a conclusioni alquanto imprecise, il che a sua volta può comportare perdite di tempo significative per i team tecnici e costi maggiori per l’azienda.
Analizziamo i due grafici seguenti che riguardano il numero di richieste registrate e l’utilizzo della memoria. Ecco come funziona la correlazione: “L’aumento del numero di richieste sta causando un aumento della memoria utilizzata. Meglio chiamare subito i tecnici e risolvere il problema”.
È stato relativamente semplice osservare come il numero di richieste abbia portato a crescere la dimensione della memoria ma, in questo caso, la conclusione tratta era sbagliata. I due valori osservati non avevano nulla a che fare tra loro! Dopo aver parlato con gli operatori di sistema, abbiamo infatti scoperto che era in esecuzione un’analisi intensiva della memoria e, una volta concluso questo lavoro, le cose sono cambiate. Guardando quindi agli stessi dati dopo pochi minuti il quadro complessivo era il seguente.
Un approccio migliore è quello di sostituire la correlazione con la causalità, che consente di definire con totale sicurezza quando un dato osservato rimanda a un altro. Non tutti oggi, però, utilizzano la causalità, soprattutto nel mondo dell’Application Performance Management, probabilmente perché la causalità è più difficile da implementare in un prodotto APM e molti clienti non capiscono ancora bene la differenza.
Le conclusioni sbagliate
Come dimostra l’esempio delle richieste e della memoria, solo perché si osserva un valore cambiare contemporaneamente a un altro, non significa che questi abbiano a che fare tra loro.
Il grafico seguente riporta un secondo esempio divertente: Tyler Vigen ha utilizzato l’ultimo 
censimento negli Stati Uniti per cercare false correlazioni a partire da dati pubblici. Lo sapevate che il consumo di margarina può causare il divorzio? Detto così l’errore è evidente, ma molti fornitori di APM ci cadono costantemente, usando la correlazione per determinare ciò che non funziona in un Enterprise Data Center.
La strada giusta
Anche se teoricamente tutti sabbiamo che “la correlazione non implica la causa”, agli esempi sopra citati se ne potrebbero aggiungere molti altri nel mondo dei sistemi di computing multi-threaded.
Nei sistemi di elaborazione complessi, infatti, molte cose accadono simultaneamente e il rischio di identificare associazioni sbagliate è molto alto.
Come ingegnere delle prestazioni, se voglio identificare la causa vera dei problemi di sistema e risolverli, devo conoscere con certezza quali sono gli eventi che causano altri eventi come, in particolare, le transazioni, le operazioni cross thread, i processi, i server e i data center. Solo una tale consapevolezza permette di risolvere rapidamente i problemi e indentificare la causa principale, anche in sistemi complessi. Il grafico seguente mostra, ad esempio, una transazione abbastanza semplice in esecuzione tra due livelli java e un database Oracle. In questo caso si è partiti dall’analisi di un clic singolo dell’utente che è stato segnalato perché ha richiesto troppo tempo. Utilizzando un approccio basato sulla causalità per analizzare i vari eventi in questo ambiente multi-tier, è possibile arrivare a 168 chiamate al db Oracle, tutte legate allo stesso singolo clic dell’utente. Tutti questi aspetti, insieme, si possono analizzare solo con la causalità.
Il semplice fatto che Dynatrace AppMon cattura ogni transazione per tutta la sua durata e utilizza un approccio di tagging rispetto a ogni chiamata remota, offre agli esperti una causalità basata su dati, una sicurezza ed elementi concreti su ciò che veramente sta causando dei problemi di sistema. Essere in grado di indicare al team di sviluppo direttamente alla causa principale non ha prezzo quando il tempo, il denaro e la vostra reputazione aziendale sono in gioco.
Concludendo, è insensato giocare d’azzardo affidando il proprio business alla correlazione, quando si può avere il meglio con la causalità.
