Monitoraggio sintetico: misurazione automatizzata dei tempi di caricamento in diverse regioni

Cosa mostra Synthetic Monitoring

Il monitoraggio sintetico esegue automaticamente e regolarmente controlli prestabiliti su un sito web. Un Controllo In particolare, descrive tra l’altro l’obiettivo, il calendario, i punti di misurazione e i criteri di successo. Ogni esecuzione in un punto di misurazione genera un risultato a sé stante: la configurazione non è quindi equiparabile a una singola misurazione.

Un test di prestazione globale effettuato una sola volta, invece, fornisce solo un’istantanea delle condizioni di quella corsa. Ripetuto Monitoraggio del sito web mette in evidenza se una discrepanza si ripresenta e come si evolvono i risultati nel tempo. Affinché tali confronti siano significativi, l’obiettivo, l’ambiente di misurazione e l’ubicazione devono rimanere identificabili.

Un punto di misurazione pubblico in un data center cloud verifica il sito web da una determinata regione e infrastruttura. Tuttavia, la sua connessione non corrisponde automaticamente a una connessione Internet privata in loco. Il routing, la latenza di rete e la distanza dall’infrastruttura di distribuzione possono influenzare il risultato; una velocità ridotta descrive quindi, in primo luogo, questo specifico percorso di misurazione.

A prova privata risponde a un’altra domanda: permette di verificare se un’applicazione è raggiungibile da una rete privata. Ciò è rilevante, ad esempio, per i servizi interni, ma non dimostra la loro raggiungibilità dall’Internet pubblico. Viceversa, un controllo pubblico andato a buon fine non indica se l’accesso funzioni da qualsiasi rete aziendale.

Ai fini della pianificazione, vale quindi la pena formulare ogni verifica come una domanda concreta: la pagina del prodotto è accessibile da un’importante regione di destinazione e in quella pagina viene visualizzato il contenuto previsto? La risposta è valida per i punti di misurazione e le condizioni di test selezionati. Si tratta di un’indicazione riproducibile, ma non di un quadro completo di tutti i visitatori e dei loro dispositivi.

HTTP, browser e percorsi

A Controllo HTTP interroga un endpoint e valuta, ad esempio, il codice di stato o la risposta. Nel caso di una pagina di prodotto, può rilevare rapidamente che il server non risponde come previsto. Se restituisce un codice HTTP 200, ciò significa solo che il criterio di risposta verificato è soddisfatto: resta da vedere se l'interfaccia sia visibile e funzionante.

Un "browser check" carica la stessa pagina di prodotto in un browser automatizzato. È in grado di verificare se compare un titolo previsto e di rilevare i valori relativi al browser. Se questo controllo fallisce, pur essendo lo stato HTTP corretto, vale la pena esaminare il rendering e il contenuto della pagina. Tuttavia, questa discrepanza di per sé non dimostra ancora una causa specifica dell’errore.

A Verifica del percorso va oltre il semplice caricamento della pagina ed esegue una serie di passaggi definiti. Ad esempio, durante la procedura di registrazione, apre la pagina di accesso, effettua l’accesso con un account di prova adeguato e infine verifica la presenza di un elemento previsto. Solo quest’ultimo criterio dimostra, per il flusso di lavoro testato, che non solo la pagina di accesso era raggiungibile.

Anche un percorso completato con successo conferma solo i passaggi effettivamente eseguiti e le condizioni soddisfatte. Una procedura di reimpostazione della password non testata o l’utilizzo di un altro browser potrebbero comunque causare problemi. Scegli quindi pochi processi importanti per l’azienda e definisci per ogni passaggio un risultato verificabile, invece di dedurre che l’intero servizio funzioni correttamente solo perché la pagina è stata caricata con successo.

Un controllo visivo supplementare può individuare alterazioni nell’aspetto che un semplice controllo dei singoli elementi non rileva. A tal fine è possibile, ad esempio, confrontare degli screenshot; le discrepanze devono poi essere valutate nel contesto, poiché non tutte le modifiche visibili costituiscono un errore. Ulteriori approcci sono descritti nell’articolo su Verifica visiva e controlli automatizzati del sito.

Distinguere correttamente i tempi di caricamento

„Senza ulteriori precisazioni, il termine “tempo di caricamento» non indica un parametro chiaramente comparabile. Quando si apre una pagina, ciò che interessa innanzitutto è il tempo che intercorre fino alla prima risposta del server: questo dato aiuta a valutare i ritardi prima dell’arrivo della risposta. Tuttavia, non indica ancora quando il browser abbia visualizzato qualcosa o abbia elaborato completamente la pagina.

