--- title: "Monitoring proattivo per Laravel su VPS unmanaged: come evitare di scoprire un downtime dalla telefonata del cliente" description: "Monitoring Laravel su VPS unmanaged con Prometheus, Grafana e Alertmanager: health check, metriche applicative, alerting e runbook. Guida operativa per PMI." canonical: "https://www.mauriziofonte.it/blog/post/vps-monitoring-laravel-prevenzione-downtime.html" author: "Maurizio Fonte" date: "2025-06-30T08:28:11+02:00" modified: "2026-04-14T17:48:55+02:00" section: "VPS & Hosting" tags: ["VPS & Hosting", "Business Continuity"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) # [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) Lunedì 30 Giugno 2025, alle 08:28 ![Monitoring proattivo per Laravel su VPS unmanaged: come evitare di scoprire un downtime dalla telefonata del cliente](https://www.mauriziofonte.it/image/001890200-vps-monitoring-laravel-prevenzione-downtime.jpg) Il 18 luglio 2025, un venerdì alle 16:40, il certificato Let's Encrypt di un e-commerce B2B Laravel ospitato su un VPS Contabo (6 vCPU, 16 GB RAM, 400 GB SSD) è scaduto. Il cron job di Certbot che avrebbe dovuto rinnovarlo automaticamente aveva smesso di funzionare tre mesi prima - il 14 aprile - quando un aggiornamento del sistema operativo aveva spostato il binario di Certbot da `/usr/bin/certbot` a `/snap/bin/certbot` senza aggiornare il crontab. Per tre mesi il rinnovo aveva fallito silenziosamente, scrivendo un errore in `/var/log/letsencrypt/letsencrypt.log` che nessuno leggeva. Il venerdì pomeriggio, alla scadenza del certificato, il sito è diventato irraggiungibile: gli header HSTS (HTTP Strict Transport Security) che l'applicazione inviava correttamente impedivano ai browser di accettare il fallback a HTTP in chiaro. Per l'utente finale il sito era semplicemente morto - nessuna pagina di errore, nessun messaggio, solo un ERR_CERT_DATE_INVALID che Chrome mostrava senza possibilità di bypass. Il cliente - una PMI pugliese che vende componentistica idraulica industriale al mercato europeo, con un fatturato e-commerce di circa 2 milioni di euro - ha scoperto il problema il lunedì mattina alle 8:15, quando il primo commerciale ha provato ad accedere al backoffice per controllare gli ordini del weekend. Sessanta ore di downtime. Nessun alert, nessuna notifica, nessun SMS. Il VPS era tecnicamente online - SSH funzionava, MySQL era attivo, PHP-FPM era in esecuzione. Mancava solo il certificato SSL, e senza di quello il sito era un fantasma. Stima delle perdite: circa 80 ordini non completati nel weekend (basata sulla media storica), equivalenti a circa 35.000 euro di fatturato lordo. Quando sono intervenuto il lunedì mattina, il fix tecnico è stato banale: aggiornare il path di Certbot nel crontab e forzare il rinnovo con `certbot renew --force-renewal`. Quindici minuti di lavoro. Ma il problema vero non era il certificato - era l'assenza totale di un sistema di monitoring che avrebbe potuto segnalare il problema tre mesi prima, quando il cron job aveva iniziato a fallire, o al massimo il venerdì pomeriggio, quando il certificato era scaduto. Questo articolo descrive lo stack di monitoring che ho installato su quel VPS e che da allora installo su ogni server che prendo in carico per clienti PMI. ## Cosa deve monitorare un sistema di monitoring per essere davvero utile su un VPS unmanaged? Un dashboard di Grafana con grafici colorati che nessuno guarda non è monitoring - è decorazione. Il monitoring che previene i downtime ha tre caratteristiche: misura le cose giuste, genera alert quando una soglia viene superata, e ogni alert ha un'azione associata. Se un alert suona e chi lo riceve non sa cosa fare, quell'alert è rumore, non segnale. Lo stack che ha dimostrato nel tempo il miglior rapporto costo/efficacia su VPS unmanaged per PMI è composto da quattro componenti: **Prometheus** per la raccolta e lo storage delle metriche, **Grafana** per la visualizzazione, **Alertmanager** per l'instradamento degli alert, e **Node Exporter** per le metriche del sistema operativo. A livello applicativo, il pacchetto [laravel-prometheus di Spatie](https://spatie.be/docs/laravel-prometheus/v1/introduction) espone metriche custom di Laravel in un formato che Prometheus sa leggere nativamente. Le metriche si dividono in tre livelli, e tutti e tre devono essere coperti: - **Infrastruttura**: CPU, RAM, disco, I/O, network. Node Exporter le espone automaticamente. Il 90% dei downtime evitabili su VPS unmanaged nasce da disco pieno o RAM esaurita. - **Applicazione**: tempo di risposta HTTP, tasso di errori 5xx, profondità della coda Laravel, job falliti, connessioni al database. Queste sono le metriche che ti dicono se l'applicazione sta degradando prima che l'utente se ne accorga. - **Business**: transazioni completate per ora, email transazionali inviate con successo, scadenza dei certificati SSL, freschezza dell'ultimo backup. Queste sono le metriche che il proprietario dell'azienda capisce - e sono quelle che trasformano il monitoring da costo tecnico a investimento di business. Stai cercando un **Consulente Informatico** esperto per mettere in sicurezza e monitorare la tua infrastruttura Laravel? Nel mio [profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su VPS Hetzner, Contabo, OVH e Digital Ocean, monitoring proattivo e incident response per PMI. ## Lo stack in pratica: Prometheus, Node Exporter e metriche Laravel L'installazione di Prometheus e Node Exporter su un VPS Debian/Ubuntu è diretta. Node Exporter gira come servizio systemd sulla porta 9100 ed espone centinaia di metriche del sistema operativo senza nessuna configurazione applicativa. Prometheus viene configurato per interrogare Node Exporter e l'endpoint `/prometheus` dell'applicazione Laravel a intervalli regolari: ```yaml # /etc/prometheus/prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s rule_files: - "/etc/prometheus/rules/*.yml" scrape_configs: - job_name: "node" static_configs: - targets: ["localhost:9100"] - job_name: "laravel" metrics_path: "/prometheus" static_configs: - targets: ["localhost:80"] scheme: "https" tls_config: insecure_skip_verify: true ``` Sul lato Laravel, il pacchetto Spatie espone automaticamente metriche di base (richieste per secondo, tempo di risposta). Le metriche custom più utili che aggiungo su ogni installazione sono il contatore di job falliti in coda, la profondità della coda stessa, e un gauge che misura il tempo dell'ultima transazione completata con successo - perché se l'e-commerce è online ma nessuno riesce a completare un ordine, il monitoring infrastrutturale non ti dice nulla: ```php // app/Providers/PrometheusServiceProvider.php use Spatie\Prometheus\Facades\Prometheus; public function register(): void { Prometheus::addGauge('Profondità coda Laravel') ->name('laravel_queue_depth') ->helpText('Numero di job in attesa nella coda') ->value(fn () => DB::table('jobs')->count()); Prometheus::addGauge('Job falliti') ->name('laravel_failed_jobs_total') ->helpText('Numero totale di job falliti') ->value(fn () => DB::table('failed_jobs')->count()); Prometheus::addGauge('Ultimo ordine completato (secondi fa)') ->name('laravel_last_order_seconds_ago') ->helpText('Secondi trascorsi dall ultimo ordine completato') ->value(function () { $last = DB::table('orders') ->where('status', 'completed') ->max('created_at'); return $last ? now()->diffInSeconds($last) : -1; }); } ``` Per una guida più completa sull'integrazione tra Laravel, Prometheus e Grafana con esempi di dashboard e configurazione avanzata, [Better Stack ha pubblicato una delle guide più dettagliate disponibili](https://betterstack.com/community/guides/monitoring/php-laravel-prometheus/) - la consiglio come riferimento per chi vuole approfondire oltre il setup di base che descrivo qui. ## Le regole di alerting che prevengono i downtime reali Prometheus senza Alertmanager è un archivio storico: utile per l'analisi post-mortem, inutile per la prevenzione. Alertmanager prende le regole definite in Prometheus e le trasforma in notifiche - email, Telegram, Slack, webhook. La configurazione che uso come baseline su ogni VPS copre i sette scenari che nella mia esperienza causano il 95% dei downtime evitabili: ```yaml # /etc/prometheus/rules/vps-alerts.yml groups: - name: infrastruttura rules: - alert: DiscoQuasiPieno expr: (1 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) > 0.85 for: 5m labels: severity: warning annotations: summary: "Disco root sopra l'85%" runbook: "Controllare log rotation, /tmp, /var/log, storage/logs" - alert: RAMCritica expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 0.90 for: 5m labels: severity: critical annotations: summary: "RAM sopra il 90% da 5 minuti" runbook: "Verificare OOM killer, processi zombie, memory leak PHP-FPM" - name: applicazione rules: - alert: ErrorRate5xx expr: rate(laravel_http_responses_total{status=~"5.."}[5m]) / rate(laravel_http_responses_total[5m]) > 0.01 for: 3m labels: severity: critical annotations: summary: "Tasso errori 5xx sopra l'1%" runbook: "Controllare storage/logs/laravel.log, stato MySQL, stato Redis" - alert: CodaTroppoLunga expr: laravel_queue_depth > 1000 for: 10m labels: severity: warning annotations: summary: "Più di 1000 job in coda da 10 minuti" runbook: "Verificare stato Horizon, worker attivi, job bloccanti" - alert: JobFalliti expr: laravel_failed_jobs_total > 0 for: 1m labels: severity: warning annotations: summary: "Presenti job falliti nella tabella failed_jobs" runbook: "php artisan queue:failed, analizzare eccezione, retry o delete" - name: business rules: - alert: CertificatoInScadenza expr: (probe_ssl_earliest_cert_expiry - time()) / 86400 < 14 for: 1h labels: severity: warning annotations: summary: "Certificato SSL scade entro 14 giorni" runbook: "certbot renew --dry-run, verificare crontab certbot" - alert: BackupAssente expr: time() - laravel_last_backup_timestamp > 90000 for: 30m labels: severity: critical annotations: summary: "Nessun backup completato nelle ultime 25 ore" runbook: "Verificare spatie/laravel-backup, spazio disco remoto, credenziali S3" ``` Ogni alert ha un campo `runbook` - una riga che dice esattamente cosa controllare. Questo è il dettaglio che separa il monitoring che funziona dal monitoring che genera ansia: quando il tuo telefono vibra alle 2 di notte con "DiscoQuasiPieno", non devi pensare. Leggi il runbook, esegui i comandi, il problema è circoscritto. Per l'alert `CertificatoInScadenza` - quello che avrebbe evitato le 60 ore di downtime del cliente pugliese - serve Blackbox Exporter, un componente aggiuntivo di Prometheus che fa probe HTTPS e verifica la scadenza del certificato dall'esterno. Sul cliente pugliese, questa regola da sola avrebbe generato un alert il 4 luglio - 14 giorni prima della scadenza - dando tutto il tempo necessario per diagnosticare il problema con Certbot e risolverlo senza alcun impatto sull'operatività. ## Alertmanager: dove mandare gli alert perché qualcuno li legga La configurazione di [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) determina chi riceve quale alert e attraverso quale canale. La regola che applico è semplice: i `warning` vanno su un canale Telegram o Slack di team, i `critical` vanno anche via email al responsabile IT e via SMS (tramite webhook a un servizio come Twilio o MessageBird): ```yaml # /etc/alertmanager/alertmanager.yml global: resolve_timeout: 5m route: group_by: ['alertname'] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: 'team-telegram' routes: - match: severity: critical receiver: 'responsabile-it' receivers: - name: 'team-telegram' telegram_configs: - bot_token: '{{ .TelegramBotToken }}' chat_id: -100XXXXXXXXXX send_resolved: true message: '{{ template "telegram.default.message" . }}' - name: 'responsabile-it' telegram_configs: - bot_token: '{{ .TelegramBotToken }}' chat_id: -100XXXXXXXXXX send_resolved: true email_configs: - to: 'it@azienda.it' from: 'alerts@azienda.it' smarthost: 'smtp.azienda.it:587' require_tls: true ``` Il parametro `repeat_interval: 4h` è critico: senza di esso, un alert che resta attivo per giorni (come un disco che cresce lentamente) genera notifiche ogni 5 minuti - e dopo il primo giorno il team le ignora tutte. Con un repeat ogni 4 ore, l'alert ricorda la situazione senza diventare rumore bianco. ## Health check applicativo: il livello che manca alla maggior parte dei setup Prometheus e Node Exporter ti dicono se il server è vivo. Le metriche Laravel ti dicono se l'applicazione risponde. Ma nessuno dei due ti dice se l'applicazione *funziona correttamente dal punto di vista del business*. Per questo serve un health check applicativo dedicato - un endpoint che verifica non solo che Laravel risponda, ma che tutti i servizi da cui dipende siano raggiungibili e funzionanti: ```php // routes/web.php Route::get('/health', function () { $checks = []; // Database try { DB::select('SELECT 1'); $checks['database'] = 'ok'; } catch (\Throwable $e) { $checks['database'] = 'fail: ' . $e->getMessage(); } // Redis try { Redis::ping(); $checks['redis'] = 'ok'; } catch (\Throwable $e) { $checks['redis'] = 'fail: ' . $e->getMessage(); } // Storage scrivibile try { $path = storage_path('app/.health_check'); file_put_contents($path, time()); unlink($path); $checks['storage'] = 'ok'; } catch (\Throwable $e) { $checks['storage'] = 'fail: ' . $e->getMessage(); } // Spazio disco $freePercent = disk_free_space('/') / disk_total_space('/') * 100; $checks['disk_free_percent'] = round($freePercent, 1); $allOk = !in_array(false, array_map( fn ($v) => is_string($v) ? !str_starts_with($v, 'fail') : true, $checks )); return response()->json($checks, $allOk ? 200 : 503); }); ``` Questo endpoint restituisce 200 se tutto funziona, 503 se qualcosa è guasto. Blackbox Exporter di Prometheus lo interroga ogni 15 secondi, e l'alert scatta dopo 2 check consecutivi con stato non-200. In Laravel 12 esiste anche il facade `Health` nativo che offre un meccanismo simile out of the box, ma nella mia esperienza l'endpoint custom resta preferibile perché ti dà il controllo totale su cosa verificare e come esporre i risultati - e soprattutto perché puoi aggiungere check specifici del tuo business (ultimo ordine, ultima fattura emessa, ultimo backup riuscito) che nessun pacchetto generico può conoscere in anticipo. Per chi gestisce applicazioni PHP legacy senza Laravel, ho descritto un approccio analogo - logging strutturato, metriche essenziali e alert senza riscrivere il codice - nel mio articolo sull'[osservabilità minima per applicazioni PHP legacy](https://www.mauriziofonte.it/blog/post/osservabilita-minima-applicazioni-php-legacy-logging-metriche-alert.html). Sul cliente pugliese, dopo l'installazione completa dello stack, il primo alert utile è arrivato 11 giorni dopo: `DiscoQuasiPieno` al 86%. La causa: log di Laravel che non ruotavano perché il `daily` channel in `config/logging.php` era configurato con `days => 365` - un anno di log accumulati. Il fix è stato cambiare il valore a 14 giorni e aggiungere `logrotate` come safety net. Senza l'alert, quel disco si sarebbe riempito entro tre settimane, causando un altro downtime - diverso dal certificato, ma con lo stesso risultato per il business. Per chi vuole approfondire cosa fare quando il monitoring rileva un incidente reale e bisogna intervenire in emergenza, ho descritto il protocollo completo di [incident response in 72 ore per Laravel e Symfony, allineato a NIS2](https://www.mauriziofonte.it/blog/post/incident-response-72-ore-laravel-symfony-nis2-pmi.html) - che copre contenimento, forensics, ripristino e notifiche obbligatorie. Se gestisci un VPS unmanaged con applicazioni Laravel in produzione e il tuo sistema di monitoring è "il cliente mi chiama quando il sito non funziona", stai operando alla cieca su un'infrastruttura che genera fatturato. Il costo di un setup Prometheus + Grafana + Alertmanager su un VPS è di mezza giornata di lavoro iniziale e zero costi ricorrenti - il software è tutto open source. Il costo di non averlo è il prossimo downtime che scoprirai dalla telefonata del lunedì mattina. [Contattami](https://www.mauriziofonte.it/pages/contattami) se vuoi uno stack di monitoring operativo sulla tua infrastruttura: in una giornata installo, configuro e cablaggio gli alert su tutti e tre i livelli - infrastruttura, applicazione e business - con runbook per ogni scenario. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteQuando i microservizi sono la scelta sbagliata per il tuo monolite Laravel: il caso di una PMI lombarda27 Giugno 2025](https://www.mauriziofonte.it/blog/post/trasformazione-laravel-monolite-microservizi-guida.html)[Articolo successivo »Applicazione Laravel compromessa via APP_KEY su GitHub: forensics, contenimento e ripristino in cinque giorni30 Giugno 2025](https://www.mauriziofonte.it/blog/post/ripristino-laravel-attacco-informatico-emergenza.html) ### Articoli correlati a Monitoring proattivo per Laravel su VPS unmanaged: come evitare di scoprire un downtime dalla telefonata del cliente - [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) - [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) Il report ITIC 2024 stima che le PMI perdono da 8K a 25K per ogni ora di downtime. Il monitoraggio proattivo con Prometheus e Grafana, basato · 28 Mag 2025 ![Monitoraggio IT proattivo per PMI: da alert reattivi a SLO-based alerting con Prometheus e Grafana](https://www.mauriziofonte.it/image/001480070-monitoraggio-it-proattivo-prevenire-incidenti.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) - [Let's Encrypt con Certbot su Nginx: automazione completa per multi-dominio](https://www.mauriziofonte.it/blog/post/lets-encrypt-certbot-nginx-automazione-multi-dominio-linux.html) Gestire 40 certificati TLS su 8 VPS a mano è un incubo. Ho costruito un sistema di automazione con Certbot, un cron di controllo scadenze e alert · 30 Dicembre 2025 ![Let's Encrypt con Certbot su Nginx: automazione completa per multi-dominio](https://www.mauriziofonte.it/image/002450070-lets-encrypt-certbot-nginx-automazione-multi-dominio-linux.jpg) - [Certificato HTTPS scaduto o mal configurato su VPS con Laravel: diagnosi, fix e hardening TLS nel 2025](https://www.mauriziofonte.it/blog/post/https-compromesso-vps-laravel-protezione-urgente.html) Un portale B2B Laravel su Hetzner con certificato Let's Encrypt scaduto da 11 giorni il rinnovo automatico di Certbot falliva perché la porta · 4 Luglio 2025 ![Certificato HTTPS scaduto o mal configurato su VPS con Laravel: diagnosi, fix e hardening TLS nel 2025](https://www.mauriziofonte.it/image/001980070-https-compromesso-vps-laravel-protezione-urgente.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, "Monitoring proattivo per Laravel su VPS unmanaged: come evitare di scoprire un downtime dalla telefonata del cliente", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/vps-monitoring-laravel-prevenzione-downtime.html Pubblicato: 2025-06-30 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.