Analisi e monitoraggio di un web service con Grafana e InfluxDB

Analisi e monitoraggio di un web service con Grafana e InfluxDB

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:

Perché Grafana

Ci sono molte ragioni per cui mi sono orientato verso Grafana:

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:

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

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

Visualizzazione con 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

stack TICK

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: