Monitoraggio IT proattivo per PMI: da alert reattivi a SLO-based alerting con Prometheus e Grafana

In un progetto per un'azienda del settore e-commerce, il "monitoraggio" consisteva in un cron job che ogni 5 minuti faceva curl sulla homepage e inviava un'email se riceveva un HTTP 500. Quando il database ha iniziato a rallentare - query da 200ms salite a 3 secondi in 48 ore per un indice mancante - nessun alert è scattato perché la homepage continuava a rispondere con HTTP 200. Gli utenti hanno segnalato i problemi prima del team tecnico. Il Google SRE Book distingue tra monitoraggio basato su sintomi ("il servizio è lento per gli utenti") e basato su cause ("la CPU è al 90%"): il primo rileva problemi che impattano gli utenti, il secondo genera rumore senza contesto. Il monitoraggio proattivo parte dai sintomi e dagli SLO, non dagli alert sulla CPU.

Cos'è il monitoraggio proattivo e perché il metodo RED/USE è il framework di riferimento?

Il monitoraggio proattivo significa misurare continuamente il comportamento dei servizi e dell'infrastruttura per rilevare degradazioni prima che diventino incidenti. La differenza con il monitoraggio reattivo è strutturale: il reattivo rileva che un servizio è caduto, il proattivo rileva che il tasso di errore sta salendo e il budget di errore si sta consumando - dando tempo per intervenire. Il report ITIC 2024 Global Server Hardware and Server OS Reliability Survey stima che oltre il 90% delle medie e grandi imprese subisce costi superiori a $300.000 per ogni ora di downtime, mentre per le PMI l'intervallo è $8.000-$25.000/ora - cifre che rendono il monitoraggio proattivo un investimento con ROI misurabile.

Due framework complementari definiscono cosa monitorare. Il metodo RED (Tom Wilkie, 2018) si applica ai servizi: Rate (richieste al secondo), Errors (richieste fallite), Duration (latenza). Il metodo USE (Brendan Gregg) si applica all'infrastruttura: Utilization (percentuale di utilizzo della risorsa), Saturation (lavoro in coda), Errors (eventi di errore hardware/software). Google li sintetizza nei quattro golden signals del Site Reliability Engineering: Latency, Traffic, Errors, Saturation. Per un applicativo PHP su server LEMP, RED copre Nginx e PHP-FPM (request rate, 5xx rate, response time), USE copre CPU, memoria, disco e connessioni MySQL.

Il concetto di SLO (Service Level Objective) trasforma il monitoraggio da "la metrica ha superato una soglia" a "il servizio sta rispettando il livello di qualità promesso". Un SLO del 99.9% di disponibilità corrisponde a 43.2 minuti di downtime ammessi al mese - l'error budget. Quando il budget consumato supera una soglia (tipicamente il 75%), l'alert scatta prima che l'SLO venga violato. Il DORA Report 2024 conferma che i team con SLO definiti hanno un change failure rate significativamente inferiore e un recovery time più rapido.

Come implementare il monitoraggio con Prometheus e Grafana in un'infrastruttura PHP?

Prometheus, progetto CNCF graduated (agosto 2018), è il sistema di monitoraggio time-series standard per infrastrutture moderne. Il CNCF Annual Survey 2023 riporta un'adozione tra il 67% e l'86% tra le organizzazioni cloud-native. Prometheus raccoglie metriche via pull (scrape HTTP su endpoint /metrics), le archivia in un database time-series locale e valuta regole di alerting. Grafana fornisce la visualizzazione. Per un'infrastruttura PHP/LEMP, gli exporter necessari sono node_exporter (metriche sistema), mysqld_exporter (metriche MySQL) e php-fpm_exporter (metriche PHP-FPM). Nginx espone metriche native via il modulo stub_status:

