--- title: "Monitoraggio IT proattivo per PMI: da alert reattivi a SLO-based alerting con Prometheus e Grafana" description: "ITIC 2024: le PMI perdono $8K-$25K/ora di downtime. Monitoraggio proattivo con Prometheus, Grafana e alerting basato su SLO previene gli incidenti prima che impattino gli utenti." canonical: "https://www.mauriziofonte.it/blog/post/monitoraggio-it-proattivo-prevenire-incidenti.html" author: "Maurizio Fonte" date: "2025-05-28T08:11:16+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Sicurezza Informatica" tags: ["Sicurezza Informatica", "DevOps"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) [DevOps](https://www.mauriziofonte.it/blog/cat/devops.html) # [Monitoraggio IT proattivo per PMI: da alert reattivi a SLO-based alerting con Prometheus e Grafana](https://www.mauriziofonte.it/blog/post/monitoraggio-it-proattivo-prevenire-incidenti.html) Mercoledì 28 Mag 2025, alle 08:11 ![Monitoraggio IT proattivo per PMI: da alert reattivi a SLO-based alerting con Prometheus e Grafana](https://www.mauriziofonte.it/image/001480200-monitoraggio-it-proattivo-prevenire-incidenti.jpg) 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](https://sre.google/sre-book/monitoring-distributed-systems/) 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](https://itic-corp.com/itic-2024-global-server-hardware-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](https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/) (Tom Wilkie, 2018) si applica ai servizi: **Rate** (richieste al secondo), **Errors** (richieste fallite), **Duration** (latenza). Il [metodo USE](https://www.brendangregg.com/usemethod.html) (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](https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_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](https://dora.dev/research/2024/dora-report/) 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](https://prometheus.io/docs/introduction/overview/), progetto CNCF graduated (agosto 2018), è il sistema di monitoraggio time-series standard per infrastrutture moderne. Il [CNCF Annual Survey 2023](https://www.cncf.io/reports/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`: ```yaml ## 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](https://laravel.com/docs/12.x/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](https://sre.google/sre-book/monitoring-distributed-systems/) 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](https://www.mauriziofonte.it/blog/post/osservabilita-minima-applicazioni-php-legacy-logging-metriche-alert.html) 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](https://www.mauriziofonte.it/blog/post/piano-disaster-recovery-php-continuita-operativa-pmi.html) efficace. Il monitoraggio proattivo trasforma il team da pompiere (reagire agli incidenti) a ingegnere dell'affidabilità (prevenire gli incidenti). L'[Infrastructure as Code](https://www.mauriziofonte.it/blog/post/infrastructure-as-code-iac-benefici-azienda.html) 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](https://www.mauriziofonte.it/pages/about). Se il tuo "monitoraggio" è un cron job che fa curl sulla homepage, [contattami per una consulenza dedicata](https://www.mauriziofonte.it/pages/contattami) - partiamo dall'inventario delle metriche RED/USE e dalla definizione degli SLO per i servizi critici. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteInfrastructure as Code per PMI: da provisioning manuale a playbook Ansible e moduli Terraform ripetibili27 Mag 2025](https://www.mauriziofonte.it/blog/post/infrastructure-as-code-iac-benefici-azienda.html)[Articolo successivo »Disaster Recovery Plan per PMI: da backup non testati a RPO/RTO verificabili con la regola 3-2-1-1-029 Mag 2025](https://www.mauriziofonte.it/blog/post/disaster-recovery-plan-importanza-azienda.html) ### Articoli correlati a Monitoraggio IT proattivo per PMI: da alert reattivi a SLO-based alerting con Prometheus e Grafana - [Monitoraggio VPS con Prometheus e Grafana: setup minimale per applicazioni PHP](https://www.mauriziofonte.it/blog/post/prometheus-grafana-monitoraggio-vps-applicazioni-php.html) La metà dei downtime che ho gestito nell'ultimo anno erano prevedibili: disco pieno, memoria esaurita, connessioni MySQL saturate. Tutti i segnali · 26 Settembre 2025 ![Monitoraggio VPS con Prometheus e Grafana: setup minimale per applicazioni PHP](https://www.mauriziofonte.it/image/002740070-prometheus-grafana-monitoraggio-vps-applicazioni-php.jpg) - [Monitoring proattivo per Laravel su VPS unmanaged: come evitare di scoprire un downtime dalla telefonata del cliente](https://www.mauriziofonte.it/blog/post/vps-monitoring-laravel-prevenzione-downtime.html) Un VPS Contabo con un e commerce B2B Laravel è rimasto fermo 60 ore dal venerdì pomeriggio al lunedì mattina perché il certificato SSL era scaduto · 30 Giugno 2025 ![Monitoring proattivo per Laravel su VPS unmanaged: come evitare di scoprire un downtime dalla telefonata del cliente](https://www.mauriziofonte.it/image/001890070-vps-monitoring-laravel-prevenzione-downtime.jpg) - [Laravel Pulse: monitoraggio applicativo nativo senza strumenti esterni](https://www.mauriziofonte.it/blog/post/laravel-pulse-monitoraggio-applicativo-nativo-produzione.html) Laravel Pulse è arrivato come alternativa zero config agli stack Prometheus/Grafana. L'ho configurato su tre applicazioni in produzione in 20 · 14 Novembre 2025 ![Laravel Pulse: monitoraggio applicativo nativo senza strumenti esterni](https://www.mauriziofonte.it/image/002410070-laravel-pulse-monitoraggio-applicativo-nativo-produzione.jpg) - [PHP-FPM che crasha sotto carico su VPS: come ho diagnosticato un OOM killer silenzioso su un portale Laravel con 200 utenti concorrenti](https://www.mauriziofonte.it/blog/post/ripristino-crash-php-fpm-laravel-vps.html) Un portale B2B Laravel su VPS OVH andava in 502 Bad Gateway ogni giorno tra le 10 e le 11 del mattino l'ora di punta degli ordini. PHP FPM veniva · 3 Luglio 2025 ![PHP-FPM che crasha sotto carico su VPS: come ho diagnosticato un OOM killer silenzioso su un portale Laravel con 200 utenti concorrenti](https://www.mauriziofonte.it/image/001960070-ripristino-crash-php-fpm-laravel-vps.jpg) - [Dopo l'emergenza, il debito tecnico: come trasformo un server Linux post-subentro in un asset misurabile nei 90 giorni successivi](https://www.mauriziofonte.it/blog/post/gestire-debito-tecnico-server-linux-hetzner-ovh-post-subentro.html) L'emergenza è passata, il sito gira di nuovo, gli accessi sono recuperati. Adesso cominciano i 90 giorni decisivi: o il debito tecnico viene · 10 Giugno 2025 ![Dopo l'emergenza, il debito tecnico: come trasformo un server Linux post-subentro in un asset misurabile nei 90 giorni successivi](https://www.mauriziofonte.it/image/001710070-gestire-debito-tecnico-server-linux-hetzner-ovh-post-subentro.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Monitoraggio IT proattivo per PMI: da alert reattivi a SLO-based alerting con Prometheus e Grafana", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/monitoraggio-it-proattivo-prevenire-incidenti.html Pubblicato: 2025-05-28 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.