Un ambiente dinamico, come quello container, necessita di un sistema leggero, performante e interoperabile per il monitoraggio. Il protocollo di esposizione delle metriche/OpenMetrics Prometheus si basa sul sistema Borgmon di Google e proprio per questo motivo risulta la soluzione più diffusa e versatile.
Per rafforzare il suo orientamento opensource nel 2016 la CNCF (Cloud Native Computing Foundation) ha accettato di incubare il progetto, rendendolo di fatto la soluzione preferita in ambito cloud container.
L’esposizione di metriche applicative e di sistema deve inoltre adattarsi a un mondo sempre più opensource e basato sul web. L’approccio “Single http page for all metrics”, adottato da Prometheus, rappresenta il modo semplice ed efficace per rispondere a tale necessità.
Una metrica è basata su una linea testuale così composta:
nome_della_metrica_(unità_di_misura){etichetta1=valore1,etichetta2=valore2,…} valore (timestamp)
Ad esempio:
http_request_count{page=index} 234
net_tx_interface_bytes{ifname=eth0} 123
La cardinalità di una metrica è data dal numero di label ad essa associate. Tutti i linguaggi più noti mettono a disposizione un exporter compatibile. Tra questi troviamo:
- Python: https://github.com/prometheus/client_python
- Golang: https://github.com/prometheus/client_golang
- Java: https://github.com/prometheus/client_java
Ugualmente i framework più utilizzati hanno una libreria specializzata che include tutte le metriche di base necessarie, ad esempio:
- Springboot: https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html
Le principali Features di Prometheus
TimeseriesDB
In risposta ad alti requisiti di performance e al contempo di poco impatto in termini di risorse computazionali, il team di Prometheus ha deciso di utilizzare un formato custom per massimizzare le performance. Ogni blocco di dati residente in una cartella sul filesystem contiene 2 ore di campioni. Ogni blocco, a sua volta, include una serie di “chunk” che sono il partizionamento per le metriche in quella finestra temporale. Il vantaggio di questo formato è che ogni metrica occupa all’incirca 1-2 Byte per singolo campione.
[root@prometheus small]# tree ├── 2020_07 │ ├── 119236896_79269_20200721133611.531_20200721154700.066_1623BA8D67E4C1A3 │ │ ├── index.bin │ │ ├── metaindex.bin │ │ ├── timestamps.bin │ │ └── values.bin │ ├── 146250_76434_20200721162658.025_20200721162722.922_1623BA8D67E4C3BE │ │ ├── index.bin │ │ ├── metaindex.bin │ │ ├── timestamps.bin │ │ └── values.bin
Servizio di raccolta metriche
A completare la suite, il servizio Prometheus si occupa di acquisire le metriche dagli endpoint configurati. Esistono due modi per configurarli: staticamente in un file di configurazione, dinamicamente sfruttando uno dei servizi di discovery supportati (tutti i principali provider cloud lo sono, Kubernetes in primis).
I principali benefici di Prometheus rispetto ad altri approcci di monitoraggio/acquisizione di metriche è la semplicità di raccolta (è l’applicazione/sistema che espone le metriche), senza la necessità di agenti installati sull’endpoint.
Come vedremo successivamente questo approccio è particolarmente efficace in ambito container.
