Una pagina di monitoraggio degli ordini impiega molto tempo a rispondere. La vostra applicazione non segnala errori, ma l’utente è ancora in attesa. Il ritardo deriva dal server, da una decisione di cache o da un passaggio intermedio? Cloudflare Traces, annunciato in beta il 2 ottobre 2026, permette di esaminare ulteriori fasi. Per trarne una diagnosi, è ancora necessario collegare le osservazioni al percorso corretto.
Iniziare con una richiesta che potete riconoscere
Prendiamo un'applicazione fittizia dietro Cloudflare. Un browser richiede una pagina, la richiesta attraversa la piattaforma e poi raggiunge il server dell’applicazione, chiamato origine. Questo server può consultare un database o un servizio esterno prima di rispondere. Ogni livello vede solo una parte del lavoro.
Un registro applicativo può indicare che una pagina è stata servita senza spiegare un'attesa verificatasi prima del suo arrivo. Al contrario, un indicatore di rete non mostra necessariamente quale operazione dell'applicazione abbia richiesto tempo. Una traccia raccoglie le fasi legate a una stessa richiesta. Ogni fase osservata, spesso chiamata span, specifica un'operazione e la sua posizione nel percorso.
Per ragionare, iniziate con una richiesta sintetica di cui controllate il contenuto. Annotate il percorso utilizzato, l’orario di emissione e gli elementi che permettono di ritrovarlo. Separate le osservazioni dalle ipotesi: «l’origine ha ricevuto la richiesta» è un’osservazione; «la base rallenta la pagina» resta un’ipotesi finché nulla dimostra questo lavoro.
La vostra scheda di diagnosi deve poter contenere delle caselle vuote. Uno strato mancante può corrispondere a una parte non strumentata o non conservata. Non dimostra che lì non sia avvenuta alcuna operazione. Questo principio è utile anche con uno strumento di supervisione già installato: il nome di una visualizzazione non garantisce mai l'estensione della prova.
Gli annunci del 2 ottobre, con i loro stati
Cloudflare Traces è stato annunciato in beta aperta il 2 ottobre. L'editore descrive un percorso che copre le operazioni supportate di sicurezza, trasformazione, cache, instradamento, di Workers e di trattamento dell'origine. Annuncia la propagazione del contesto W3C traceparent, il campionamento e un'esportazione compatibile OTLP, il protocollo di trasmissione di OpenTelemetry. La copertura non deve essere estesa a tutti i prodotti per deduzione. Annuncio Cloudflare Traces.
Lo stesso giorno, Cloudflare ha presentato otto evoluzioni di Observability, tra cui uno spazio comune per i log, un'API SQL unificata e avvisi in beta. Le query incrociate tra più set di dati sono ancora previste per un secondo momento. Il nuovo modello tariffario è previsto a partire dal 1° dicembre 2026, con applicazione al rinnovo per Enterprise. Annuncio Osservabilità.
| Elemento annunciato | Ciò che bisogna ricordare il 6 ottobre |
|---|---|
| Cloudflare Traces | Beta aperta; controllare le operazioni effettivamente visibili |
| SQL e nuovi avvisi | Beta da qualificare secondo il vostro account e il vostro utilizzo |
| Incrocio tra set di dati | Capacità futura, da non supporre disponibile |
| Tariffazione unificata | Scadenza annunciata a dicembre, con modalità Enterprise |
Questa tabella riassume gli stati annunciati, non un inventario testato su un account Partitech. Serve a scegliere ciò che il vostro pilota dovrà confermare. Evitate di costruire una procedura d’incidente attorno a una funzionalità ancora futura.
Collegare gli strati senza inventare ciò che non mostrano
Il contesto di tracciamento è un'informazione trasmessa tra servizi per riconoscere un percorso comune. OpenTelemetry fornisce un insieme di convenzioni e strumenti per strumentare un'applicazione, cioè farle descrivere le sue operazioni. Un formato comune facilita il confronto; non crea automaticamente le osservazioni mancanti all'interno del vostro codice.
Per un'applicazione Symfony o Laravel, cercate prima ciò che è già strumentato: ingresso della richiesta, accesso al database, chiamata esterna, coda asincrona. Fate una mappa semplice dei confini: browser verso piattaforma, piattaforma verso applicazione, applicazione verso dipendenze. Per ogni passaggio, identificate chi accetta, trasmette o rinnova il contesto. Non aggiungete un secondo collettore prima di aver compreso il percorso esistente.
Un identificativo fornito da un chiamante non è un'identità autenticata. Nel nostro protocollo, non serve mai ad autorizzare un'azione né a selezionare il fascicolo di un cliente. Definite i confini in cui può essere ripreso un contesto esterno, i formati ammessi e le condizioni in cui si riparte con un contesto interno. Questa raccomandazione di architettura deve essere adattata alla vostra reale strumentazione.
Esaminate anche i rami asincroni. Se la pagina avvia un lavoro dopo aver risposto, la sua durata non deve essere confusa con quella dell'attesa nel browser. Il collegamento tra le due operazioni può rimanere utile, ma bisogna spiegare cosa si sta misurando. Senza questa distinzione, un lungo compito secondario rischia di diventare una falsa spiegazione della lentezza della pagina.
Scegliere i dati prima di scegliere il volume
Una traccia ricca può contenere informazioni di cui la diagnostica non ha bisogno. Per la nostra pagina fittizia, mantenere un percorso normalizzato come « monitoraggio ordine » è spesso più utile che conservare un URL completo con identificativo personale e parametri. Il nome dell’operazione può bastare senza il suo contenuto operativo.
Scrivete un elenco di campi consentiti e un elenco di esclusioni: segreti, cookie, intestazioni di autenticazione, contenuto dei moduli e corpo delle risposte. Verificate cosa viene raccolto automaticamente, cosa viene aggiunto dal vostro codice e cosa viene inviato verso la destinazione di esportazione. La pulizia sullo schermo non garantisce che l’esportazione sia anch’essa pulita.
Il campionamento consiste nel trattenere una parte delle richieste. Cercate un compromesso tra osservazioni utili, volumi e costi. In condizioni normali, fissate una regola comprensibile. Durante un'indagine, potete proporre una raccolta più mirata su un percorso sintetico o un traffico di prova. Cloudflare annuncia precisamente delle regole che permettono di modificare la selezione delle richieste tracciate. Campionamento e Regole di Traccia.
Una regola temporanea deve avere un proprietario, una data di ritiro e una giustificazione. Altrimenti l’incidente termina, ma la raccolta estesa continua. Definite anche chi può leggere le tracce, per quanto tempo rimangono accessibili e chi può attivare un’esportazione. Queste sono scelte operative; nessun livello di conformità viene dedotto qui dall’adozione di un formato tecnico.
Tre percorsi sintetici da confrontare
La nostra proposta di qualificazione inizia con tre richieste su un'applicazione di dimostrazione. La prima utilizza una risposta che avete progettato per provenire dalla cache. La seconda si collega all'origine. La terza attiva un'operazione interna volutamente distinta, ad esempio una chiamata a un servizio fittizio. Nessun account cliente, nessun ordine reale e nessuna latenza misurata sono forniti in questo articolo.
Per ogni percorso, verificate che il comportamento atteso sia effettivamente avvenuto: non chiamate una richiesta « cache » solo perché lo avete desiderato. Trovate poi la sua traccia, le fasi visibili e le osservazioni applicative associate. Un percorso non ritrovato deve essere spiegato dalle impostazioni, dalla copertura o da un'ulteriore indagine; non consideratelo automaticamente come un successo.
| Campo della scheda | Osservazione da compilare durante la prova |
|---|---|
| Richiesta sintetica | Percorso, ora e variante di test |
| Correlazione | Identificativo o prova che collega gli strati |
| Fasi visibili | Operazioni trovate in ogni strumento |
| Fasi assenti | Strumentazione o selezione da verificare |
| Ipotesi | Spiegazione prevista dell'attesa |
| Prova | Osservazione che conferma o confuta l'ipotesi |
Ripetete i percorsi con la regola normale e poi con la regola mirata. Rilevate i volumi generati e la proporzione di percorsi ritrovati nelle condizioni del test. Ispezionate alcuni export per confermare l’assenza dei campi esclusi. Queste misure permetteranno di decidere; la semplice visualizzazione di una traccia non sarà sufficiente per qualificare la diagnosi.
Passare dallo schema a una procedura operativa
Il prossimo passo è una scheda utilizzabile durante un incidente: dove cercare la richiesta, quali livelli confrontare e chi può ampliare temporaneamente la raccolta. Fatela rileggere da una persona che non ha preparato il pilota. Se non riesce a trovare una richiesta di test con queste istruzioni, migliorate la procedura prima di estendere il perimetro.
Preparate anche la reversibilità. Sapete rimuovere una regola, disattivare un export e conservare solo le prove necessarie per l’analisi. Stimate la conservazione e i volumi in base all’uso osservato, quindi riesaminate questa stima avvicinandovi alla scadenza tariffaria annunciata. Le condizioni dell’offerta possono evolvere durante la beta.
La scelta favorevole a Cloudflare Traces si basa su una correlazione dimostrata tra gli strati utili alla vostra applicazione, una raccolta controllata e una procedura comprensibile. Se le operazioni decisive restano assenti, migliorate la strumentazione prima di sperare in una diagnosi migliore. Lo strumento offre un nuovo perimetro di osservazione; il vostro team trasforma queste osservazioni in prove utilizzabili.
Fonti e data di verifica
Fonti primarie aperte il 6 ottobre 2026: Cloudflare Osservabilità e Cloudflare Traces, pubblicate il 2 ottobre. Il percorso fittizio, la scheda e le regole proposte costituiscono un metodo originale, senza esperimento eseguito né guadagno di risoluzione misurato.