Monitoraggio URL con Datadog: metriche dei redirect dei link

Il monitoraggio URL con Datadog per i link corti di Elido viene da due fonti. Elido stesso invia i dati dei clic: un log per clic all'intake dei Datadog Logs, più tre metriche di conteggio dei clic inviate ogni 60 secondi. Non invia la latenza dei redirect né i codici di stato. Per quelli punti un test HTTP di Datadog Synthetics su un link corto canary, e la dashboard di latenza dei redirect, i monitor e l'SLO poggiano tutti su quella coppia.

Questa divisione è l'intero design. Il lato clic ti dice quante persone sono passate dai tuoi link e da dove, e il lato sintetico ti dice se il redirect ha risposto, quanto in fretta e con lo stato giusto. Questo articolo copre le forme esatte di metriche e log, come collegarli, cosa mettere sulla dashboard e dove si ferma.

Se sei qui per la latenza, leggi prima come funziona il budget p95 sotto i 15ms. Spiega che aspetto ha un numero sano prima di scegliere una soglia.

Cosa invia davvero Elido a Datadog

Ogni clic in un workspace collegato prende due percorsi. Il percorso dei log invia un batch a voce singola a https://http-intake.logs.<site>/api/v2/logs, subito dopo la registrazione del clic. Il percorso delle metriche incrementa un contatore in memoria, e un flusher invia i conteggi a https://api.<site>/api/v2/series una volta al minuto. Entrambi si autenticano con l'header DD-API-KEY.

Le metriche sono gauge, e il valore è il numero di clic contati dall'ultimo invio. Quindi un punto di 37 significa 37 clic nell'ultimo minuto circa. È l'unità naturale per un grafico operativo, e significa che per i totali si somma nel tempo anziché applicare as_count(). Nota cosa manca: non c'è alcun tag link_id o slug sulle metriche. La definirei una scelta sensata sul costo, perché Datadog fattura le metriche personalizzate per combinazione unica di tag, e un tag slug su un workspace trafficato moltiplicherebbe il numero di serie per il numero di link.

Il log porta link_id anche come tag Datadog, ed è taggato service:click-ingester con host elido-edge, quindi è quello il nome del servizio su cui filtrare. I campi arrivano annidati sotto un oggetto attributes, quindi in Log Explorer le faccette appaiono come @attributes.slug e @attributes.country. Espandi un log prima di costruire qualsiasi cosa. Dieci secondi, e ti risparmia una query rotta.

Collegare Datadog nel tuo workspace Elido

La configurazione richiede due campi. Ti serve una chiave API di Datadog (non una application key) e il sito su cui gira la tua organizzazione.

1. In Datadog, apri Organization Settings, poi API Keys, e creane una chiamata per esempio elido-forwarder.
2. Controlla il tuo sito. La guida ai siti Datadog associa ogni URL di login al suo sito; app.datadoghq.eu significa che inserisci datadoghq.eu, us5.datadoghq.com significa che inserisci esattamente quello.
3. In Elido, apri Integrazioni, scegli Datadog, incolla la chiave, digita il sito e salva. La chiave è cifrata a riposo.
4. Attendi fino a cinque minuti, perché il forwarder mette in cache le impostazioni di integrazione del workspace, poi clicca uno dei tuoi link da un telefono e cerca source:elido in Log Explorer.

Lascia il sito vuoto ed Elido assume datadoghq.com. Per un'organizzazione UE, è il classico fallimento silenzioso. Un refuso fa lo stesso. Ogni POST fallisce e nessuno vede l'errore.

Il pulsante Test connection invia un log di prova (marcato elido_test: true) al tuo sito Datadog e mostra la risposta di Datadog, quindi una chiave o un sito sbagliati falliscono subito lì con il 403 di Datadog. Un esito positivo dimostra che la chiave funziona, non che le tue pipeline e i tuoi indici conservino i log, quindi la vera prova resta un log di clic che compare. Stessa regola del forwarder di clic per Mixpanel: clic reale, o non è successo.

