Database: metriche utili per il monitoraggio

Il monitoraggio dei database è essenziale per un progetto data-driven. Ma qual'è il modo giusto per farlo? Quali sono i metodi per valutare la salute di un database? Negli ultimi anni sono state creati tantissimi sistemi che controllano vari aspetti delle applicazioni, la loro infrastruttura e persino gli utenti e le loro abitudini, ma spesso ci si dimentica che anche un database necessità di essere monitorato. Ciò è dovuto in gran parte al fatto che buona parte dei database fa il suo lavoro così bene che semplicemente ci si scorda della sua attività e si inizia a fidarsi del suo operato in modo incondizionato.

Esistono però diverse ragioni per monitorare un database, e sono gli stessi motivi per cui monitorare qualsiasi altra parte di un sistema. Più in particolare, i database sono degli indicatori di salute e del comportamento del sistema. Un comportamento anomalo nel database può indicare problematiche nelle applicazioni ed è possibile utilizzare metriche per accelerare i processi di debug.

Il modo migliore per avviare il monitoraggio di un database è quello di identificare le metriche database-agnostic fondamentali per il proprio progetto.

Throughput: quanto lavora il database?

Il modo più semplice per iniziare a monitorare un database consiste nel tenere traccia del numero di richieste ricevute dal database. Solitamente si hanno grandi aspettative per le prestazioni dei database: ci si attende che memorizzino i dati in modo affidabile e che gestiscano efficacemente le query. Il throughput può indicarci esattamente quanto lavora il database e con quante query si ritrova ad operare.

Durante tale analisi è anche possibile raggruppare le query per tipo (letture, scritture, lato server, lato client, ecc.) cosi da avere una visione d'insieme del traffico.

Tempo di esecuzione: quanto tempo impiega il database per svolgere il proprio lavoro?

Questa metrica viene spesso trascurata. E' necessario sapere non solo quante richieste ha ricevuto il database, ma anche quanto tempo ha speso per ogni richiesta. Tuttavia è importante valutare il tempo di esecuzione con il relativo contesto: ciò che consideriamo poco performante per un database come InfluxDB non è detto che lo sia per un database relazionale come MySQL. Essere lento nell'elaborare le richieste su InfluxDB potrebbe significare millisecondi, mentre il valore predefinito di MySQL per la variabile SLOW_QUERY è di 10 secondi.

Concorrenza: quante operazioni esegue il database contemporaneamente?

Una volta compreso il numero di richieste che il database gestisce e la durata di ciascuna, è necessario aggiungere un livello di complessità per iniziare a ottenere un valore reale dalle metriche. Se il database riceve 10 richieste e ognuna richiede 10 secondi per essere completata, il database verrà occupato per 100 secondi, dieci secondi o in un punto intermedio?

Il numero di attività simultanee cambia il modo in cui vengono utilizzate le risorse del database. Quando si inizia a considerare fattori come il numero di connessioni e thread, si può ottenere un'immagine più completa della salute del database. La concorrenza può influire anche sulla latenza, che include non solo il tempo necessario per completare l'attività (tempo di esecuzione), ma anche il tempo in cui l'attività deve attendere prima di essere gestita.

Utilizzo: quanto tempo il database resta occupato?

L'utilizzo è il culmine del throughput, del tempo di esecuzione e della concorrenza. Serve per determinare la frequenza con cui il database è disponibile o, in alternativa, la frequenza con cui il database era troppo occupato per rispondere a una richiesta. Questa metrica è particolarmente utile per determinare lo stato generale e le prestazioni del database, lavorare sull'ottimizzazione o apportare altre modifiche per avvicinarsi ad una disponibilità più elevata.

Tutte queste operazioni possono sembrare tediose e ripetitive, tuttavia diversi database integrano sistemi di monitoraggio delle performance. Tali sistemi sono progettati direttamente dal team di sviluppo dei database e sono pensati appositamente per esaminare i valori corretti e per determinate in modo esatto le performance del database. Ad esempio Postgres dispone del modulo pg_stats, CouchDB di Runtime_Statistics e InfluxDB di _internal.

Via Katy Farmer