Le metriche: perché e come
Autore: Lorenzo Berni
Talvolta durante lo sviluppo di servizi web, si tende a dare bassa considerazione al monitoraggio sia di performance che di utilizzo del servizio. Mantenere un sistema comprensivo di metriche e una visualizzazione adeguata permetterà di scovare eventuali colli di bottiglia e bug prima ancora che si manifestino.
Il mio caso d’uso
Sono stato messo di fronte al tema delle metriche nel momento in cui mi è stato chiesto di monitorare le performance di una REST API, verificare quali endpoint fossero maggiormente stressati e tenere di conto dei codici HTTP di risposta. A questi parametri, strettamente relativi alla API, ho aggiunto poi ulteriori metriche relative all’utilizzo dei database sottostanti e relative performance.
L’analisi delle metriche permette a colpo d’occhio di individuare subito alcuni comportamenti anomali dell’API, comportamenti che altrimenti passerebbero del tutto inosservati a lungo.
Per quanto ragionevoli, i requisiti di un sistema di metriche sono stringenti:
- impatto tendente a zero sulle performance dell’API
- metriche fail-proof: la API avrebbe dovuto funzionare senza problemi anche in caso di malfunzionamento del sistema di collezione delle metriche
- semplicità di aggiunta di nuovi parametri da monitorare
- semplicità di aggiunta di nuove visualizzazioni su tali parametri
Perché Grafana
Ci sono molte ragioni per cui mi sono orientato verso Grafana:
- è un progetto open source, stabile e dotato di una documentazione decisamente esauriente
- è estremamente configurabile ed espandibile
- è attivamente sviluppato e mantenuto
- è utilizzato da molti big del settore – StackOverflow per dirne uno 🙂
- i grafici e le visualizzazioni generate sono decisamente gradevoli alla vista: anche l’occhio vuole la sua parte
- era già in uso per la monitorizzazione di alcuni servizi secondari 😀
Metriche interessanti per una REST API
Riempire di metriche la propria API non solo non è utile, ma può essere controproducente. Per questo conviene sempre fare un analisi approfondita di cosa si vuole monitorare. Ricevere tonnellate di alert inutili è poco più utile di non riceverne affatto.
Ecco alcuni parametri che potrebbero essere interessanti da monitorare:
- codici di errore HTTP: per quanto sia del tutto lecito restituire codici di errore, riconoscere a colpo d’occhio una improvvisa ondata può aiutare nelle successive indagini.
- errori interni: decisamente meno leciti dei precedenti, questi sono campanelli di allarme di possibili bug.
- performance dei vari endpoint: è interessante sapere se l’API sta perdendo troppo tempo dietro qualcosa in particolare. Potrebbe trattarsi di problemi nei servizi a cui si appoggia, un carico troppo elevato sul server o persino un problema hardware.
- anagrafica degli utilizzatori della API: utenti, client, device qualunque cosa. Capire chi sta usando l’API, in quanti e tramite cosa è la chiave per scovare insidiosi bug negli utilizzatori.
- sistema sottostante: è importante, per quanto possibile, tenere sotto controllo anche i servizi ai quali l’API si appoggia, quali database o altre API. Inoltre è importante avere degli indicatori di salute dell’hardware sul quale l’API è in ascolto.
Mentre è sconsigliato aggiungere grandi quantità di parametri poco interessanti, è invece di fondamentale importanza allegare a tali metriche quante più informazioni possibili: sapere che si stanno verificando molti errori nelle richieste è un buon punto di partenza, ma sapere che questi errori sono causati da utenti Android dislocati negli Stati Uniti tramite l’app aggiornata alla sua ultima versione rilasciata poche ore prima è molto più utile.
Rimani aggiornato!
Ricevi novità su Develer e sulle tecnologie che utilizziamo iscrivendoti alla nostra newsletter.
Dettagli sullo stack di metriche
statsd
Al primo livello dello stack, subito in contatto con la API REST si trova statsd, con il quale si comunica mediante statsd-client, un semplice modulo Python che implementa il protocollo di comunicazione via UDP. È stato scelto statsd per questo ingrato compito per via della sua capacità di tenere in memoria le metriche ricevute e generare in output oltre alle metriche stesse anche degli aggregati.
InfluxDB
Per la persistenza dei dati accumulati è stato scelto InfluxDB, un database robusto, scritto in go, su cui è possibile fare query utilizzando un linguaggio SQL-like. InfluxDB nasce con lo scopo di memorizzare time series di dati, ed è altamente performante sia in fase di salvataggio che in fase di query. Mantiene inoltre in un formato estremamente compatto i dati su filesystem. La comunicazione tra statsd e InfluxDB avviene tramite il protocollo graphite.
Grafana
La visualizzazione, invece, come scritto sopra è delegata a Grafana.
Grafana supporta innumerevoli sorgenti di dati, tra cui InfluxDB e mette a disposizione dei tool grafici all’interno della web app stessa per configurare semplicemente le query e modificare l’aspetto della visualizzazione dei risultati.
Conclusioni
Sono rimasto molto soddisfatto da Grafana così come dall’intero stack dedicato alle metriche. Eppure ho trovato talvolta molto macchinosa l’interfaccia di configurazione delle dashboard su Grafana. Inoltre un’altra pecca che ho riscontrato è l’impossibilità di poter configurare una serie di dashboard già pronte da utilizzare su una installazione pulita di Grafana stesso, tanto che per costruire un ambiente riproducibile e funzionante su docker sono stato costretto a scrivere degli script che importassero delle dashboard al primo avvio utilizzando la API HTTP di Grafana.
Rimuovere statsd dallo stack
Per quanto sia uno strumento maturo e affidabile, al termine del progetto sono giunto alla conclusione che non valesse la pena di includere un intero servizio aggiuntivo solo ed esclusivamente per ottenere gli aggregati temporanei: InfluxDB è sufficientemente potente e performante da poter effettuare le aggregazioni on-the-fly. Nel setup finale del progetto, eliminare statsd avrebbe significato rimuovere una dipendenza aggiuntiva, con relative problematiche di configurazione e manutenzione.
Dare una chance allo stack TICK offerto da InfluxData
Un altro punto che – considerando tempo e budget infinito – avrei sicuramente affrontato è una possibile migrazione all’intero stack TICK messo a disposizione da InfluxData (i creatori di InfluxDB).
Questo stack è formato da:
- Telegraf: la controparte di statsd offerta da InfluxData
- InfluxDB
- Chronograf: la controparte di Grafana offerta da InfluxData
- Kapacitor: un motore di processing dei dati provenienti da InfluxDB programmabile, utilizzabile per ricevere notifiche relative a soglie superate, pattern nelle metriche e quanto la vostra fantasia sia in grado di concepire.
Vuoi approfondire la tua conoscenza su Grafana? Leggi anche l’articolo Metriche di progetto con Grafana