Un controllo di uptime funziona in modalità pull: un servizio di monitoraggio invia a intervalli regolari una richiesta al tuo sito o alla tua API e ti avvisa quando la risposta è sbagliata o manca. Un heartbeat funziona in modalità push: il tuo job o servizio invia una richiesta al servizio di monitoraggio a ogni esecuzione, e l’avviso scatta quando quella richiesta non arriva. Usa i controlli di uptime per tutto ciò che le persone raggiungono via rete, e gli heartbeat per le attività pianificate o prive di un indirizzo pubblico. La maggior parte delle configurazioni ha bisogno di entrambi.
È facile confonderli, perché entrambi si riducono a “avvisami quando qualcosa non va”. Vedono però guasti diversi, e usare l’uno dove serve l’altro lascia un punto cieco che emerge solo quando qualcosa si rompe.
Come funziona un controllo di uptime
Il client è il servizio di monitoraggio. Ogni minuto, o all’intervallo che scegli, richiede un URL, esegue un ping verso un host o apre una porta, e valuta la risposta: il codice di stato, il tempo di risposta, una parola chiave nella pagina, il certificato. Se il controllo fallisce e un secondo controllo lo conferma, ricevi un avviso. È una forma di monitoraggio sintetico: un robot fa quello che farebbe un visitatore.
Cosa rileva: un sito o un’API down, lenti, che rispondono con errori, mostrano il contenuto sbagliato o sono bloccati da un certificato scaduto o da una modifica DNS. Tutto ciò in cui si imbatterebbe un visitatore.
Cosa non vede: tutto ciò che non risponde alle richieste. Un backup che non è partito, un queue worker bloccato, un’importazione fallita alle 02:00. Il sito resta online, quindi ogni controllo va a buon fine.
Come funziona un heartbeat
Il client è il tuo job. Indichi al servizio di monitoraggio quando il job deve essere eseguito, e il job chiama un URL di ping univoco quando termina. Se il ping è in ritardo oltre un periodo di tolleranza da te scelto, ricevi un avviso. L’idea è quella del dead man’s switch: il segnale è il silenzio. Per questo l’heartbeat monitoring è chiamato anche push monitoring o dead man’s switch monitoring.
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 -o /dev/null https://app.uptimecheck.com/api/hb/your-token
Cosa rileva: job che non sono partiti, si sono interrotti prima della fine, sono stati eseguiti con la pianificazione sbagliata o, con un ping di avvio, sono durati troppo. Con un exit code nel ping, rileva anche i job eseguiti ma falliti.
Cosa non vede: se qualcuno riesce a raggiungere il tuo servizio. Un job su un server può inviare ping senza problemi mentre il sito sullo stesso server risponde 502 a ogni visitatore.
A confronto
Controllo di uptimeHeartbeatChi invia la richiestaIl servizio di monitoraggioIl tuo job o servizioAvviso quandoLa risposta è sbagliata, lenta o assenteIl ping è in ritardo o segnala un erroreServe un indirizzo pubblicoSìNo, solo HTTPS in uscitaConfigurazioneUn URL, un host o una portaUna pianificazione, un periodo di tolleranza e una richiesta nel jobVedeCiò che vivono visitatori e client APISe le attività in background sono state eseguite e come sono terminateNon vedeLe attività che non rispondono alle richiesteSe qualcuno riesce a raggiungere il servizio
Quando usare un controllo di uptime
La homepage e le pagine che generano ricavi: checkout, registrazione, login.
API pubbliche e ricevitori di webhook, con controlli sul codice di stato e sul JSON restituito.
Un endpoint di health check che verifica il database e le altre dipendenze a ogni richiesta.
Servizi su altre porte, come un server di posta, con un controllo della porta.
La regola pratica: se una persona o un altro sistema lo chiama, controllalo dall’esterno nello stesso modo.
Quando usare un heartbeat
Cron job: backup di database e file, importazioni ed esportazioni notturne, generazione di report, cicli di fatturazione.
Attività pianificate in altre forme: un’attività pianificata di Windows, un CronJob di Kubernetes, un workflow GitHub Actions pianificato, una funzione serverless con timer.
Script di rinnovo dei certificati e sincronizzazioni di dati tra sistemi.
Tutto ciò che sta dietro un firewall o un NAT e non è raggiungibile dall’esterno, ma può fare una richiesta HTTPS in uscita.
Worker sempre in esecuzione
Un queue worker o un daemon non segue una pianificazione, ma può comunque inviare un heartbeat. Invia un ping dal ciclo principale ogni pochi minuti e assegna al monitor un intervallo invece di un’espressione cron. Se il ciclo si blocca, il processo viene terminato o il server si riavvia senza farlo ripartire, i ping si fermano e vieni avvisato. Invia il ping dal ciclo che svolge il lavoro, non da un thread separato, altrimenti un worker bloccato continuerà a dire che va tutto bene.
Quando servono entrambi
La maggior parte dei servizi reali ha una vetrina e un retrobottega. Monitora ciascuno con lo strumento che lo vede:
Un negozio online: controlli di uptime su homepage e checkout, e heartbeat sull’esportazione notturna degli ordini e sul backup del database.
Un prodotto SaaS: un controllo di uptime sull’endpoint di health dell’API, e heartbeat sul queue worker e sul job che invia le fatture.
Un servizio interno: nessun indirizzo pubblico, quindi un heartbeat dal servizio stesso, più controlli di uptime sulle pagine pubbliche che dipendono dai suoi dati.
Un’alternativa è esporre lo stato dei job tramite l’endpoint di health, ad esempio facendo fallire il controllo quando l’ultimo backup ha più di 25 ore. Funziona, ma lega l’uptime del sito ai backup, così un backup in ritardo compare nei report come downtime del sito. Un heartbeat separato tiene distinti i due segnali, e anche le persone che ricevono ciascun avviso.
Impostare bene i tempi
Intervallo del controllo di uptime: ogni minuto per le pagine che generano ricavi, perché l’intervallo è il tempo massimo in cui puoi restare all’oscuro di un disservizio. Le pagine meno critiche possono usare un intervallo più lungo.
Periodo di tolleranza dell’heartbeat: più lungo della normale variazione dell’orario di fine del job. Un backup che parte alle 03:00, dura da 5 a 20 minuti e invia il ping alla fine richiede almeno 20 minuti di tolleranza; 30 lasciano margine per una notte lenta.
Durata massima: con un ping di avvio, ricevi un avviso quando un’esecuzione dura molto più del solito. Anche un job bloccato non invia mai il ping di fine, ma questo avviso arriva non appena il limite viene superato.
Fuso orario: una pianificazione cron segue il fuso orario del server, spesso UTC. Imposta lo stesso nel monitor, altrimenti con l’ora legale si aspetterà il job un’ora prima o dopo due volte l’anno. Lo strumento per espressioni cron mostra quando una pianificazione viene effettivamente eseguita.
Errori comuni
Inviare il ping solo all’avvio. Un job che parte e poi va in crash si fa comunque vivo. Invia il ping alla fine, oppure entrambi.
Inviare il ping anche quando il job fallisce. backup.sh; curl … invia il ping qualunque cosa succeda. Usa &&, oppure invia l’exit code, così un errore viene segnalato come tale.
Un ping che può bloccare il job. Imposta per curl un timeout e dei tentativi (-m 10 –retry 3), così una rete lenta non blocca il job né fa perdere il ping.
Usare un heartbeat per un sito pubblico. Un server che invia ping dimostra solo di poter raggiungere internet, non che i visitatori possano raggiungere lui.
Monitorare il daemon cron invece del job. Il daemon può funzionare benissimo mentre un job fallisce ogni notte. Ogni job importante ha il suo heartbeat.
Per approfondire il lato heartbeat, leggi come monitorare i cron job e come evitare le attività cron mancate.
Entrambi in un unico posto con Uptimecheck
Uptimecheck gestisce entrambi i tipi di monitor nello stesso account, con gli stessi canali di avviso e la stessa cronologia degli incidenti.
Monitoraggio uptime: controlli HTTP(S), ping e porta fino a ogni minuto da Stoccolma, Londra e New York, con ogni errore confermato da una seconda località prima dell’avviso. I controlli HTTP possono verificare il codice di stato, una parola chiave, campi JSON e header.
Monitoraggio dei cron job: un’espressione crontab nel tuo fuso orario, ora legale inclusa, o un semplice intervallo; un periodo di tolleranza da 1 minuto a 6 ore; ping /start con una durata massima da 1 minuto a 24 ore; /fail o l’exit code per indicare come è terminata un’esecuzione; e l’output del job, inviato con il ping, mostrato nell’avviso.
Limiti: Start include 15 monitor di uptime e 10 cron job, Professional 100 e 50, Business 250 e 150. Vedi i prezzi.
Per configurarne uno, consulta come monitorare un cron job con un heartbeat e gli esempi di ping per cron job per Laravel, Kubernetes, GitHub Actions, systemd e Windows. Per dischi e memoria del server sottostante, aggiungi il monitoraggio dei server.
Tieni d’occhio la vetrina e il retrobottega. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.