m4nifest0-tech

Cerca nel sito

Linux e Windows Server

Monitoraggio dell'infrastruttura con Prometheus e Grafana in un container LXC

Come raccogliere metriche da nodi Linux e Proxmox VE con Prometheus, visualizzarle in Grafana e ricevere avvisi, in un LXC non privilegiato dedicato.
Pubblicato il 8 min di letturaLivello: Intermedio

Un'infrastruttura non monitorata segnala i problemi quando sono già diventati disservizi: un disco pieno, un nodo spento, un backup fermo da giorni. Prometheus e Grafana permettono di raccogliere metriche, visualizzarle e ricevere un avviso prima che il guasto si propaghi. La guida descrive un'installazione di laboratorio su Debian 12 o 13, in un container LXC non privilegiato su Proxmox VE 8 o 9, che osserva nodi Linux, host Proxmox e, volendo, server Windows.

Architettura

I componenti sono quattro, ciascuno con un compito preciso.

  • Prometheus interroga a intervalli regolari i target via HTTP (modello pull), archivia le serie temporali e valuta le regole di alert.
  • Gli exporter sono piccoli servizi che espongono le metriche su un endpoint HTTP: node_exporter per Linux, windows_exporter per Windows, prometheus-pve-exporter per Proxmox VE.
  • Grafana non raccoglie nulla: legge da Prometheus e disegna le dashboard.
  • Alertmanager riceve gli alert generati da Prometheus, li raggruppa e li inoltra ai canali configurati, come email, webhook o chat.
exporter (nodi, Proxmox VE)  ->  Prometheus  ->  Alertmanager  ->  notifiche
                                     ^
                                     |
                                  Grafana

Il container LXC dedicato

Un container separato isola il monitoraggio dai servizi che osserva e si salva, si sposta e si ripristina come un'unità. Il carico è modesto e nessun componente richiede privilegi sull'host, quindi un LXC non privilegiato è la scelta naturale: il root del container non corrisponde al root dell'host, come spiegato in LXC non privilegiati, bind mount e mapping degli UID. Per conservare lo storico delle metriche oltre la vita del container si può destinare un volume dedicato, o un bind mount, alla directory dei dati.

Sul nodo Proxmox
pveam update
pveam available --section system
pveam download local <NOME_TEMPLATE_DEBIAN>
Sul nodo Proxmox
pct create <CTID> local:vztmpl/<NOME_TEMPLATE_DEBIAN> \
  --hostname monitoraggio \
  --unprivileged 1 \
  --cores 2 --memory 2048 \
  --rootfs local-lvm:16 \
  --net0 name=eth0,bridge=vmbr0,ip=192.0.2.20/24,gw=192.0.2.1 \
  --onboot 1
pct start <CTID>

Nota

Nomi dei template e degli storage (local, local-lvm) cambiano da un'installazione all'altra: vanno verificati con pveam available e pvesm status prima di eseguire i comandi. Indirizzi e dimensioni sono solo esempi.

Il container va collocato nella rete di gestione: la segmentazione con VLAN aiuta a lasciare aperte verso gli exporter solo le porte necessarie.

Prometheus e node_exporter dai pacchetti Debian

Nel container, come root
apt update
apt install prometheus prometheus-node-exporter prometheus-alertmanager

I pacchetti Debian si aggiornano insieme al resto del sistema ma seguono la versione della release stabile. Per funzionalità più recenti si possono usare i binari ufficiali, gestendo gli aggiornamenti a mano.

prometheus-node-exporter va installato anche su ogni host Linux da osservare, limitando la porta 9100 al solo indirizzo del container di monitoraggio. I target si dichiarano in scrape_configs.

/etc/prometheus/prometheus.yml
global:
  scrape_interval: 30s
  evaluation_interval: 30s
 
