Monitoring stack minimo ma serio: cosa mettere per vedere i problemi prima

Molte agenzie dicono di avere monitoring. Poi guardi meglio e scopri che hanno un solo controllo HTTP, un alert via mail che arriva tardi e zero log aggregati. Questo non è monitoring operativo. È un modo lento per scoprire che il cliente ha già aperto il ticket.

Uno stack minimo ma serio non deve essere enorme. Deve dirti tre cose:

• cosa sta degradando
• quando è iniziato
• chi deve muoversi e con quale priorità

Se oggi rincorri solo emergenze, abbina questa guida a Server down: cosa fare nei primi 60 minuti e a Incident response: guida operativa per la prima ora. Se vuoi un servizio continuativo, la pagina giusta è Monitoring.

TL;DR

Il minimo sindacale per un'infrastruttura web gestita è:

• metriche host e servizi
• log centralizzati
• alerting con severità
• controllo esterno HTTP/SSL/DNS
• dashboard leggibili
• ownership chiara degli alert

Senza questi sei cieco. Con questi inizi a essere operativo.

Cosa devi monitorare davvero

1. Host

• CPU
• load average
• RAM e swap
• disco e inode
• I/O wait
• riavvii inattesi

2. Servizi

• Nginx o Apache
• MySQL o MariaDB
• Redis
• PHP-FPM
• cron e queue workers

3. Sintomo esterno

• HTTP 200/500
• tempo di risposta
• certificato SSL in scadenza
• DNS risolto correttamente

4. Log

• error log web server
• log applicativi
• auth log
• slow log MySQL
• kernel e systemd journal

Stack minimo consigliato

Prometheus

Raccoglie metriche time series.

Grafana

Visualizza dashboard e aiuta la diagnosi.

Loki

Centralizza i log senza trasformarli in un progetto ingestibile.

Alertmanager

Instrada gli alert con severità e routing.

Uptime esterno

Un controllo esterno indipendente per HTTP, SSL e DNS.

Questo set è già sufficiente per il 90% dei casi di piccole e medie web agency.

Da dove partire: node exporter

Su ogni host Linux metti almeno node_exporter.

useradd --no-create-home --shell /usr/sbin/nologin node_exporter
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz
tar xzf node_exporter-1.8.0.linux-amd64.tar.gz
cp node_exporter-1.8.0.linux-amd64/node_exporter /usr/local/bin/

Service systemd minimale:

[Unit]
Description=Prometheus Node Exporter
After=network.target

[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target

Poi:

systemctl enable --now node_exporter
curl -s http://127.0.0.1:9100/metrics | head

Se non hai questa base, tutto il resto è cosmetica.

Metriche che devono avere alert

Non tutto deve svegliarti. Alcune cose sì.

P1

• host non raggiungibile
• HTTP down su sito critico
• MySQL non risponde
• disco oltre 95% con crescita attiva

P2

• RAM molto alta con swap in uso
• PHP-FPM in saturazione
• SSL in scadenza ravvicinata
• backup fallito

P3

• load anomalo ma servizio up
• crescita lenta di errori 5xx
• errori cron non bloccanti

Esempi di alert utili

groups:
  - name: host
    rules:
      - alert: HostDown
        expr: up == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Host non raggiungibile"

      - alert: DiskAlmostFull
        expr: (node_filesystem_avail_bytes{fstype!="tmpfs"} / node_filesystem_size_bytes{fstype!="tmpfs"}) < 0.08
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Spazio disco residuo sotto 8%"

L'obiettivo non è avere cento alert. È avere pochi alert che meritano davvero attenzione.

Dashboard minime da costruire

Dashboard host

• CPU
• load
• RAM
• swap
• disco
• rete

Dashboard web

• response time
• status code
• richieste per secondo
• errori 5xx
• processi PHP-FPM attivi

Dashboard database

• connessioni
• query lente
• cache hit ratio
• I/O
• replica, se presente

Se una dashboard non aiuta una decisione, non serve.

Loki: perché i log cambiano il gioco

Le metriche ti dicono che c'è un problema. I log ti dicono spesso quale.

Con Loki puoi fare query tipo:

• tutti i 500 di un vhost negli ultimi 15 minuti
• tutti i PHP Fatal error
• tentativi SSH falliti
• slow query log in crescita

Esempio di promtail base:

server:
  http_listen_port: 9080

positions:
  filename: /var/lib/promtail/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: system
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          __path__: /var/log/*.log

Per chi fa incident response, avere log centralizzati prima del problema fa una differenza enorme. Dopo è tardi.

Alert routing: il punto che quasi tutti sbagliano

Un alert senza owner è rumore.

Devi definire:

• dove va il P1
• dove va il P2
• chi vede i warning
• chi può silenziare
• chi scrive il post-mortem

Se usi email per tutto, nessuno legge niente. Almeno:

• P1 su canale immediato
• P2 su canale operativo
• P3 in digest o dashboard review

Errori frequenti

1. Alert su tutto

Risultato: alert fatigue.

2. Dashboard belle ma inutili

Grafici spettacolari, zero utilità operativa.

3. Nessun controllo esterno

Il server “sembra sano” dall'interno ma il sito da fuori è giù.

4. Nessun alert su backup

Scopri il fallimento solo quando devi ripristinare.

5. Nessuna correlazione tra metriche e log

Sai che CPU è alta, ma non sai perché.

Stack minimo per tipologia

WordPress singolo o pochi siti

• node_exporter
• uptime esterno
• alert su disco, RAM, HTTP, SSL

VPS con più siti clienti

• Prometheus
• Grafana
• Loki
• alert routing serio
• dashboard PHP-FPM e MySQL

E-commerce o ambienti sensibili

• tutto il precedente
• alert su checkout o endpoint critici
• backup monitoring
• test esterni frequenti

Quando questa guida non basta

Questa guida basta per impostare un monitoring utile. Non basta se:

• hai più team o più livelli di supporto
• hai ambienti multi-server o cluster
• vuoi SLO formali e reporting avanzato
• devi integrare incident response strutturata
• hai compliance che richiede retention log specifica

In quel caso serve un progetto di observability vero. Parti da Monitoring o da un audit gratuito per capire da dove iniziare senza costruire un mostro ingestibile.

Checklist finale

• metriche host attive
• servizi principali osservati
• log centralizzati
• alert con severità
• controllo esterno HTTP/SSL/DNS
• dashboard operative
• owner definito per i P1
• backup e cron inclusi nel monitoring

Il monitoring buono non serve a produrre grafici. Serve a vedere il problema prima del cliente, e a capire in pochi minuti dove guardare.