Il primo rendering visibile descrive una fase successiva: il browser visualizza per la prima volta dei contenuti. Può trattarsi già di un breve testo o di un altro elemento iniziale, mentre il contenuto principale della pagina è ancora assente. Un inizio visibile in fase precoce non equivale quindi automaticamente a una pagina di prodotto immediatamente fruibile.

Il sito Il più grande contenuto di vernice (LCP) tiene conto della visualizzazione dell'elemento di contenuto più rilevante nell'area visibile. Nel caso di una pagina di prodotto, potrebbe trattarsi, ad esempio, dell'immagine grande del prodotto. Confronta l'LCP solo con valori LCP contrassegnati in modo corrispondente e registra le condizioni del browser e della rete; il tempo necessario per ottenere la risposta del server viene misurato in una fase diversa.

Il sito Durata della sceneggiatura non corrisponde automaticamente al tempo di caricamento di una singola pagina. Uno script può richiamare più pagine, attendere il caricamento di alcuni elementi ed eseguire un’autenticazione. Nei controlli del browser di Grafana-k6, la durata dello script indicata di solito non include la fase di avvio di k6; anche tali limiti dello strumento devono essere tenuti in considerazione nell’interpretazione.

L'Interaction to Next Paint, abbreviato INP, riguarda la risposta alle interazioni. Un flusso sintetico può analizzare solo le interazioni che effettivamente esegue. Un clic automatizzato in condizioni prestabilite non fornisce quindi una distribuzione delle esperienze di tutti i visitatori reali che utilizzano dispositivi, connessioni e percorsi di navigazione diversi.

Piano di monitoraggio per le regioni target

Inizia il piano di monitoraggio con le pagine e i flussi la cui interruzione avrebbe un impatto significativo sulla tua attività. Potrebbe trattarsi di una pagina di prodotto, della procedura di registrazione o di un’interfaccia. Scegli quindi le aree di monitoraggio in base ai tuoi mercati di riferimento: una sede aggiuntiva è particolarmente utile se copre un’area di utenza importante o integra un monitoraggio regionale già esistente.

Per un controllo analogo Registra il browser e la versione, la modalità di visualizzazione del dispositivo, le condizioni di rete e lo stato della cache. Documenta inoltre l'intervallo e il limite di tempo, nonché la risposta prevista o l'elemento visibile. In questo modo sarà possibile verificare in seguito se una discrepanza potrebbe coincidere con una modifica dell'ambiente di misurazione.

La tabella seguente è un esempio concettuale, non un piano operativo basato su dati misurati né generalmente raccomandato. Devi adattare gli intervalli e le condizioni di allarme in base all'importanza del tuo sito web e alle possibilità offerte dal servizio scelto.

La tabella è solo il punto di partenza: nella configurazione del controllo, inserisci il limite di tempo specifico e le altre condizioni di misurazione. Un allarme regionale rimane comunque utile anche se altre sedi segnalano che tutto è a posto. Tieni presente che un punto di misurazione nel cloud non rappresenta automaticamente una connessione Internet privata nella stessa regione.

Configurazione dei controlli e delle procedure di test

Per una tua pagina di test, puoi innanzitutto creare un controllo HTTP che verifichi il codice di stato previsto. Aggiungi poi un controllo del browser che apra la stessa pagina e verifichi la presenza di un’intestazione prevista. Il primo controllo verifica la risposta dell’endpoint; il secondo fornisce inoltre un’indicazione sul fatto che il contenuto previsto venga visualizzato nel browser.

Per ogni esecuzione, registra il punto di misurazione, l'ora, il risultato e la durata pertinente. Se il controllo del browser fallisce nonostante il controllo HTTP abbia avuto esito positivo, esamina il contenuto e il rendering, invece di supporre immediatamente un errore specifico. Verifica inoltre se il titolo è stato modificato intenzionalmente o se il limite di tempo impostato era troppo breve.

Per effettuare una registrazione, clicca su un Journey la richiesta al browser per l'inserimento dei dati e una verifica dopo il login. Utilizza un account di prova separato con il minor numero possibile di autorizzazioni e verifica un elemento stabile e non personale nell'area riservata agli utenti registrati. Il semplice caricamento della pagina di login non è di per sé sufficiente a confermare che la procedura di accesso funzioni correttamente.