rule_files:
  - /etc/prometheus/rules/*.yml
 
alerting:
  alertmanagers:
    - static_configs:
        - targets: ["localhost:9093"]
 
scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
 
  - job_name: "nodi-linux"
    static_configs:
      - targets:
          - "nodo1.example.com:9100"
          - "nodo2.example.com:9100"
          - "nodo3.example.com:9100"
 
  - job_name: "proxmox"
    metrics_path: /pve
    params:
      module: ["default"]
      cluster: ["1"]
      node: ["1"]
    static_configs:
      - targets:
          - "nodo1.example.com"
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: "127.0.0.1:9221"

Il job proxmox usa il relabeling: i target sono i nodi Proxmox, ma le richieste vanno all'exporter in ascolto in locale, che a sua volta interroga il nodo tramite API. I server Windows, come il controller di dominio del laboratorio Active Directory, si osservano con windows_exporter (porta 9182 per impostazione predefinita) aggiungendo un job analogo a nodi-linux.

La configurazione si controlla prima di applicarla:

Nel container, come root
promtool check config /etc/prometheus/prometheus.yml
systemctl reload prometheus

Exporter per Proxmox VE e minimo privilegio

L'exporter deve leggere lo stato del cluster, non modificarlo. Il principio del minimo privilegio si traduce in tre scelte: un utente dedicato, il ruolo predefinito PVEAuditor (sola lettura) e un token API con permessi separati, revocabile senza toccare nulla d'altro.

Sul nodo Proxmox
pveum user add monitoraggio@pve --comment "Sola lettura per Prometheus"
pveum acl modify / --users monitoraggio@pve --roles PVEAuditor
pveum user token add monitoraggio@pve prometheus --privsep 1
pveum acl modify / --tokens 'monitoraggio@pve!prometheus' --roles PVEAuditor

Importante

Il valore del token viene mostrato una sola volta, alla creazione. Va conservato in un gestore di segreti e scritto soltanto nel file di configurazione dell'exporter, con permessi restrittivi e fuori da qualsiasi repository.

Il pacchetto prometheus-pve-exporter si installa con pip. Su Debian 12 e successive conviene un ambiente virtuale, perché l'installazione a livello di sistema è bloccata:

Nel container, come root
apt install python3-venv
python3 -m venv /opt/pve-exporter
/opt/pve-exporter/bin/pip install prometheus-pve-exporter

L'exporter si avvia con pve_exporter --config.file /etc/prometheus/pve.yml, ascolta sulla porta 9221 e, per un uso stabile, va eseguito come servizio systemd con un utente non privilegiato. Il formato del file di configurazione è descritto nella documentazione del progetto (si apre in una nuova scheda).

Grafana dal repository APT ufficiale

Grafana si installa dal repository apt.grafana.com, verificato con la chiave GPG pubblicata dal progetto. I comandi seguono la documentazione ufficiale al momento della stesura e possono cambiare: prima di eseguirli conviene confrontarli con la guida di installazione per Debian (si apre in una nuova scheda).

Nel container, come root
apt install wget
mkdir -p /etc/apt/keyrings
wget -O /etc/apt/keyrings/grafana.asc https://apt.grafana.com/gpg-full.key
chmod 644 /etc/apt/keyrings/grafana.asc
echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" > /etc/apt/sources.list.d/grafana.list
apt update
apt install grafana
systemctl enable --now grafana-server

Grafana ascolta sulla porta 3000. Al primo accesso la password dell'amministratore predefinito va sostituita. Si aggiunge poi Prometheus come origine dati con indirizzo http://localhost:9090 e si importano dashboard della community per node_exporter e per Proxmox, da adattare alle proprie esigenze.

Regole di alert

Le regole stanno in file separati, caricati tramite rule_files. Due esempi: un target irraggiungibile per cinque minuti e un filesystem oltre una soglia.

/etc/prometheus/rules/base.yml
groups:
  - name: base
    rules:
      - alert: TargetNonRaggiungibile
        expr: up == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} non risponde"
          description: "Il job {{ $labels.job }} non risponde da oltre 5 minuti."
 
      - alert: DiscoQuasiPieno
        expr: |
          1 - node_filesystem_avail_bytes{fstype=~"ext4|xfs|btrfs|zfs"}
            / node_filesystem_size_bytes{fstype=~"ext4|xfs|btrfs|zfs"} > 0.85
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Filesystem {{ $labels.mountpoint }} su {{ $labels.instance }} oltre la soglia"
          description: "Lo spazio occupato supera l'85%. La soglia è indicativa."
Nel container, come root
mkdir -p /etc/prometheus/rules
promtool check rules /etc/prometheus/rules/base.yml
systemctl reload prometheus

I destinatari delle notifiche si definiscono in /etc/prometheus/alertmanager.yml. Le credenziali dei canali (SMTP, webhook, chat) sono segreti come gli altri e restano fuori dal repository.

Cosa monitorare per primo

  • Disponibilità. La metrica up indica se la raccolta riesce: è il primo alert da attivare.
  • Spazio disco. I filesystem pieni sono una causa frequente di guasti. Oltre a node_filesystem_*, l'exporter di Proxmox espone l'occupazione degli storage.
  • SMART. node_exporter non legge i dati SMART in modo nativo: servono un exporter dedicato o uno script per il textfile collector, eseguiti sull'host fisico perché un container non vede i dischi.
  • Temperature. I sensori hwmon sono esposti come node_hwmon_temp_celsius e vanno letti sul nodo fisico.
  • Stato dei backup. Un backup che non parte non produce errori: conviene misurare l'età dell'ultimo backup riuscito e allarmare quando supera l'intervallo atteso. Il contesto è nella strategia di backup 3-2-1 con Proxmox Backup Server.

Attenzione

Prometheus, Alertmanager e gli exporter non prevedono autenticazione per impostazione predefinita e le metriche rivelano la struttura dell'infrastruttura. Nessuno di questi servizi, Grafana compreso, va esposto direttamente a Internet: l'accesso dall'esterno passa da una VPN, per esempio WireGuard, o da un reverse proxy con TLS e autenticazione. Se Prometheus e Grafana condividono il container, Prometheus può ascoltare solo in locale con ARGS="--web.listen-address=127.0.0.1:9090" in /etc/default/prometheus.

Articoli correlati