Monitoraggio sintetico
Il monitoraggio sintetico di HostTracker mette alla prova il tuo sito secondo una pianificazione, da oltre 300 località, usando il controllo più adatto al compito: un percorso scriptato in browser, una chiamata API valutata da regole, o una semplice richiesta HTTP. Scegline uno qui sotto e ricevi un avviso nel momento in cui smette di corrispondere a ciò che ti aspetti.
Lo stesso schema dietro a tutti e tre: esegui, valuta, riverifica, avvisa
Il monitoraggio sintetico significa che il traffico viene generato di proposito. Invece di aspettare che un visitatore reale incontri un problema, un servizio di monitoraggio guida da sé il tuo sito web, secondo una pianificazione fissa, dall’esterno della tua rete, e controlla ciò che riceve in base alle regole che imposti. Gli strumenti di monitoraggio sintetico di HostTracker coprono tre forme di controllo - monitoraggio in browser per un percorso scriptato, una chiamata API valutata da regole, e una semplice richiesta HTTP - coprendo tutto, da un flusso di checkout completo fino a una singola verifica del codice di stato, tutto da oltre 300 località nel mondo.
Non è monitoraggio degli utenti reali. HostTracker genera da sé ogni controllo; non raccoglie dati di tempistica o di errore dai browser dei tuoi visitatori reali. Se hai bisogno di sapere cosa hanno vissuto i tuoi visitatori reali, quella è una disciplina diversa con un nome diverso - vedi monitoraggio sintetico e monitoraggio degli utenti reali per il confronto completo. Il vantaggio del monitoraggio sintetico va nella direzione opposta: funziona prima ancora che tu abbia un solo visitatore, e continua a funzionare alle tre del mattino quando nessuno sta guardando.
I tre tipi di controllo rispondono a domande diverse, e scegliere quello sbagliato è il modo più comune in cui un problema reale passa inosservato. Questa tabella associa cinque esigenze comuni al controllo che le copre davvero.
La maggior parte degli account finisce per eseguire più di una riga di questa tabella contemporaneamente - un controllo HTTP sotto a tutto, più un controllo transazionale o API sui flussi, uno o due, che contano di più.
Uno scenario transazionale è una sequenza di azioni con nome; un insieme di regole API è un gruppo di asserzioni su un’unica risposta. Entrambi si configurano, non si scrivono come script.
Transazione: uno scenario a cinque passaggi
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
API: un insieme di quattro regole
status isOk header("Content-Type") contains "json" body.json.path("$.count") gt 0 time lt 5s
Ognuno risponde a una domanda diversa. La maggior parte degli account che usa HostTracker finisce per eseguirne più di uno.
Apri un vero browser Chromium e percorri fino a dieci passaggi - accedi, cerca, aggiungi al carrello, effettua il checkout - poi verifica cosa c’è sulla pagina. Rileva ciò che un codice di stato non può: un pulsante rimosso, un invio di modulo rotto, un errore JavaScript a metà percorso. Monitoraggio delle transazioni
Invia una chiamata HTTP e valuta la risposta rispetto a fino a 20 regole di asserzione su stato, intestazioni, tempistiche e corpo JSON, XML o testo semplice. Pensato per l’endpoint da cui dipende un altro sistema. Monitoraggio API
Richiede un URL da oltre 300 checkpoint in 158 città e controlla lo stato, le parole chiave del corpo, il tempo di risposta e il TLS. La base sempre attiva su cui poggiano gli altri due. Monitoraggio HTTP
La forma del controllo cambia; i checkpoint, la logica di conferma e i canali di avviso dietro di essa no.
Ogni tipo di controllo viene eseguito dalla stessa flotta pubblica di checkpoint. Scegli le località che corrispondono a dove si trovano davvero i tuoi visitatori, o i consumatori della tua API.
Un singolo checkpoint che fallisce non apre mai da solo un incidente. Il controllo viene rieseguito da altri checkpoint indipendenti, e solo un risultato concorde lo trasforma in un avviso.
Un controllo transazionale conserva uno screenshot dell’ultimo passaggio, e un altro nel momento in cui un passaggio fallisce, così il debug parte da come appariva davvero la pagina.
Verifica il testo visualizzato, un valore JSON selezionato tramite JSONPath o XPath, oppure una semplice parola chiave - fino a 20 regole di asserzione o 10 corrispondenze di parole chiave per monitor, a seconda del tipo di controllo.
Email, SMS, chiamata vocale, Slack, Telegram e webhook, configurati una volta per ciascun contatto, sono condivisi tra i controlli transazionali, API e HTTP del tuo account.
Aggiungi qualsiasi monitor - percorso in browser, chiamata API o controllo HTTP - alla stessa pagina di stato pubblica, così i clienti vedono una sola pagina invece di tre separate.
Siti web, server, API, certificati. Un tipo di controllo per pagina, con le stesse località, avvisi e report alle spalle.
Scelto da team come
Ogni capitolo si apre sul posto, così la pagina resta breve.
I due approcci rispondono a domande diverse. Il monitoraggio sintetico di un sito web genera il proprio traffico, dai propri checkpoint, secondo una pianificazione che controlli tu - un percorso scriptato in browser, una chiamata API, o una semplice richiesta HTTP. Il monitoraggio degli utenti reali invece osserva i browser dei tuoi visitatori effettivi, il che significa che ha bisogno di traffico reale per dire qualcosa, e non può dirti cosa succederà domani, solo cosa è già successo oggi.
HostTracker è un servizio di monitoraggio sintetico - non offre il monitoraggio degli utenti reali, e questa pagina non farà finta del contrario. Ciò che il monitoraggio sintetico offre invece: un sito di staging senza alcun visitatore viene comunque controllato; un guasto alle tre del mattino viene rilevato allo stesso modo di uno nell’ora di punta; e poiché lo scenario è deterministico, il risultato indica il passaggio o la regola esatti che sono falliti, invece di un sintomo vago. Per il confronto completo fianco a fianco, vedi monitoraggio sintetico e monitoraggio degli utenti reali; la pagina del monitoraggio delle transazioni riporta anche una tabella dettagliata se vuoi i meccanismi.
Ogni tipo di controllo ha il proprio limite minimo di intervallo, perché ciascuno richiede una quantità diversa di lavoro per essere eseguito. Una richiesta HTTP è economica e può essere eseguita anche ogni minuto su un piano a pagamento. Una chiamata API aggiunge l’analisi e la valutazione delle regole, ma viene comunque eseguita da un minuto fino a 24 ore. Un controllo transazionale apre un browser reale e percorre uno scenario dall’inizio alla fine, motivo per cui ha un limite minimo di 10 minuti - i controlli tramite browser sono costosi da eseguire e da ricevere, e abbinarne uno a un controllo HTTP veloce sullo stesso sito copre sia la domanda «è raggiungibile in questo momento» sia quella più difficile «il flusso funziona ancora», senza eseguire un browser ogni sessanta secondi.
Tutti e tre ti permettono di scegliere da quale dei 300+ checkpoint in 158 città viene eseguito un determinato monitor - la geografia conta più di quanto sembri, dato che una CDN o un load balancer con instradamento geografico possono essere sani in una regione e guasti in un’altra.
La tentazione con qualsiasi nuovo tipo di controllo è collegarlo direttamente a un avviso che sveglia qualcuno. Resisti per la prima settimana: lascia che un nuovo monitor funzioni in silenzio, leggi una manciata di risultati reali, e solo allora decidi chi viene avvisato immediatamente e chi riceve invece un riepilogo giornaliero. Un controllo transazionale che fallisce perché è cambiato il selettore di un banner di marketing non ha la stessa gravità di uno che fallisce perché il checkout ha smesso di completarsi - scrivi le tue verifiche sul contenuto usando testo stabile e significativo, così l’avviso che ricevi vale davvero la pena di essere gestito.
Gli avvisi vengono inviati tramite i canali che configuri per ciascun contatto - email, SMS, chiamata vocale, Slack, Telegram, webhook e altro ancora - lo stesso insieme per tutti e tre i tipi di controllo, così un guasto transazionale e un guasto HTTP raggiungono la stessa persona nello stesso modo. Un cambio di stato viene confermato solo quando altri checkpoint concordano, quindi l’avviso che ricevi è già ponderato e non una singola osservazione instabile; segue un avviso di ripristino una volta che il controllo torna a passare, chiudendo il cerchio senza che tu debba andare a controllare.
Il monitoraggio sintetico è un monitoraggio in cui il traffico viene generato di proposito, secondo una pianificazione, da un servizio esterno ai tuoi sistemi, invece di aspettare che un visitatore reale incontri un problema sperando che te lo segnali. Il monitoraggio sintetico di HostTracker si presenta in tre forme: un percorso scriptato in browser che percorre un flusso multi-fase, una chiamata API valutata secondo regole che scrivi tu, e una semplice richiesta HTTP controllata su stato, corpo e tempistiche. Tutte e tre vengono eseguite da oltre 300 località, usano gli stessi canali di avviso, e trattengono un avviso finché altri checkpoint non confermano il guasto.
No. HostTracker genera da sé il traffico, dai propri checkpoint, secondo una pianificazione che imposti tu - non raccoglie dati di tempistica o di errore dai browser dei tuoi visitatori reali. Se hai bisogno di sapere cosa hanno vissuto i tuoi visitatori reali, quello è il monitoraggio degli utenti reali, una disciplina diversa con un nome diverso; vedi monitoraggio sintetico e monitoraggio degli utenti reali per il confronto completo. Il vantaggio del monitoraggio sintetico è l’opposto: funziona prima ancora che tu abbia un solo visitatore, e continua a controllare alle tre del mattino quando nessuno sta navigando.
Il monitoraggio uptime, nel senso stretto e quotidiano, di solito indica esattamente una di queste tre forme: il semplice controllo HTTP che richiede un URL e osserva il codice di stato e il tempo di risposta. Il monitoraggio sintetico è il termine più ampio che copre anche il monitoraggio in browser - il percorso scriptato - e il monitoraggio sintetico delle API, la chiamata valutata secondo regole. Un controllo HTTP risponde a «il server c’è»; un controllo transazionale risponde a «il flusso multi-fase si completa davvero»; il monitoraggio sintetico delle API risponde a «la risposta corrisponde davvero al proprio contratto». Un sito può superare ogni controllo HTTP mentre il suo checkout è rotto, ed è esattamente questo il divario che gli altri due colmano.
No. Tutti e tre i tipi di controllo si costruiscono nell’editor web. Uno scenario transazionale è un elenco di azioni - navigate, click, type e così via - scelte da un menu, con un selettore CSS digitato in un campo. Le regole di asserzione di un monitor API sono ciascuna una riga di sintassi semplice e leggibile, non uno script. Le parole chiave e le opzioni di un monitor HTTP sono campi di un modulo. Nulla di tutto questo è un linguaggio di programmazione, anche se l’intera superficie di azioni e regole è raggiungibile anche tramite l’API, se vuoi automatizzare la configurazione stessa.
Fino a dieci passaggi scritti, entro un budget di 40 secondi per l’intera esecuzione. Una navigazione di apertura verso l’URL del monitor stesso viene aggiunta automaticamente come passaggio zero, quindi i dieci passaggi che scrivi sono dieci passaggi di lavoro reale - clic, testo digitato, verifiche sul contenuto - non nove più un caricamento di pagina. Un flusso che ha davvero bisogno di più di dieci passaggi è di solito meglio suddividerlo in due monitor; questo ti dice anche quale metà si è rotta.
Inizia con un controllo HTTP sul sito stesso - è il segnale più economico e la base sempre attiva che ogni account dovrebbe avere. Poi aggiungi quale dei due rimanenti corrisponde al tuo rischio di maggior valore: un controllo transazionale se un checkout o un login rotto ti costa denaro direttamente, un controllo API se un altro sistema - la tua app, l’integrazione di un partner - dipende da un endpoint che risponde correttamente. La maggior parte degli account che usa tutti e tre esegue il controllo HTTP più spesso, quello API subito dopo, e quello transazionale sull’intervallo più lungo, dato che è quello che richiede più lavoro per essere eseguito.
Dipende dal tipo di controllo, perché ognuno richiede una quantità diversa di lavoro per essere eseguito. I controlli HTTP possono essere eseguiti anche ogni minuto su un piano a pagamento. I controlli API vanno da un minuto fino a 24 ore. I controlli transazionali - poiché ogni esecuzione apre un browser reale e percorre uno scenario dall’inizio alla fine - hanno un limite minimo di 10 minuti. Uno schema comune abbina un controllo HTTP a un minuto per un rilevamento rapido delle interruzioni a un controllo transazionale o API ogni 10-15 minuti per la domanda più approfondita.
Il guasto non viene considerato attendibile alla prima osservazione. HostTracker riesegue il controllo da altri checkpoint indipendenti, e conferma il cambio di stato solo quando un numero sufficiente di essi concorda, così un singolo percorso di rete instabile o un nodo lento non si trasforma da solo in un avviso. Una volta confermato, HostTracker avvisa i contatti che hai configurato attraverso i canali che hai scelto - email, SMS, chiamata vocale, Slack, Telegram, webhook e altro ancora - dopo il ritardo assegnato a ciascun contatto, e segue un avviso di ripristino una volta che il controllo torna a passare.
Avvia una prova gratuita e aggiungi un controllo transazionale, API o HTTP allo stesso account - le stesse oltre 300 località e gli stessi avvisi dietro a tutti e tre.
Fa parte del software di monitoraggio siti web di HostTracker.