Scegliere selettori robusti e attendi in modo mirato i contenuti previsti, invece di affidarti esclusivamente a una pausa fissa. Salva le credenziali di accesso nella sezione "Segreti" del servizio utilizzato e non nello script o nei log. Dopo aver apportato modifiche all'interfaccia, verifica che i selettori e i criteri di successo siano ancora in linea con il flusso previsto.

Limita le procedure di test ad azioni sicure: un percorso eseguito regolarmente non deve generare ordini o pagamenti reali. Se un’operazione di scrittura è inevitabile, è necessario un ambiente di test espressamente previsto a tale scopo o un processo di test controllato. Stabilisci inoltre chi è incaricato di analizzare un'esecuzione fallita e di gestire i dati di test.

Confrontare strumenti e modelli operativi

Nella scelta dello strumento, occorre distinguere tra un servizio di monitoraggio gestito e uno strumento che, in una prima fase, esegue solo un test. Il fattore decisivo non è solo il supporto di un browser: sono necessarie anche sedi adeguate, un’esecuzione regolare, l’archiviazione dei risultati e un sistema di allerta che si adatti alle tue esigenze operative.

Grafana Cloud Monitoraggio sintetico collega le configurazioni di controllo a probe pubbliche e private e supporta i controlli del browser basati su k6. I punti di monitoraggio pubblici e privati rispondono a diverse esigenze di verificabilità. Verifica in anticipo anche le frequenze di controllo disponibili: i controlli del browser e degli script sono soggetti a limiti diversi rispetto ad alcuni semplici controlli degli endpoint.

Quello eseguito localmente Modulo browser k6 Va considerato separatamente. Per farlo, ti servono k6 e un browser basato su Chromium; l'esecuzione di uno script locale non configura automaticamente né i punti di monitoraggio regionali né una pianificazione permanente. Per il monitoraggio distribuito, dovresti organizzare separatamente l'esecuzione, l'infrastruttura e la gestione dei risultati oppure utilizzare un servizio adeguato.

AWS CloudWatch Synthetics esegue i "canary" pianificati. Il Funzionalità multilocalità Replica un Canary in regioni AWS selezionate e aggrega i risultati in una regione primaria. Prima dell'implementazione, verifica le versioni minime documentate per i runtime Node.js Puppeteer o Playwright supportati, nonché la disponibilità regionale specifica di questa funzione.

I sensori gestiti autonomamente ti offrono un maggiore controllo sulla posizione e sull’ambiente circostante, ma richiedono anche manutenzione, aggiornamenti e monitoraggio dell’infrastruttura di misurazione. Confronta, per tutti i modelli operativi, le ubicazioni effettivamente offerte, i costi legati all’utilizzo e le condizioni relative alla conservazione dei dati. Verifica in particolare dove vengono salvati screenshot e registri e se ciò è conforme alle tue norme sulla protezione dei dati.

Valutare in modo mirato i risultati regionali

Confronta i risultati regionali relativi alla stessa pagina e allo stesso periodo. Il browser, la versione, le condizioni di rete e lo stato della cache devono coincidere; in caso contrario, l’eventuale differenza potrebbe essere dovuta all’ambiente di misurazione piuttosto che alla distribuzione. Inoltre, un punto di misurazione cloud rappresenta una specifica ubicazione e un percorso di rete, non tutte le connessioni di una regione.

Per misurazioni ripetute con esito positivo, il Mediano il valore mediano dei risultati ordinati. Un percentile superiore, ad esempio il 95° percentile, mette in evidenza le esecuzioni più lente: il 95% dei valori considerati non supera questo valore. Annota il periodo di tempo e il numero di misurazioni, in modo che rimanga chiaro quanto sia ampia l'analisi.

Quando il numero di esecuzioni è esiguo, una singola esecuzione lenta può influenzare notevolmente il percentile superiore. Verifica quindi l’andamento temporale e confronta diverse finestre di misurazione prima di ipotizzare un peggioramento regionale persistente. Anche un cambiamento del punto di misurazione o della versione del browser va considerato come un possibile fattore di variazione nell’analisi.

Fermati corse fallite visibili separatamente, ad esempio come numero di errori e percentuale sul totale delle esecuzioni. Una statistica sui tempi di caricamento che includa solo le chiamate andate a buon fine potrebbe altrimenti far apparire erroneamente positiva una regione in cui si verificano frequenti timeout. In caso di errore senza un valore valido per il tempo di caricamento, non è possibile inserire semplicemente un tempo di caricamento normale.