## prometheus.yml - Configurazione scrape per stack LEMP
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alerts/*.yml"

scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["server-prod:9100"]
        labels:
          env: "production"

  - job_name: "mysqld"
    static_configs:
      - targets: ["server-prod:9104"]

  - job_name: "php-fpm"
    static_configs:
      - targets: ["server-prod:9253"]

  - job_name: "nginx"
    static_configs:
      - targets: ["server-prod:9113"]

## alerts/slo-lemp.yml - Alert basati su SLO e metodo RED/USE
groups:
  - name: slo_alerts
    rules:
      ## RED: tasso di slow request PHP-FPM sopra soglia SLO
      - alert: HighSlowRequestRate
        expr: |
          rate(phpfpm_accepted_connections_total[5m]) > 0
          and
          rate(phpfpm_slow_requests_total[5m])
            / rate(phpfpm_accepted_connections_total[5m]) > 0.01
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Tasso slow request PHP-FPM >1% (SLO: <0.1%)"

      ## RED: latenza - coda PHP-FPM satura
      - alert: PHPFPMQueueSaturation
        expr: phpfpm_listen_queue > phpfpm_listen_queue_max * 0.7
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Coda PHP-FPM al 70% della capacità"

      ## USE: saturazione disco
      - alert: DiskSpaceLow
        expr: |
          (node_filesystem_avail_bytes{mountpoint="/"}
            / node_filesystem_size_bytes{mountpoint="/"}) < 0.15
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Spazio disco root sotto il 15%"

      ## USE: saturazione connessioni MySQL
      - alert: MySQLConnectionsHigh
        expr: |
          mysql_global_status_threads_connected
            / mysql_global_variables_max_connections > 0.8
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Connessioni MySQL all'80% del massimo"

Le regole di alerting da sole non bastano - serve un Alertmanager configurato per il routing delle notifiche. La separazione tra regole (Prometheus) e notifiche (Alertmanager) è intenzionale: Prometheus valuta le condizioni, Alertmanager gestisce deduplicazione, raggruppamento, silenziamento e instradamento verso i canali appropriati (Slack, email, PagerDuty, webhook). Un alert critical va al canale on-call immediato, un warning va al canale del team per la revisione nel prossimo orario lavorativo. Senza questa separazione, il team riceve lo stesso alert su 5 canali contemporaneamente - il percorso diretto verso l'alert fatigue. La retention di default di Prometheus è 15 giorni - sufficiente per il troubleshooting immediato, ma per analisi di trend e capacity planning a lungo termine serve un backend remoto come Thanos o VictoriaMetrics.

Per applicativi Laravel, Pulse (introdotto in Laravel 11) fornisce monitoraggio aggregato in produzione: slow queries, slow requests, utilizzo cache, job in coda, eccezioni. Telescope è lo strumento di debug per sviluppo (non adatto alla produzione per l'overhead di storage). Horizon monitora le code Redis con metriche di throughput e latenza. I tre strumenti sono complementari a Prometheus: Pulse e Horizon monitorano il livello applicativo (business metrics), Prometheus monitora l'infrastruttura e le metriche RED cross-service.

Errori comuni nell'adozione del monitoraggio IT

Il primo errore è l'alert fatigue. Un sistema di monitoraggio che invia 50 alert al giorno rende il team insensibile alle notifiche - il Google SRE Book raccomanda un massimo di 2 incidenti per turno di 12 ore. Ogni alert deve essere actionable (richiede un'azione umana), urgente (non può aspettare il giorno dopo) e basato su sintomi (impatto utente), non su cause (CPU al 70% senza degradazione del servizio).

Il secondo è monitorare l'infrastruttura senza definire SLO. Senza un error budget, ogni spike di latenza genera un alert, e il team non sa distinguere un'oscillazione normale da una degradazione reale. La definizione di SLO parte dai requisiti di business: un gestionale interno può tollerare 99.5% di disponibilità (3.65 ore/mese di downtime), un e-commerce in peak season richiede 99.95% (21.9 minuti/mese).

Il terzo è monitorare solo l'infrastruttura ignorando il livello applicativo. CPU e RAM normali non significano che l'applicazione funzioni: una query N+1 introdotta nell'ultimo deploy può moltiplicare i tempi di risposta da 50ms a 2 secondi senza variazioni significative nelle metriche di sistema. Le metriche RED (error rate, latenza P95/P99) catturano queste degradazioni. L'osservabilità applicativa con logging strutturato completa il quadro fornendo il contesto per diagnosticare i problemi rilevati dalle metriche.

Il quarto è non testare le regole di alerting. Una regola Prometheus non validata può non scattare mai (soglia troppo alta), scattare continuamente (soglia troppo bassa) o non raggiungere il canale di notifica (Alertmanager mal configurato). La pratica di "fire drill" - simulare un incidente per verificare che la catena alert→notifica→escalation funzioni - è raccomandata dal Google SRE Book ed è parte integrante di un piano di Disaster Recovery efficace.

Il monitoraggio proattivo trasforma il team da pompiere (reagire agli incidenti) a ingegnere dell'affidabilità (prevenire gli incidenti). L'Infrastructure as Code garantisce che la configurazione di Prometheus, exporter e alerting sia versionata e ripetibile su ogni ambiente - lo stesso principio di automazione che elimina i snowflake server si applica alla configurazione del monitoraggio. Per conoscere il mio approccio al monitoraggio infrastrutturale per applicativi PHP, visita la mia pagina professionale. Se il tuo "monitoraggio" è un cron job che fa curl sulla homepage, contattami per una consulenza dedicata - partiamo dall'inventario delle metriche RED/USE e dalla definizione degli SLO per i servizi critici.