Costruire una dashboard di latenza dei redirect che misuri il salto

Dato che Elido non invia i tempi, i dati di latenza devono venire da qualcosa che effettua richieste. Un test HTTP di Datadog Synthetics è lo strumento giusto, e misura ciò che sente il visitatore, DNS e TLS inclusi.

Ecco il test che configuro su ogni workspace:

• URL: un link canary dedicato, idealmente sul tuo dominio personalizzato, che punti a qualcosa di noioso e stabile.
• Seguire i redirect: disattivato. Se è attivo, stai cronometrando la tua landing page, e una hero image lenta ti sveglierà alle 3 di notte per un redirect che andava bene.
• Asserzioni: il codice di stato è 302 (il predefinito; usa 301 o 307 se è ciò che hai impostato, e 301 vs 302 spiega il compromesso), l'header location contiene la tua destinazione e il tempo di risposta è sotto una soglia.
• Località: almeno tre, con una nella regione UE in cui si trova il tuo pubblico. Esegui ogni minuto.
• Header: un User-Agent contenente bot, in modo che Elido tratti la sonda come un bot e salti l'evento del clic.

Scegli la soglia da ciò che osservi per una settimana, non da un articolo di blog. I tempi sintetici includono il percorso di rete della sonda stessa, quindi una sonda su un altro continente non corrisponderà mai a un numero nella regione, e va bene così. Quello che vuoi è una linea che resti piatta.

La dashboard ha poi bisogno di quattro widget. Tempo di risposta per località, come serie temporale del test sintetico. Tasso di successo delle asserzioni. Clic al minuto da elido.clicks. E una top list dei paesi.

# Clicks per minute across the workspace (gaps become zeros)
default_zero(sum:elido.clicks{workspace_id:42})

# Hourly click totals
sum:elido.clicks{workspace_id:42}.rollup(sum, 3600)

# Top 10 countries over the dashboard window
top(sum:elido.clicks_by_country{workspace_id:42} by {country}, 10, 'sum', 'desc')

Perché default_zero? Perché un minuto senza clic non produce alcun punto, e senza la funzione di interpolazione Datadog traccia una linea retta attraverso il vuoto. Quella linea mente.

Monitor per cali di clic e link corti rotti

Tre monitor coprono la maggior parte di ciò che va storto con i link, e ciascuno usa una fonte diversa, che è dove la divisione della prima sezione ripaga.

Redirect rotto o lento. Il test sintetico è già un monitor. Fai scattare l'alert quando due o più località falliscono nella stessa esecuzione, così una singola regione di sonda instabile non sveglia nessuno. Qualsiasi risposta diversa dal tuo 302 fa fallire l'asserzione di stato, quindi un link canary eliminato, scaduto o in pausa compare qui come 404 o 410.

Traffico fermo. Crea un monitor di metrica su sum:elido.clicks{workspace_id:42} e attiva la notifica per dati mancanti dopo, diciamo, 30 minuti. Dato che Elido non invia nulla in un minuto tranquillo, "nessun dato" qui significa davvero "nessun clic", che è l'evento che ti interessa durante una campagna.

Traffico anomalo. Un monitor di anomalie sulla stessa metrica, con la direzione impostata su below, intercetta una campagna che normalmente fa 4.000 clic all'ora e improvvisamente ne fa 200. Ho visto quello schema tre volte, e ogni volta la causa stava fuori dal link: un annuncio non approvato, una newsletter finita al segmento sbagliato, un poster QR dietro un'impalcatura. Dagli un paio di settimane di storico prima di fidarti delle sue bande.

Vuoi alert per singolo link? Le metriche non possono farlo, ma i log sì. Crea una metrica basata sui log da source:elido raggruppata per @attributes.slug, e ottieni un conteggio dei clic per slug che puoi monitorare. Limitala a un insieme filtrato di slug di campagna, o il costo di cardinalità rientra dalla porta di servizio.

Un SLO che puoi davvero difendere

