HTTPS
Monitoraggio di siti web e API
Una pagina o un endpoint, recuperati da quattro continenti.
Provalo ora
Un controllo, da un solo posto, subito, e nulla viene salvato. Un monitor controlla da ogni posizione in cui operiamo e conferma un errore da altri due continenti prima che qualcuno venga svegliato, cosa che un singolo controllo non può mostrarti.
A cosa serve
Il controllo con cui tutti iniziano, e quello a cui la maggior parte dei prodotti si ferma. Richiediamo l'URL, seguiamo o rifiutiamo i redirect come dici tu, e leggiamo il codice di stato.
Un codice di stato da solo è una promessa debole. Un sito può restituire 200 mentre serve una pagina di errore, una schermata di login, una copia cache di martedì scorso o un guscio vuoto che non è riuscito a renderizzare. Quindi il controllo può anche richiedere la presenza di una frase, un redirect che atterri in un luogo specifico, un campo JSON con un valore particolare e una risposta che arrivi entro un tempo che imposti. Questi sono i fallimenti che un codice di stato non può vedere.
Come ogni controllo qui, viene eseguito da Amsterdam, New York, Sydney and Singapore, e un errore viene confermato da altri due continenti prima che qualcuno venga svegliato. Come funziona.
Cosa puoi impostare
Tutto ciò che segue è nel modulo quando ne aggiungi uno, su ogni piano.
- Metodo
- GET, HEAD, POST, PUT, PATCH o DELETE. HEAD è l'impostazione predefinita educata per una pagina di cui devi solo sapere l'esistenza.
- Stato previsto
- Quali codici contano come validi. Un 401 è corretto per un endpoint che dovrebbe rifiutarti, e dirlo ci impedisce di segnalare la tua autenticazione funzionante come un'interruzione.
- Parola chiave
- Una frase che deve esserci, o che deve essere assente. Il modo più economico per catturare un 200 che è in realtà una pagina di errore.
- Asserzioni JSON
- Un percorso e il valore che dovrebbe contenere, per un'API che risponde 200 con un body che dice il contrario.
- Redirect
- Segui la catena, o tratta un redirect come la risposta. Con una posizione prevista, questo cattura un sito silenziosamente reindirizzato dove non dovrebbe essere.
- Lentezza è un fallimento
- Un tempo di risposta oltre il quale il controllo conta come degradato piuttosto che attivo, e quanti di fila prima che lo diciamo.
- Autenticazione
- Basic o Bearer. Archiviato criptato, decriptato dal control plane e consegnato alla probe con l'assegnazione piuttosto che dare a una macchina noleggiata la chiave di tutto.
- Header e body
- Tutto ciò di cui la richiesta ha bisogno. Un header per riga e un body per i metodi che ne richiedono uno.
- Timeout
- Quanto aspettare prima di considerarlo un fallimento.
- Conferme
- Quanti altri continenti devono essere d'accordo prima che qualcuno venga svegliato. Zero è disponibile ed è raramente ciò che vuoi.
Domande
Cosa significa un 502 o un 503, e invierai un alert su di esso?
Un 502 è il server davanti che ti dice che quello dietro ha dato una risposta che non poteva usare, e un 503 è un server che dice che non sta accettando richieste, che è ciò che la maggior parte dei framework restituisce durante un riavvio. Entrambi falliscono il controllo per impostazione predefinita, perché l'impostazione predefinita si aspetta 2xx e 3xx. Se un codice è corretto per quell'endpoint, mettilo nella lista degli status attesi e smette di essere un outage.
Verifichi la catena di certificati SSL/TLS?
Sì. Il controllo si connette come farebbe un browser, contro il trust store pubblico, quindi un intermediario mancante, un certificato autofirmato, un hostname non corrispondente o uno scaduto falliscono il controllo con un errore TLS invece di un codice di stato. Quello che non fa è contare i giorni rimanenti, che è il compito del monitor del certificato SSL/TLS. La verifica può essere disattivata per monitor su un host interno che conosci.
Posso monitorare un endpoint API invece di una pagina?
È per questo che esistono le opzioni della richiesta, ed è il motivo per cui non c'è un tipo di monitor API separato da questo. Scegli POST, PUT, PATCH o DELETE, aggiungi header e un body, autentica con credenziali basic o bearer, accetta i codici di stato corretti e verifica un percorso nel JSON che ritorna.
Qual è la differenza tra un timeout e una risposta lenta?
Un timeout è un controllo che non ha mai ricevuto una risposta entro i secondi consentiti, ed è segnalato come un fallimento senza codice di stato, a parte una connessione rifiutata direttamente. Lento è una risposta che è arrivata ma ha impiegato troppo tempo: imposta un tempo di risposta oltre il quale il controllo è considerato degradato, e quanti di fila prima che qualcuno venga avvisato.
Segui i redirect?
Non a meno che tu non lo dica, il che sorprende abbastanza spesso da valere una spiegazione. Un sito che inizia a rispondere 302 a una pagina di parcheggio è rotto, e un checker che lo segue silenziosamente e trova un 200 lo segnalerebbe come sano. Attiva il follow quando il redirect è il punto, e specifica la destinazione che ti aspetti.
Il controllo esegue JavaScript o renderizza la pagina?
No, e lo diciamo invece di implicare il contrario. Recupera il documento che il server invia e legge quello, quindi un controllo per parola chiave deve corrispondere a qualcosa nell'HTML piuttosto che a qualcosa che un framework disegna dopo. Per una pagina renderizzata nel browser, verifica il codice di stato, il tempo di risposta e una frase che sia effettivamente nella risposta.
Il tempo di risposta è quello che sperimentano i miei visitatori?
È il tempo che la nostra probe ha aspettato, dalla richiesta alla risposta, su una connessione senza cache fredda e senza un browser davanti. Questo lo rende un eccellente campanello d'allarme per un server che sta rallentando e un pessimo modello di una persona su un telefono. Il monitoraggio reale degli utenti e i Core Web Vitals rispondono all'altra domanda e questo controllo non finge di farlo.
Perché non usare semplicemente curl in un cron job?
Per un URL da una macchina, un cron job è davvero la maggior parte di questo, e chiunque ti dica il contrario sta vendendo qualcosa. Quello che non ti dà è un posto dove eseguire che non possa morire silenziosamente: un controllo su una macchina che ha perso la rete non segnala nulla, il che sembra esattamente come se tutto fosse a posto. Né ti dice se c'è un link rotto tra te e il sito o se il sito è rotto, che è il motivo per cui si controlla di nuovo da altri due continenti, e ti lascia comunque costruire la parte che sveglia qualcuno.
In cosa è diverso da un controllo sintetico basato su browser?
Un controllo sintetico guida un vero browser, quindi vede cose che noi non possiamo: una pagina che si rende vuota perché uno script ha generato un errore, un pulsante che ha smesso di funzionare, un font che non è mai stato caricato. Questo controllo fa la richiesta e legge la risposta, il che significa che non può vedere nulla di tutto ciò. Quello che ti offre invece è un controllo abbastanza economico da eseguire ogni trenta secondi da tre continenti, su ogni URL che hai, piuttosto che una manciata di percorsi alcune volte all'ora. Rispondono a domande diverse e molte persone vogliono entrambi.