Il Real User Monitoring integra i test controllati con le esperienze dei visitatori reali. Il Chrome UX Report fornisce dati sul campo disponibili su una finestra mobile di 28 giorni; non tutte le pagine o tutti i gruppi di utenti sono coperti da tale report. Questa visione a lungo termine non sostituisce quindi un allarme sintetico aggiornato, né può essere equiparata direttamente a una singola prova.

Allarmi e ricerca dei guasti a livello regionale

A allarme globale può raggruppare gli errori ricorrenti di più sedi. Ciò aiuta a distinguere un incidente di ampia portata da un malfunzionamento isolato di un punto di misurazione. Definisci al contempo una condizione di allarme regionale: se un mercato di riferimento importante subisce un’interruzione, il successo delle altre regioni non deve nascondere il problema.

Scegli il numero di ripetizioni e l'intervallo di tempo in base all'importanza del processo. Diversi test falliti consecutivamente possono compensare picchi temporanei, ma ritardano la segnalazione. Controlla anche i punti di misurazione stessi e verifica se un campione è difettoso o se anche altri test della stessa sede sono interessati dal problema.

Se una pagina di prodotto è lenta solo in una determinata località, inizia confrontando sessioni simili e individuando il momento in cui si è verificata la discrepanza. Esamina quindi la risoluzione DNS, la distribuzione CDN, i tempi di caricamento delle risorse e la risposta del server. I diversi percorsi di rete e la vicinanza all’infrastruttura possono influenzare i livelli di riferimento regionali; il valore misurato da solo non identifica ancora una causa.

Per le risorse provenienti da altre origini, i dettagli relativi alla misurazione del browser potrebbero essere limitati. Senza un appropriato Timing-Allow-Origin- Alcuni valori dell'API Resource Timing possono essere pari a zero. Ciò non significa automaticamente che la connessione fosse estremamente veloce; verifica innanzitutto quali dati il server esterno renda disponibili per la misurazione.

Per il livello di analisi successivo, associa l'ora, la regione e il processo interessato ai log e alle tracce disponibili. In questo modo è possibile, ad esempio, individuare una richiesta lenta senza trarre conclusioni affrettate sulla causa da una semplice correlazione. L'articolo su spiega come interagiscono tra loro metriche, log e tracce Osservabilità nell'hosting.

Garantire un monitoraggio costante

Inizia con semplici controlli degli endpoint per le principali destinazioni accessibili pubblicamente e integra percorsi mirati nel browser per le pagine o le procedure di accesso fondamentali per l’azienda. Un controllo HTTP può essere eseguito con maggiore frequenza, mentre il test del browser, più complesso, verifica funzioni selezionate. Gli intervalli vanno stabiliti in base al tempo di rilevamento desiderato, ai limiti del servizio e ai costi, non in base a un valore forfettario in minuti.

Per ogni controllo, determina un Competenza: Chi riceve l'allarme, chi verifica il servizio interessato e chi si occupa del punto di misurazione? Indica anche quando viene inoltrato un allarme e dove si possono trovare i relativi risultati. Un controllo che non comporta alcuna reazione a errori ripetuti fornisce sì dei dati, ma non risolve l'incidente.

Dopo aver apportato modifiche all'interfaccia, verifica che i selettori e i contenuti previsti siano ancora compatibili con il flusso di esecuzione. Nello script, attendi l’elemento richiesto, invece di affidarti esclusivamente a un ritardo fisso. Documenta le modifiche apportate al browser, al profilo di rete o alle impostazioni della cache, in modo che i confronti successivi non mescolino inavvertitamente condizioni di misurazione diverse.

Considera gli screenshot e i log come dati potenzialmente sensibili: potrebbero contenere il contenuto di una sessione o informazioni provenienti dall’applicazione. Limita l’accesso e la conservazione in base allo scopo e verifica cosa viene effettivamente registrato durante il test. Per gli accessi, utilizza un account di test con funzionalità limitate e gestisci le credenziali come «secrets» anziché inserirle nello script.

Controlla regolarmente se Siti di misurazione se sono ancora adeguati ai tuoi mercati di riferimento e se le tariffe, la gestione dei dati e i requisiti di protezione dei dati consentono ancora il funzionamento. Nel caso di ambienti di prova gestiti in proprio, si aggiungono l’aggiornamento e il monitoraggio dell’ambiente. Uno script del browser k6 avviato localmente non costituisce di per sé un’infrastruttura di monitoraggio distribuita in modo permanente.