Che la nostra applicazione sia composta da una moltitudine sconfinata di microservizi o che sia un singolo monolite, uno dei bisogni principali è la nostra capacità di determinarne il suo carico effettivo e il suo buono stato di funzionamento.

In altri termini appena mettiamo il nostro applicativo in produzione occorre poter rispondere in modo continuo a domande quali ad esempio:

• la nostra applicazione sta funzionando?
• a quante richieste al secondo sta rispondendo?
• quali sono i tempi di risposta?
• quanto traffico di rete sta producendo?
• quanto sono stressati i server su cui è collocata la nostra applicazione?

Il monitoraggio diventa ancora più utile se si incappa in problemi di prestazioni o malfunzionamenti:

• qual’è la richiesta http che risponde sempre in tempi lunghissimi?
• il database non riesce ad essere abbastanza rapido nelle risposte, ma forse c’è un collo di bottiglia da qualche parte?

La soluzione di monitoraggio opensource Prometheus può rispondere a queste e a molte altre domande affronta e risolve queste problematiche grazie anche all’ottimo compagno di viaggio Grafana.

Grafana è una applicazione Web che realizza grafici suddivisi in pannelli, con i dati provenienti da una molteplicità di sorgenti diverse, come OpenTSDB, InfluxDB, ElasticSearch… e Prometheus.

Punti salienti del sistema Prometheus

Prometheus è nato ed è completamente OpenSource. Il suo sviluppo è partito da SoundCloud, ma poi è stato sostenuto e indirizzato dalla comunità OperSource. Questo è un punto cruciale di un qualsiasi software Opensource: in effetti laddove manchi una direzione indicata dalla comunità, spesso mancano anche le effettive evoluzioni con requisiti indicati dagl utenti.

Il modello con con cui sono registrati i dati in time series (TS) è in formato chiave/valore aperto, quindi multi-dimensionale. È possibile inserire il tempo di risposta di una pagina web con molteplici etichette, per esempio:

• nome dell’applicazione
• percorso richiesto
• ip del server.

Con queste etichette per esempio sarà possibile ottenere statistiche aggregate per una o più di queste etichette:

• tempo medio di risposta per applicazione
• tempo massimo richiesto per un determinato percorso (la homepage per esempio)
• numero di richieste al secondo per server

Queste risposte si possono ottenere grazie ad uno specifico linguaggio di interrogazione: il PromQL. Questo risulta moltto flessibile e potente, grazie anche alla capacità di avvalersi della multi dimensionalità. Con il Prometheus Server operante in HTTP c’è un apposito Expression Browser, utile per provare le query e vedere l’effetto che fa. Si può anche utilizzare in congiunzione con i [Console Templates] per generare dei pannelli con grafici complessi quando le possibilità offerte da Grafana non sono sufficienti.

L’arichiettura Prometheus è decisamente modulare e permette di pensare in modo scalabile anche tutta la parte di monitoraggio. Prometheus ha in effetti la possibilità di scrivere/leggere i dati su/da elementi remoti, come Prometheus Server remoti o altri sistemi Time-Series (InfluxDb, OpenTSDB, …).

Un elemento importante dell’ecosistema Prometheus è l’autonomia con cui i vari nodi Server registrano i dati prelevati dalle sorgenti previste. In sostanza il Prometheus server non necessita di uno strato di storage distribuito, rendendolo intrinsecamente più semplice di altre soluzioni e tendenzialmente più affidabile (KISS).

Configurazione e Service discovery

La configurazione Prometheus è tipicamente indicata in un file YAML Nella configurazione del Prometheus Server è contenuto l’elenco dei dispositivi sottoposti a monitoraggio, tuttavia gli elementi da sottoporre a a misurazione possono anche essere rilevati in modo automatico, per mezzo dei più diffusi sistemi di “service discovery” (consul, Kubernentes, DNS, …).

In questo modo è possibile ad esempio monitorare un’applicazione a microservizi distribuita in cloud in modo coordinato. Grazie anche a questi elementi Prometheus è particolarmente appropriato con l’utilizzo di metodologie DevOps: si possono così applicare in automatico le etichette ai servizi sotto misurazione.

Lettura delle metriche

Il modello di acquisizione dei dati previsto dal Prometheus è quello definito come “pull model”, ossia che il sistema di rilevazione in modo ciclico preleva i dati dai singoli “Job Exporter” mediante HTTP, con un formato chiave valore estremamente semplice.

Sempre più software - alcuni dei quali molto conosciuti - espongono nativamente o con piccole aggiunte le proprie metriche con il Protocollo Prometheus. In questo modo i nodi Prometheus incaricati di collezionarle possono prelevarle direttamente senza ulteriori elaborazioni. Tra questi ad esempio si possono annoverare:

• Etcd
• Kubernetes
• Docker Daemon
• Collectd
• Netdata

Nei casi in cui non sia presente questa possibilità, ci sono dei Job Exporter specifici, che determinano le metriche da altri sistemi, esponendole poi con il Protocollo Prometheus.

Tra questi si possono evidenziare:

• Node Exporter che fornisce i dati (CPU, Memoria, I/O, Network…) di un qualasi server Linux.
• Blackbox Exporter che fornisce dati (tempi di risposta, stati, ping…) interrogando opportunamente servizi esterni. Così ad esempio è possibile sapere se è raggiungibile un determinato servizio, oppure se risponde correttamente con il protocollo HTTP …
• HAProxy Exporter che fornisce i dati di utilizzo di un servizio HAProxy.
• JMX Exporter che fornisce le metriche delle JVM via JMX.
• SNMP Exporter che fornisce le metriche prelevando i dati da un servizio SNMP.

Ma per un elenco più aggiornato e dettagliato rimando alla sezione Exporter nella documentazione ufficiale.

Infine non manca comunque il supporto alla modalità push con un apposito Push Gateway, utile in caso si voglia sottoporre a misurazione apparati che non supportano nativamente il modello “pull” adottato da Prometheus. Questa modalità è tipicamente necessaria quando i dati da misurare sono generati e quindi presenti solo in determinati eventi.

Panoramica dei servizi

L’architettura Prometheus è suddivisa in servizi che si occupano di un singolo aspetto. Eccone una panoramica:

• il server Promethues che si occupa di acquisire i dati, memorizzare le timeseries e rispondere alle interrogazioni esterne via PromQL
• i Job Exporter che si appoggiano ai layer dei singoli nodi sottosti a misura che offrono i dati (chiave/valore)
• i Job Exporter specifici per la conversione dei dati di monitoraggio acquisiti con altri formati (StatsD, Graphite, SNMP…)
• i push gateway per supportare il modello “push”, già citato.
• gli alertmanager per gestire l’allarmistica, con funzioni quali “escalation”, filtraggio, deduplica in caso di servizi di alertmanager multipli, supporto di molteplici tipologie di segnalazione (email, sms, i più comuni sistemi di chat, …)
• Grafana per la generazione delle dashboard e dei grafici correlati.

Deploy della soluzione Prometheus

Tutti i componenti Prometheus sono disponibili come immagini Docker molto snelle: sono tutti scritti in Go e senza fronzoli, from scratch. La scalabilità della soluzione Prometheus può essere ottenuta federando i nodi Prometheus, tipicamente suddividendo il lavoro per Datacenter o di tipologia del servizio monitorato. In caso di carico estremamente elevato è anche possibile implementare una suddivisione in più nodi paralleli (sharding).

L’alta affidabilità del servizio Prometheus si ottiene realizzando delle copie indipendenti dei vari nodi che possono autonomamente collezzionare i dati e rispondere alle interrogazioni.