Le interruzioni di Cloudflare, gli errori della CDN regionale e i degradi a livello di edge non vengono sempre visualizzati nelle pagine di stato. Quando il POP Tokyo del tuo CDN non funziona ma il suo stato globale appare verde, il tuo monitoraggio dalla Virginia non lo rileverà.
Il rilevamento delle interruzioni a livello regionale richiede il monitoraggio da dove si trovano effettivamente gli utenti, non solo da dove si trova la tua infrastruttura.
Sono le 3 del mattino. Il tuo tecnico di guardia viene contattato dal successo del cliente: "Tre clienti aziendali a Singapore hanno riferito di non poter accedere all'app. Avviata circa due ore fa."
Controlli la dashboard di monitoraggio: tutto verde. Pagina di stato di Cloudflare: operativa. AWS: nessun incidente. Il tuo APM: piccoli grafici felici. Quindi chiedi ai clienti di riprovare, svuotare la cache, controllare la propria rete.
Ma continua a succedere. Più biglietti dalla stessa regione. Alla fine, qualcuno esegue un traceroute da un VPS di Singapore e scopre: il traffico sta raggiungendo un edge Cloudflare che restituisce 502. La CDN ha un'interruzione regionale che interessa un PoP e non c'è nulla nel tuo stack di monitoraggio che controlli da quella regione.
Due ore di inattività. Per una geografia specifica. Zero avvisi. Questo è il punto cieco di cui parla questa pagina.
Che si tratti di un'interruzione di Cloudflare, di un guasto Fastly Edge o di un degrado regionale di Akamai, il rilevamento di questi problemi richiede il monitoraggio da parte delle regioni interessate. In questo modo è possibile individuare i problemi prima che diventino un'escalation da parte dei clienti.
Internet non è un’unica rete. Una richiesta da Sydney viaggia attraverso un'infrastruttura completamente diversa rispetto a una richiesta da Francoforte. Quando qualsiasi parte di quel percorso regionale fallisce, solo gli utenti di quella regione ne sono interessati.
CDN come Cloudflare, Fastly e Akamai gestiscono centinaia di punti di presenza (PoP) a livello globale. Quando un server edge o un PoP specifico riscontra problemi (guasto hardware, configurazione errata o problemi di capacità), vengono interessati solo gli utenti instradati a quell'edge. Lo stato globale della CDN rimane "operativo" perché il 95% dei bordi va bene.
Esempio: nel giugno 2022, Cloudflare ha subito un'interruzione di 30 minuti che ha interessato 19 data center a causa di una modifica della configurazione di rete. Gli utenti in quelle regioni hanno riscontrato errori; gli utenti altrove non hanno riscontrato nulla di insolito.
Il DNS è il primo passo in qualsiasi richiesta. Quando la versione 1.1.1.1 di Cloudflare o i server DNS del tuo CDN riscontrano problemi in una regione specifica (un percorso anycast configurato in modo errato, un server dei nomi sovraccarico), gli utenti in quella regione non possono risolvere il tuo dominio. Il loro browser mostra semplicemente "DNS_PROBE_FINISHED_NXDOMAIN".
Esempio: i problemi DNS regionali possono essere causati da filtri a livello di ISP, problemi di risoluzione locale o problemi di routing anycast che interessano solo determinate aree geografiche.
Perdite di percorso BGP, dirottamenti e configurazioni errate possono reindirizzare il traffico attraverso percorsi non ottimali o bloccarlo completamente. Quando uno dei principali operatori di una regione presenta problemi di routing, il traffico da quella regione al tuo CDN o all'origine potrebbe non riuscire, anche se entrambi gli endpoint funzionano perfettamente.
Esempio: gli incidenti BGP colpiscono regolarmente migliaia di reti. Un singolo percorso AS configurato in modo errato può rendere il tuo sito irraggiungibile da interi paesi per ore mentre appare a posto dalla tua posizione di monitoraggio.
I principali ISP in paesi specifici potrebbero avere una connettività ridotta alla tua CDN a causa di controversie di peering, congestione o problemi infrastrutturali. Gli utenti di Telstra in Australia potrebbero riscontrare guasti mentre gli utenti di Optus nella stessa città non hanno problemi, perché il traffico scorre attraverso percorsi diversi.
Esempio: le controversie sul peering tra ISP e fornitori di servizi cloud hanno storicamente causato peggioramenti che durano più settimane, colpendo milioni di utenti in mercati specifici.
Il filo conduttore: tutti questi errori hanno un ambito geografico. La tua origine è attiva. La configurazione della tua CDN è corretta. Ma da qualche parte tra il tuo perimetro e gli utenti in una regione specifica, qualcosa si è rotto e il tuo monitoraggio che controlla da una posizione in Virginia non ha modo di rilevarlo.
La maggior parte del monitoraggio del tempo di attività è stato progettato per un problema più semplice: "Il server risponde?" Per i siti accelerati da CDN che servono utenti globali, questa non è più la domanda giusta.
La maggior parte dei servizi di monitoraggio effettuano per impostazione predefinita il controllo da una manciata di località degli Stati Uniti o dell'UE. Se il PoP di Singapore di Cloudflare fallisce, il tuo controllo dall'Oregon avrà comunque successo: raggiunge un vantaggio diverso e sano. Nel frattempo, i tuoi utenti APAC visualizzano errori 502.
L'esecuzione dei controlli da AWS a Cloudflare utilizza la connettività backbone cloud: percorsi ottimizzati che non rappresentano il traffico utente reale. Il tuo controllo sintetico da AWS ap-southeast-1 potrebbe ignorare l'esatto percorso di rete che non funziona per gli utenti sugli ISP locali.
Le pagine di stato della CDN riflettono la loro visione interna, spesso aggregata su centinaia di PoP. Un problema regionale che interessa il 5% delle loro infrastrutture potrebbe non innescare un aggiornamento della pagina di stato, ma quel 5% potrebbe includere tutto il Sud-est asiatico.
I controlli HTTP ti dicono se una richiesta è riuscita o meno, ma non dove è fallita. Senza i dati di traceroute e di suddivisione della latenza della regione interessata, non è possibile determinare se il problema è il DNS, un hop di rete specifico o il perimetro della CDN.
Cloudflare ha oltre 310 PoP. Se il tuo monitoraggio viene effettuato da 3 posizioni, stai verificando meno dell'1% dei bordi che i tuoi utenti potrebbero colpire. Non si tratta di rilevamento di interruzioni: si spera per il meglio.
Ogni minuto in cui un'interruzione di Cloudflare o un guasto della CDN regionale non viene rilevato, perdi utenti, entrate e fiducia in mercati che potresti non renderti nemmeno conto di servire.
Un'interruzione regionale durante l'orario lavorativo in quel fuso orario può costare ore di transazioni, iscrizioni o chiamate API. Gli utenti non inviano email del tipo "il tuo sito non è disponibile per me", ma se ne vanno e basta. In seguito vedrai un calo nelle metriche regionali, senza una chiara attribuzione della causa.
I clienti aziendali hanno degli SLA. Quando non possono accedere alla tua piattaforma e tu non sapevi nemmeno che c'era un problema, è una brutta conversazione. "Non abbiamo rilevato l'interruzione" non è una risposta che crea fiducia, soprattutto quando pagano per l'affidabilità.
Googlebot esegue la scansione da più località globali. Se il tuo edge CDN in una regione restituisce errori o risposte lente, ciò influisce sul budget di scansione, sulle valutazioni Core Web Vitals e, in ultima analisi, sulle classifiche. Potresti notare cali di traffico in mercati specifici senza una causa evidente.
Il tempo medio di ripristino (MTTR) inizia quando viene rilevato il problema. Se un'interruzione regionale di Cloudflare colpisce gli utenti per 2 ore prima che tu ne venga a conoscenza da un ticket del cliente, verranno aggiunte 2 ore al tuo MTTR effettivo. Il rilevamento proattivo è l'unico modo per ridurre al minimo l'impatto effettivo dei tempi di inattività.
Il rilevamento delle interruzioni a livello regionale richiede il monitoraggio dalla posizione degli utenti, con una diagnostica approfondita per identificare dove si verificano gli errori.
Ciascuna posizione di monitoraggio raggiunge diversi bordi CDN e attraversa percorsi di rete diversi. Per rilevare le interruzioni regionali, sono necessari nodi in ogni regione in cui si dispone di traffico significativo: Asia-Pacifico, Europa, Americhe, Medio Oriente, Africa. Non solo "internazionale", in particolare dove si trovano i tuoi utenti.
Il monitoraggio da oltre 50 sedi copre i principali PoP CDN e percorsi ISP.
Quando un controllo fallisce da Singapore ma ha esito positivo da qualsiasi altro posto, devi sapere: è DNS? Un salto di rete specifico? Il vantaggio della CDN? Traceroute e MTR dalla posizione interessata forniscono le prove necessarie per diagnosticare la causa principale e inoltrare il problema a Cloudflare, al tuo ISP o al tuo provider di hosting.
I dati diagnostici trasformano "qualcosa non funziona" in una causa principale attuabile.
400 ms da Tokyo sono normali o si tratta di un degrado dei bordi di Cloudflare? I dati storici per posizione creano linee di base che consentono di rilevare errori lenti: aumenti di latenza che non innescano errori gravi ma peggiorano l'esperienza dell'utente. Puoi rilevare un problema della CDN regionale prima che diventi un'interruzione completa.
Le linee di base rilevano i degradi prima che diventino interruzioni.
Una guida passo passo per implementare il monitoraggio che rileva le interruzioni di Cloudflare e gli errori della CDN regionale prima che gli utenti li segnalino.
Controlla le tue analisi per identificare dove si trovano i tuoi utenti. Se il 20% del traffico proviene dall’Asia-Pacifico, sono necessari più nodi di monitoraggio lì: Singapore, Tokyo, Sydney, Mumbai. Abbina la copertura del monitoraggio alla distribuzione effettiva degli utenti.
Configura i monitor HTTP per i tuoi URL primari che passano attraverso Cloudflare o la tua CDN. Questi dovrebbero colpire il bordo della CDN, non direttamente la tua origine. Includi il dominio dell'app, gli endpoint API e tutte le pagine pubbliche critiche.
Regioni diverse hanno latenze di base diverse. Configura soglie sensate: forse 500 ms dall'Europa sono accettabili, ma 500 ms dagli Stati Uniti orientali (quando la tua origine è lì) indica un problema di confine della CDN. Utilizza i dati storici per impostare linee di base realistiche.
Imposta avvisi che si attivano quando falliscono regioni specifiche, non solo quando falliscono tutte le posizioni. Un guasto solo a Singapore è comunque un'interruzione che vale la pena conoscere. Indirizza avvisi ad alta priorità a Slack, PagerDuty o al tuo sistema di gestione degli incidenti.
Quando viene attivato un avviso, devi determinare rapidamente: è questo il problema di Cloudflare? Un problema sul percorso di rete? DNS? Abilita traceroute e MTR su richiesta dalle posizioni di monitoraggio in modo da poter raccogliere immediatamente dati diagnostici.
Documentare il processo: come verificare un'interruzione regionale di Cloudflare. Dove controllare l'API di stato di Cloudflare. Come aprire un ticket con prove. Quali mitigazioni è possibile applicare (failover, bypass della cache e così via). Avere questo pronto riduce significativamente l’MTTR.
Imposta un promemoria settimanale del calendario per verificare la latenza e il tempo di attività per regione. Cerca modelli: l’APAC è costantemente più lenta? Ci sono segnali regolari in una posizione specifica? La revisione proattiva rileva i peggioramenti lenti prima che abbiano un impatto significativo sugli utenti.
Per i servizi in cui le interruzioni regionali sono inaccettabili, prendere in considerazione una strategia multi-CDN in cui il DNS può eseguire il failover tra provider. Ciò richiede il monitoraggio di ogni CDN in modo indipendente e la disponibilità di un'automazione in grado di commutare il traffico. È complessità, ma è resilienza.
Latency Global è stato creato per rilevare esattamente questo tipo di problema: interruzioni di Cloudflare, errori CDN regionali e problemi di rete che il monitoraggio di una singola posizione non rileva. Monitoriamo da oltre 70 luoghi reali in 6 continenti, coprendo tutte le principali regioni PoP CDN.
Ogni controllo include un'analisi temporale completa: risoluzione DNS, connessione TCP, handshake TLS, TTFB e tempo di risposta totale. Quando qualcosa non funziona in una regione specifica, puoi eseguire traceroute e MTR da quella posizione per identificare esattamente dove si è verificato il problema nel percorso di rete. Il prezzo è semplice: $ 5/mese per 5 monitor, tutte le località incluse.
Il rilevamento delle interruzioni regionali richiede infrastrutture in molte località: ecco perché la maggior parte degli strumenti di monitoraggio non lo offrono o addebitano prezzi aziendali. Ci concentriamo su ciò che conta: copertura e profondità diagnostica.
Un'interruzione della rete CDN regionale si verifica quando specifici edge server o punti di presenza (PoP) in una rete CDN si guastano o si deteriorano, mentre altri edge rimangono operativi. Ad esempio, Cloudflare potrebbe avere problemi con il PoP di Singapore mentre i suoi confini statunitensi ed europei funzionano bene. Gli utenti che instradano attraverso il perimetro interessato riscontrano errori o rallentamenti delle prestazioni; gli utenti altrove non si accorgono di nulla. Queste interruzioni sono invisibili al monitoraggio che controlla solo le regioni non interessate.
Le pagine di stato della CDN in genere mostrano lo stato globale aggregato, non l'integrità per PoP. Quando è interessato il 5% dei bordi, lo stato generale potrebbe rimanere "Operativo" perché il 95% dell'infrastruttura funziona. Anche le pagine di stato hanno una latenza di aggiornamento: ci vuole tempo perché i problemi vengano rilevati, verificati e pubblicati. Inoltre, alcuni problemi non raggiungono la soglia per la divulgazione pubblica ma interessano comunque i tuoi utenti. Il monitoraggio indipendente da più sedi è l'unico modo per ottenere dati concreti sulla disponibilità regionale.
Come minimo, è necessario monitorare le posizioni in tutte le principali regioni in cui sono presenti utenti: Nord America, Europa e Asia-Pacifico come minimo. Per una migliore copertura, oltre 50 località distribuite a livello globale cattureranno la maggior parte dei problemi regionali. La chiave è abbinare la copertura del monitoraggio alla geografia del tuo utente: se il 30% dei tuoi utenti si trova nell'APAC, avrai bisogno di più nodi lì (Singapore, Tokyo, Sydney, Mumbai). Non si tratta di abbinare ogni PoP CDN, ma di coprire i principali raggruppamenti regionali.
Innanzitutto, raccogli prove diagnostiche: traceroute e MTR dalla posizione interessata, codici di risposta HTTP, dati temporali e timestamp. Controlla la pagina di stato di Cloudflare e Twitter per eventuali riconoscimenti. Se si tratta chiaramente di un problema di Cloudflare, apri un ticket di supporto con le tue prove. Per una mitigazione immediata, prendi in considerazione: bypassare temporaneamente Cloudflare per la regione interessata (se la tua origine è in grado di gestirlo), abilitare un CDN di backup se disponi di funzionalità multi-CDN o aggiornare la pagina di stato per riconoscere il problema mentre Cloudflare lo risolve. Documentare tutto per la revisione post-incidente.
Sì, con un'adeguata strumentazione di monitoraggio. I tempi del controllo HTTP completo mostrano: tempo di risoluzione DNS (se il DNS non funziona o è lento, si tratta di un problema DNS), tempo di connessione TCP (problemi relativi al percorso di rete), tempo di handshake TLS (problemi di certificato o crittografia) e tempo di risposta/TTFB (problemi di elaborazione di origine o edge). Traceroute mostra il percorso di rete e il punto in cui i pacchetti vengono eliminati o ritardati. Confrontando questi dati della regione interessata con quelli delle regioni sane, puoi identificare esattamente dove si verifica l'errore nella catena di richieste.
Con intervalli di controllo di 1 minuto, puoi rilevare un'interruzione entro 1-2 minuti dal suo inizio. La maggior parte dei servizi di monitoraggio conferma un'interruzione dopo 2-3 guasti consecutivi per evitare avvisi in caso di segnali transitori, quindi il tempo di rilevamento realistico è di 2-5 minuti. Confronta questo con le interruzioni segnalate dai clienti, che potrebbero richiedere ore per emergere attraverso i ticket di supporto. La differenza nell'MTTR è significativa: 5 minuti contro 2 ore significano un impatto sull'utente molto diverso.
Assolutamente. Akamai, AWS CloudFront, Google Cloud CDN, Azure CDN e qualsiasi altra rete CDN possono rapidamente riscontrare interruzioni a livello regionale. Si applicano gli stessi principi: le CDN hanno un’infrastruttura distribuita e qualsiasi sistema distribuito può presentare guasti parziali. L'approccio di rilevamento è lo stesso: monitora da più posizioni globali per individuare problemi che interessano bordi o regioni specifici, indipendentemente dalla CDN utilizzata.
Smetti di fare affidamento sulle pagine di stato della CDN e sui ticket dei clienti per conoscere le interruzioni regionali. Aggiungi i tuoi endpoint, seleziona le posizioni di monitoraggio e scopri in pochi minuti quando Cloudflare, Fastly o qualsiasi parte del tuo stack fallisce in qualsiasi regione.
$ 5/mese • Oltre 70 sedi (+40 a breve) • Nessun contratto • Annulla in qualsiasi momento