Come funziona Prometheus

Collezione di Metriche :

Quste metriche vengono registrate nel database.

LogoExporters and integrations | Prometheusprometheus.io

Using client libraries you can expose / metrics endpoint

Pull mechanism

Il "Pull Mechanism" (meccanismo di estrazione o "pull") è il modello fondamentale di raccolta dati utilizzato dal server Prometheus. In questo modello, è il server di monitoraggio (Prometheus) che inizia la comunicazione, contattando periodicamente i target per estrarre le metriche.

1. Funzionamento del Meccanismo Pull

Prometheus ribalta il modello di monitoraggio tradizionale basato sul "push" (dove i server inviano i dati a un collettore centrale).

  1. Server (Target) in Attesa: I sistemi che si desidera monitorare (server, database, applicazioni) non inviano attivamente dati. Invece, espongono le loro metriche su un endpoint HTTP specifico (solitamente /metrics) tramite un Exporter o strumentazione integrata. Questi target sono in uno stato passivo in attesa di una richiesta.

  2. Scraping di Prometheus: Il server Prometheus legge il suo file di configurazione (prometheus.yml) che contiene una lista di target (server, indirizzo IP, porta) e intervalli di tempo (scrape interval).

  3. Richiesta HTTP: Ad ogni intervallo, Prometheus invia una richiesta HTTP (un'"estrazione" o scrape) a ciascun endpoint /metrics di ogni target.

  4. Risposta del Target: L'Exporter (o l'applicazione) risponde a questa richiesta inviando un payload di testo contenente tutte le metriche nel formato OpenMetrics.

  5. Archiviazione: Prometheus riceve il payload, lo analizza, lo etichetta con metadati (come il nome del job e l'istanza) e lo salva nel suo Time Series Database (TSDB).

2. Vantaggi del Meccanismo Pull

Il modello pull di Prometheus offre diversi vantaggi chiave rispetto ai modelli push:

  • Identificazione del Target: È Prometheus che sa quali target devono essere monitorati. Se un target scompare o smette di funzionare, Prometheus smette di ricevere i dati e lo marca immediatamente come Down, facilitando l'allertamento sulla disponibilità del servizio.

  • Riduzione del Carico sul Target: L'estrazione delle metriche è un'operazione leggera, che avviene su richiesta di Prometheus, evitando che i target siano costretti a gestire la logica di invio dati.

  • Semplificazione della Configurazione: La configurazione di quali metriche raccogliere avviene centralmente sul server Prometheus, non su centinaia di agenti distribuiti.

  • Service Discovery: Il meccanismo pull si integra perfettamente con i sistemi di Service Discovery (come Kubernetes o Consul). Prometheus interroga il sistema di discovery per scoprire nuovi target ed estrarre immediatamente le metriche, senza che i nuovi target debbano essere configurati per "registrarsi" o "spingere" dati.

3. Quando si Utilizza il Push (Pushgateway)

Nonostante la preferenza per il modello pull, esistono alcune eccezioni in cui è necessario utilizzare un meccanismo push:

  • Job a Vita Breve: Per i job batch che non esistono abbastanza a lungo da essere interrogati da Prometheus (ad esempio, uno script che dura 5 secondi), è necessario utilizzare il Pushgateway.

  • Pushgateway: È un servizio intermediario che accetta le metriche dai job a vita breve (push) e le espone a sua volta a Prometheus in formato pull. In questo modo, Prometheus mantiene il suo modello pull centrale.

Se fosse il contrario ovvero che i microservizi inviano il dato al server centrale si andrebbe A CREARE TANTISSIMO TRAFFICO MAGARI DIFFICILE DA GESTIRE

Il Pushgateway è un componente software separato e opzionale nello stack di monitoraggio di Prometheus. Non è un Exporter e non sostituisce il meccanismo principale di pull.

Il Pushgateway è il modo in cui Prometheus gestisce i job che non possono attendere il prossimo scrape. È la principale eccezione alla filosofia pull.

1. Il Problema che Risolve: Job a Vita Breve

Prometheus è progettato per funzionare con il modello pull: si aspetta che i target siano sempre disponibili per rispondere a una richiesta HTTP periodica (scrape).

Tuttavia, alcuni tipi di carichi di lavoro non sono adatti a questo modello:

  • Job Batch: Script che vengono eseguiti e terminano rapidamente (ad esempio, uno script di backup notturno che dura solo 30 secondi).

  • Funzioni Serverless/Lambda: Funzioni che si avviano, fanno il loro lavoro e si spengono immediatamente.

  • Macchine non Affidabili: Host che potrebbero non essere sempre raggiungibili da Prometheus.

Se Prometheus provasse a fare lo scrape di un job batch, questo potrebbe essere già terminato e risulterebbe erroneamente "Down".

Il Pushgateway è la soluzione a questo problema.

2. Come Funziona il Pushgateway

Il Pushgateway agisce come un intermediario (cache) che permette a Prometheus di mantenere il suo meccanismo pull, anche per i job che non durano a lungo:

  1. Job in Esecuzione (Push): Il job a vita breve (ad esempio, lo script di backup) viene eseguito. Alla fine dell'esecuzione, invia attivamente (push) le sue metriche al Pushgateway tramite una semplice richiesta HTTP.

  2. Pushgateway (Cache): Il Pushgateway riceve queste metriche e le conserva nella sua memoria.

  3. Prometheus (Pull): Il server Prometheus è configurato per fare lo scrape periodico (pull) del Pushgateway stesso, esattamente come farebbe con qualsiasi Exporter.

  4. Recupero: Quando Prometheus interroga il Pushgateway, riceve le metriche precedentemente inviate dal job batch.

In questo modo, Prometheus vede il Pushgateway come un bersaglio affidabile e sempre disponibile, anche se il job originale è scomparso.

3. Differenze Chiave con gli Exporter 🆚

È fondamentale non confondere il Pushgateway con un Exporter standard:

Caratteristica
Exporter Standard (es. Node Exporter)
Pushgateway

Modello

Pull (risponde alla richiesta di Prometheus).

Accetta Push da job, espone metriche in Pull per Prometheus.

Dove Risiede

Sul target che espone le metriche (es. server Ubuntu).

Su un server separato e centrale.

Dati Esposti

Dati live sullo stato attuale del target.

Dati stati dell'ultima esecuzione di un job a vita breve.

Quando Pulire

Non è necessario (le metriche sono sempre aggiornate).

È necessario cancellare manualmente le metriche obsolete per evitare di monitorare dati non aggiornati.

Configuring Prometheus

Un esempio di configurazione di Prometheus si basa principalmente sulla modifica del file prometheus.yml.

Questo file definisce le impostazioni globali, gli intervalli di tempo e, soprattutto, quali servizi o Exporter Prometheus deve interrogare (fare lo scrape).

Esempio di File prometheus.yml

Ecco un esempio di un tipico file di configurazione, che include il monitoraggio di sé stesso (Prometheus) e di un server Linux tramite il Node Exporter.

YAML

# 1. Impostazioni globali
global:
  # Intervallo predefinito con cui Prometheus esegue lo scrape dei target.
  scrape_interval: 15s 
  # Intervallo predefinito per la valutazione delle regole di alert.
  evaluation_interval: 15s

# 2. Configurazione di Alertmanager (se usato)
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # L'indirizzo e la porta dell'istanza di Alertmanager
      - localhost:9093 

# 3. Configurazione dei job di scraping
scrape_configs:
  # Job 1: Monitoraggio di Prometheus stesso (default)
  # Questo è utile per monitorare la salute e le prestazioni del server Prometheus.
  - job_name: 'prometheus'
    # Configurazione statica dei target da interrogare
    static_configs:
      - targets: ['localhost:9090'] # Indirizzo e porta predefinita di Prometheus

  # Job 2: Monitoraggio di un server Linux tramite Node Exporter
  - job_name: 'node_exporter'
    # Etichette (labels) aggiuntive per tutti i target in questo job.
    # Utile per organizzare e filtrare le metriche in Grafana.
    metrics_path: /metrics
    static_configs:
      - targets: ['192.168.1.10:9100'] # Indirizzo IP e porta del primo server Ubuntu
        labels:
          server_name: 'server-produzione-01'
      - targets: ['192.168.1.11:9100'] # Indirizzo IP e porta del secondo server Ubuntu
        labels:
          server_name: 'server-sviluppo-02'

  # Job 3: Monitoraggio di un database MySQL
  - job_name: 'mysql'
    static_configs:
      - targets: ['db-server-01:9104'] # Porta predefinita per MySQL Exporter

Spiegazione delle Sezioni Principali

1. global

Questa sezione definisce i parametri che si applicano a tutti i job di scraping, a meno che non vengano sovrascritti a livello di job:

  • scrape_interval: Definisce ogni quanto tempo Prometheus deve interrogare (estrarre i dati) dai target.

  • evaluation_interval: Definisce ogni quanto tempo Prometheus deve eseguire le sue regole di allerta per vedere se deve innescare un allarme.

2. alerting

Questa sezione configura la connessione con l'Alertmanager, il componente che gestisce e invia le notifiche di allerta (email, Slack, PagerDuty).

  • alertmanagers: Elenca gli indirizzi e le porte su cui è in ascolto l'Alertmanager.

3. scrape_configs (I Job)

Questa è la sezione più importante, dove si definisce quali servizi monitorare. Ogni elemento in questa lista è chiamato job.

  • job_name: Un nome univoco per il set di metriche raccolte (es. node_exporter, mysql). Questo nome viene aggiunto a tutte le serie temporali come etichetta job.

  • static_configs: Il modo più semplice per definire i target. Utilizza una lista fissa di indirizzi.

    • targets: Una lista di indirizzo_ip:porta che Prometheus deve interrogare.

    • labels: Coppie chiave-valore che vengono aggiunte come etichette a tutte le metriche provenienti da quel target specifico. Questo è fondamentale per filtrare e interrogare i dati in PromQL (il linguaggio di query di Prometheus).

Prometheus (Rileva il problema)→Alertmanager (Gestisce, Raggruppa e Instrada)→Receiver (Invia la notifica)

L'Alertmanager è un componente cruciale e separato nello stack di monitoraggio di Prometheus. Il suo compito principale è gestire e inviare le notifiche di allerta.

Mentre Prometheus è responsabile di identificare un problema (es. la CPU è troppo alta), l'Alertmanager è responsabile di decidere cosa fare riguardo a quel problema e notificare le persone giuste nel modo giusto.

Funzionamento e Ruolo dell'Alertmanager

L'Alertmanager agisce come un gestore centralizzato per tutti gli avvisi generati da uno o più server Prometheus.

  1. Ricezione degli Avvisi: Il server Prometheus, quando rileva che una regola di allerta è stata violata (ad esempio, il disco di un server è pieno all'85%), invia un Alert all'Alertmanager.

  2. Elaborazione (Processing): L'Alertmanager riceve l'avviso e lo elabora attraverso quattro fasi principali basate sulla sua configurazione (alertmanager.yml):

Fase
Descrizione

Grouping (Raggruppamento)

Raggruppa avvisi simili o correlati in una singola notifica. Ad esempio, se 20 server sono scesi contemporaneamente a causa di un blackout di rete, Alertmanager invia una sola notifica riassuntiva.

Inhibition (Inibizione)

Sopprime le notifiche per problemi di basso livello se un problema di alto livello è già attivo. Ad esempio, se l'intero server è "DOWN", l'Alertmanager inibisce le notifiche su "Disco Pieno" o "CPU Alta" su quel server, perché il problema principale è già noto.

Silencing (Silenzio)

Permette agli operatori di "mettere a tacere" temporaneamente gli avvisi (ad esempio, per 2 ore) quando si sa che un problema è in corso a causa di manutenzione o è già sotto indagine.

Routing (Instradamento)

Determina dove e come inviare la notifica in base alle etichette (labels) dell'avviso.

  1. Invio delle Notifiche: L'Alertmanager invia la notifica attraverso i Receiver configurati, scegliendo il canale di comunicazione appropriato.

Configurazione: Routing e Receiver

La configurazione dell'Alertmanager (alertmanager.yml) definisce le politiche di instradamento.

1. Receiver (Destinatari)

I Receiver definiscono il canale specifico (il "dove") e le credenziali per inviare l'avviso.

Esempi di Receiver:

  • Email: Invio a un indirizzo email specifico.

  • Slack/Teams: Invio a un canale di chat aziendale.

  • PagerDuty/Opsgenie: Invio a servizi di gestione degli incidenti.

2. Routing Tree (Albero di Instradamento)

L'Alertmanager utilizza un albero di instradamento (Routing Tree) per decidere quale Receiver utilizzare in base alle etichette dell'avviso.

Esempio di Regola di Routing:

  • Avviso: Qualsiasi avviso.

    • Se l'etichetta severity è critical: Invia a PagerDuty e Slack.

    • Se l'etichetta service è database: Invia solo al team dei DBA via email.

    • Altrimenti (Default): Invia solo al canale Slack generale "Monitoraggio".

Questa struttura assicura che gli avvisi ad alta priorità bypassino i canali a bassa priorità e che le notifiche arrivino solo alle persone responsabili del servizio interessato.

PROMETHEUS DATA STORAGE

I dati sono in formato CUSTOM Time Series Format

PromQL Query Language

Prometheus e Grafana sono due strumenti open source molto usati per il monitoraggio e la visualizzazione dei dati in infrastrutture IT, applicazioni e sistemi cloud. Lavorano spesso insieme, ma hanno ruoli diversi e complementari.

Prometheus – Monitoraggio e raccolta dati

Prometheus è un sistema di monitoring e time-series database sviluppato da SoundCloud e poi adottato dalla Cloud Native Computing Foundation (CNCF).

A cosa serve

  • Raccoglie metriche (CPU, memoria, traffico di rete, errori, latenza, ecc.) da server, container, applicazioni o servizi.

  • Memorizza le metriche nel tempo (serie temporali).

  • Permette di fare query sulle metriche con il linguaggio PromQL.

  • Genera alert automatici quando certe soglie vengono superate (tramite l’Alertmanager).

Esempi di metriche

  • node_cpu_seconds_total → uso della CPU

  • http_requests_total → numero di richieste HTTP

  • memory_usage_bytes → memoria usata

Grafana – Visualizzazione e dashboard

Grafana è una piattaforma per visualizzare dati provenienti da varie fonti, tra cui Prometheus, ma anche MySQL, Elasticsearch, InfluxDB, ecc.

A cosa serve

  • Crea dashboard grafiche con grafici, gauge, mappe e tabelle.

  • Permette di monitorare in tempo reale le metriche raccolte da Prometheus.

  • Consente di impostare alert visivi o notifiche basati su soglie definite.

Esempio

Grafana può mostrare:

  • l’andamento dell’utilizzo della CPU su un cluster Kubernetes,

  • la latenza media di un’API,

  • il numero di utenti connessi a un’app in tempo reale.

Insieme: Prometheus + Grafana

  • Prometheus raccoglie e archivia i dati (monitoraggio).

  • Grafana li legge da Prometheus e li presenta in modo visivo (dashboard).

Schema semplificato:

[Server / App / Container] → [Prometheus] → [Grafana] → [Dashboard & Alert]
Strumento
Funzione principale
Tipo di dati
Ruolo

Prometheus

Raccolta e archiviazione delle metriche

Serie temporali

Monitoring

Grafana

Visualizzazione e analisi

Dati da Prometheus (o altri)

Dashboard & Alert

PreviousWhat is Prometheus ?NextIntroduzione a Google Colaboratory

Last updated