Tipi di check

Ogni piano include tutti i 13 tipi di check. Scopri cosa verifica ciascuno e quali dettagli tornano con un risultato, prima di registrarti.

Web
DNS e dominio
Mail
Rete
Host
Job

I piani fissano intervalli e regioni

A seconda del piano, gli intervalli scendono fino a 10 secondi. Il modulo web offre 30 secondi e intervalli più lunghi. Gli intervalli più brevi si impostano tramite MCP. La pagina dei prezzi indica l’intervallo minimo per piano.

Gli 11 tipi di check regionali usano le regioni incluse nel piano: 2 in Free, 3 in Pulse e tutte e 6 da Sentinel in su. La loro policy regionale è configurabile e usa per impostazione predefinita un quorum di 2 regioni. La pagina sul monitoraggio dell’uptime spiega la regola regionale.

agent e heartbeat non hanno regione e non richiedono quorum, perché la segnalazione arriva dal tuo host o dal tuo job.

Controlla URL e security header

http chiama un URL e verifica il risultato: un codice di stato atteso, una keyword che il body deve contenere o un’espressione regolare sul body. Segue i redirect fino a 5 hop e controlla ogni hop contro i bersagli SSRF prima di chiamarlo. Un monitor http può anche includere subcheck opzionali per certificato TLS, security header e igiene DNS, così un solo monitor copre ciò che prima ne richiedeva quattro. Solo il subcheck del certificato richiede https.

http_headers controlla i security header come monitor separato, con il proprio registro.

Controlla DNS, domini e certificati

dns risolve un nome e confronta l’insieme delle risposte con quello che ti aspetti. Un monitor DNS può anche confrontare le sue risposte con l’insieme di risposte di un altro monitor. Una divergenza passa per la normale pipeline degli incident.

dns_hygiene controlla SPF, DMARC e CAA come configurazione. Questi record decidono se la tua posta viene recapitata e chi può emettere certificati per te.

domain sorveglia il livello della registrazione: coerenza di NS e SOA, DNSSEC e scadenza WHOIS. Un dominio dentro la sua finestra di avviso, 14 giorni per impostazione predefinita, passa in stato degradato.

ssl_cert sorveglia un certificato direttamente, indipendentemente da qualsiasi monitor http. Controlla validità, catena, scadenza ed emittente, e riconosce i certificati self-signed.

Controlla i server di posta

smtp e imap controllano il percorso della posta da cui dipendono reset delle password e fatture. Dalle regioni di sonda del tuo piano verificano che il server accetti connessioni e parli il suo protocollo.

Controlla raggiungibilità e percorso di rete

ping controlla se l’host è raggiungibile. tcp controlla se una porta accetta una connessione, facoltativamente con il certificato TLS servito su quella porta. traceroute registra il percorso, cioè la prova che ti serve quando la colpa è di una rete intermedia e non del tuo servizio.

Sorveglia un host con l’agent

agent collega un monitor all’host agent. Controlla la disponibilità con un periodo di tolleranza, CPU, memoria e disco rispetto a soglie, e i servizi indicati per nome con una tolleranza contro il flapping. Una metrica senza dati recenti non produce alcun risultato anziché un falso allarme, e un monitor di disponibilità segna down un agent che tace.

Una sola riga installa l’agent dal punto di distribuzione su Linux (x86_64, aarch64) e su macOS come binario universale. Su Linux gira come unit systemd blindata. Non raccoglie mai righe di comando, variabili d’ambiente o nomi utente.

L’agent si aggiorna da solo con release firmate ed25519. Verifica ogni release prima della sostituzione, si blocca se la verifica fallisce e non richiede un helper root. Si disinstalla in modo pulito e si deregistra dal Cockpit.

Sorveglia i job con un heartbeat

heartbeat inverte la direzione: è il tuo job a chiamare Perstat, non Perstat a chiamare il tuo servizio. Questo copre un’esecuzione di cron, un backup notturno, un importer o qualsiasi altra cosa senza un indirizzo da sondare.

Ricevi un URL segreto e il job lo richiama quando ha finito. Se quella chiamata non arriva entro il periodo più la tolleranza che hai impostato, il monitor passa a down. Un job mai partito è il guasto che il monitoraggio ordinario non vede, perché non si è rotto niente che qualcuno potesse raggiungere.

Ogni heartbeat ha un endpoint di successo e un endpoint di errore. Un job partito e fallito può chiamare l’endpoint di errore, che porta il monitor in down alla valutazione successiva invece di aspettare la fine del periodo previsto. Il tuo script decide quale endpoint chiamare, quindi può segnalare qualsiasi condizione che sa verificare, non solo se il job è girato.

La documentazione dei monitor contiene gli URL esatti.

I risultati regionali includono la diagnosi

  • IPv4, IPv6 o entrambi, per IP. Ogni check di raggiungibilità gira sulle famiglie di indirizzi che selezioni, e su IPv4 se non ne selezioni nessuna. I risultati restano separati per famiglia e per IP. Decidi tu se un guasto in una famiglia conta come degradato o come fallito.
  • Tempo DNS separato. Dove previsto, dns_ms viene riportato a parte rispetto alla latenza totale, così un resolver lento non sembra un’applicazione lenta.
  • Attribuzione della causa. Quando un check di sonda supportato produce un’attribuzione, ne indica il livello: la tua applicazione o il tuo DNS, la rete, oppure il nostro resolver o il nostro nodo. Unknown resta valido finché la causa non è determinata, e non ogni esito porta un livello di causa.

Inizia a monitorare gratis oppure fai il tour del prodotto. Il tour non richiede registrazione.