Un service level objective su un link corto significa qualcosa solo se la sua fonte misura il redirect. Costruiscilo sul test sintetico. Un SLO basato su monitor con quel singolo test come monitor fa il lavoro.

Partirei dal 99,9% su 30 giorni. Sono circa 43 minuti di controlli falliti al mese, ed è un budget che puoi spiegare a un responsabile marketing in una frase. Non costruirlo sul volume di clic. I clic misurano la domanda, non la salute; un link che nessuno clicca è perfettamente disponibile.

Se una linea piatta su quel widget SLO è ciò che ti mancava, configura un workspace, punta il canary al tuo dominio ed eseguilo per una settimana prima di fissare l'obiettivo.

Elido self-hosted: raccogliere i contatori dei redirect

Se esegui tu stesso il servizio di redirect (possibile solo come deployment Enterprise su contratto nella tua infrastruttura; Elido non è venduto come prodotto self-hosted scaricabile) hai una fonte in più. Il servizio di redirect espone un endpoint Prometheus su /metrics, e il check OpenMetrics dell'Agent Datadog può raccoglierlo. La serie utile è elido_edge_redirect_total, un contatore con label fleet e outcome, dove gli esiti includono ok, notfound, expired, paused, disabled, blocked, capped e error.

Questo ti dà ciò che l'integrazione SaaS non dà: un vero tasso di 404 su tutto il traffico, calcolato come notfound sul totale. Un secondo contatore, edge_redirect_clicks_filtered_bot_total, mostra quanti redirect sono stati serviti ai bot senza evento di clic. Su quell'endpoint non c'è però alcun istogramma di latenza. La latenza viene comunque da Synthetics, self-hosted o no. Il playbook di self-hosting su k3s tratta dove si trova quell'endpoint nel deployment.

Dove si ferma l'integrazione Datadog

Ora i limiti, quelli che più probabilmente mordono per primi.

La consegna è best effort, e viene dalla pipeline dei clic, quindi può restare indietro rispetto al redirect di un attimo. Un POST di log fallito riceve un nuovo tentativo dopo un secondo e poi viene scartato. Un invio di metriche fallito non viene ritentato affatto; quel minuto è perso, e la finestra successiva parte pulita. Tratta elido.clicks come una linea di tendenza e riconcilia i totali con gli analytics dei clic di Elido, che è il registro di riferimento.

I log portano l'IP del visitatore e l'URL di destinazione completo, tag UTM inclusi. Se la tua org Datadog è negli USA, sono dati personali che lasciano l'UE, e la guida alla residenza dei dati nell'UE per i team marketing spiega come valutarlo. Come minimo, scegli il sito UE se ne hai uno.

Il costo dei log scala con i clic, un log ingerito ciascuno. Un link virale fa una fattura virale. Filtri di esclusione, o una metrica basata sui log abbinata a un indice con retention breve, lo tengono sotto controllo.

E l'ambito sono i clic. Nessun evento di creazione link, nessuna conversione, nessuna latenza, nessun codice di stato. Onestamente, non sono sicuro che un forwarder di clic debba trasportare la latenza; la sonda che misura dall'esterno è comunque il testimone più veritiero.

Le pagine della documentazione Datadog collegate sopra sono state consultate il 2026-10-25. Per il budget di latenza dietro il redirect, vedi l'articolo sul p95 sotto 15ms

Correlati sul blog

• Tracciamento dei link con Mixpanel - lo stesso forwarder di clic, puntato all'analytics di prodotto.
• Strategia di cache per i redirect di URL - perché la latenza dei redirect ha l'aspetto che ha.
• Strategia di prevenzione del link rot - cosa fare dopo che scatta il monitor sui 404.
• Clic sui link corti vs sessioni GA4 - perché i conteggi dei clic e le sessioni analytics non coincidono.
• Tracciamento server-side GA4 tramite redirect - eventi di clic server-side, inviati a Google invece.
• Tracciamento dei link con Klaviyo - lo stesso forwarder di clic, che invia ogni clic in Klaviyo.