Sapere che il sito è 'su' non basta. Serve sapere se gli utenti prendono 500, se il disco sta finendo, e chi deve alzarsi alle tre.
Un ping verde non dice se il sito sta servendo gli utenti. Dice che una porta, su un URL, ha risposto una volta. Prima che cada davvero servono altri segnali: errori 5xx, latenza, disco e inode, CPU, scadenza TLS, battito dei job. Senza quelli si viene a sapere il fermo da un cliente, o da Google, e si arriva tardi per mestiere.
In breve: il monitoring utile misura disponibilità, errori, saturazione e lavoro in background, con un allarme che ha un owner e un'azione. Il ping è un pezzo. Non è il sistema. Troppi allarmi spengono l'attenzione: alert fatigue. Si tiene poco, si tiene azionabile, si verifica che svegli la persona giusta.
Cosa trovi in questo articolo
Perché l'uptime ping non basta
Un controllo che chiede la home ogni cinque minuti e si accontenta di un 200 è utile come filo. Non è osservabilità. Il sito può rispondere 200 con una pagina di errore del CMS, con un checkout rotto, con il disco al 99%, con un certificato che scade domani, con il cron delle scorte fermo da tre ore. L'utente, su un URL interno, prende 500. Il ping, sulla home in cache, resta verde.
Google, nel capitolo del SRE Book sul monitoring, usa quattro segnali d'oro: latenza, traffico, errori, saturazione. Non è un dogma da copiare in un dashboard da cinquanta pannelli. È una lista corta che copre il fermo vero. Un ping copre, a malapena, un pezzo della disponibilità. Gli altri tre restano ciechi.
Il tema sta nel cluster Operatività: si misura per intervenire, non per avere un murales di grafici. Accanto ai log, che ricostruiscono l'incidente, il monitoring deve dirlo mentre succede. I due mestieri si tengono insieme, come nella guida sui log del sito: traccia utile, non archivio infinito. Allarme utile, non rumore.
Cosa misurare: 5xx, latenza, saturazione, TLS, job
Cinque famiglie bastano per la maggior parte dei siti. Si aggiunge solo se una di queste è cieca su un guasto reale.
Errori 5xx. Quota di risposte 500, 502, 503, 504 sul totale. Per origine, per URL di business (checkout, login, API). Un 200 sulla home e un 502 sul carrello sono due prodotti. Si guarda il tasso, non il singolo hit: un crawler che prende un 500 non è un incidente. Una frazione visibile sul checkout sì. Il codice 5xx è il segnale che l'origine o il proxy non stanno servendo. Il 4xx, a parte picchi di 401/403 anomali, è in genere l'utente o un bot. Non si sveglia gente per un 404 su un asset vecchio.
Latenza. Non la media: un percentile alto (p95, p99) sulla richiesta server-side, e, se si ha campo, LCP/INP sulle pagine che portano soldi. La media nasconde la coda. La coda è ciò che l'utente chiama "sito lento". Il pezzo di prodotto sta nella guida sulla performance: si misura il campo, non il test più lusinghiero. Dal lato operatività basta sapere se l'origine sta impiegando più del solito a rispondere, prima che Lighthouse lo dica lunedì mattina.
Saturazione: disco, inode, CPU, memoria. Un volume al 95% non dà 500 immediatamente. Li dà quando il log, la sessione o MySQL non riescono più a scrivere. Gli inode finiti sono il classico fermo "il disco c'è, i file no": milioni di sessioni o cache su filesystem. CPU a tetto e load alto, su una macchina che serve PHP o un worker, sono saturazione. Si allarma prima del pieno, non al 100%. Il pieno è già il fermo.
Scadenza TLS. Un certificato che scade è un fermo prevedibile, e per questo ingiustificabile. Let's Encrypt documenta certificati a 90 giorni: il rinnovo va monitorato, non ricordato. Un allarme a 21 giorni, uno a 7, sul certificato che il virtual host sta davvero servendo (non su quello nel cassetto). La checklist di HTTPS e HSTS parte da redirect e rinnovo: il monitoring è il pezzo che impedisce di scoprirlo dai screenshot degli utenti con il browser in rosso.
Heartbeat dei job. Cron, code, import, generazione feed, rinnovo cache. Un job che "gira di notte" e non gira è un incidente silenzioso: scorte sbagliate, prezzi vecchi, sitemap ferma. Si misura l'ultimo successo, non l'ultimo avvio. Un processo che parte e muore dopo un secondo è un avvio. Non è un heartbeat. Timestamp del last success, soglia, owner.
Allarmi: owner, azione, alert fatigue
Un allarme senza azione è una notifica. Un allarme senza owner è rumore di gruppo. L'SRE Book, nello stesso capitolo sul monitoring e in Practical Alerting, insiste su segnali che un umano può trattare: c'è un fermo, c'è un gesto, c'è qualcuno di turno. Se l'unica risposta possibile è "vediamo domani", non è un allarme. È un record da dashboard.
L'alert fatigue è reale. Troppi avvisi, troppi falsi, troppi canali, e il team impara a silenziare. A quel punto il ping verde e i cinquanta allarmi rossi dicono la stessa cosa: nulla. Si tiene una lista corta, si soglia su tasso e durata (non sul singolo spike), si prova l'allarme come si prova un restore. Se in tre mesi un allarme non è mai stato azionabile, si cancella o si sposta in un report diurno.
Severity onesta. Pagina (sveglia) solo per il servizio giù, per il 5xx sul percorso di business, per il disco vicino al pieno, per il TLS sotto soglia, per il job che alimenta il negozio. Il resto è ticket del giorno dopo. Confondere le due classi è il modo più rapido per far sì che, la notte del fermo vero, il telefono resti in modalità silenziosa.
Sintetico e di campo, insieme
Il controllo sintetico (un probe esterno che chiama HTTPS, legge un 200, misura il tempo) vede ciò che un utente nuovo vede: DNS, TLS, origine, un URL scelto. Va messo fuori dalla rete del datacenter, su più centri se il pubblico è geograficamente sparso, e su più URL: home, una scheda, il login, un healthcheck che non passa dalla cache piena. Un probe solo sulla home in CDN è un complimento alla cache, non un controllo dell'origine.
I dati di campo (RUM, log aggregati, metriche dell'host) vedono l'utente vero e la macchina vera. Un probe può essere verde mentre il p95 sul checkout è triplicato, o mentre un solo nodo del pool è saturo. Si tengono entrambi. Il sintetico sveglia. Il campo spiega. I log, se interrogabili, chiudono la causa.
Ha senso quando. Non serve quando
Ha senso un monitoring corto e azionabile su ogni sito che è un canale: ecommerce, lead, app, editoriale con pubblicità. 5xx, latenza, disco/inode, TLS, heartbeat dei job, un probe esterno, un owner. Basta per non farsi raccontare il fermo da Twitter.
Non serve un osservability platform da white paper su un sito che può restare fermo fino a lunedì. Non serve un dashboard di cinquanta pannelli che nessuno apre. Non serve copiare le soglie di un SaaS da miliardo di richieste. Serve coprire i guasti che, su quel prodotto, hanno già fatto male o lo farebbero lunedì mattina.
Errori da evitare
Fidarsi del ping sulla home. La home è la pagina più cachata. Il fermo sta altrove.
Allarmare sulla media. La media è calma mentre la coda è già piena.
Allarmare su tutto. Si ottiene silenzio appreso. L'alert fatigue non è un tratto di carattere. È un disegno sbagliato.
Non provare l'allarme. Un webhook verso un canale morto è un monitoring che mente.
Dimenticare TLS e cron. Sono fermi prevedibili. Se arrivano come sorpresa, il monitoring non c'era.
Non nominare l'owner. "DevOps" non è una persona di turno. Lo è un nome, un canale, una escalation.
In sintesi
Il monitoring che conta dice se gli utenti stanno prendendo 5xx, se l'origine è lenta, se disco e inode stanno finendo, se il certificato vive, se i job hanno avuto un last success. Il ping è il filo. Gli allarmi sono pochi, con un owner e un gesto. Il resto, murales, medie, soglie copiate, è rumore. Si misura per alzarsi prima del cliente. Se si viene a saperlo dal cliente, si aveva un ping. Non si aveva monitoring.
Fonti
Google SRE Book, Monitoring Distributed Systems (four golden signals: latency, traffic, errors, saturation).
Google SRE Book, Practical Alerting.
Let's Encrypt, FAQ (validità dei certificati a 90 giorni).
MDN, HTTP response status codes (classe 5xx).
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
