Monitoraggio dei link brevi con Sentry e Datadog: chi fa cosa

Il monitoraggio dei link brevi si divide in modo netto tra i due strumenti. Sentry è dove Elido invia gli eventi sullo stato dei link: una destinazione che ha smesso di rispondere, un link scaduto, un limite di click raggiunto, un dominio personalizzato la cui verifica è fallita. Datadog è dove Elido invia i click, un log per ogni visita e tre metriche sul conteggio dei click al minuto. La latenza dei redirect non arriva a nessuno dei due, perché Elido non la esporta: la misuri dall'esterno con una sonda sintetica.

Questo articolo è la metà del quadro incentrata su Sentry, più una risposta chiara alla domanda "quale strumento per cosa". Se sei qui per le dashboard di Datadog, la guida alle metriche di redirect su Datadog copre in profondità le metriche sui click, la struttura dei log e una board sulla latenza basata su Synthetics, quindi qui non la ripeto.

Un pezzo di contesto prima di entrare nel dettaglio tecnico. Un redirect può essere perfettamente sano mentre il link è in realtà morto: l'URL breve risponde in pochi millisecondi e manda le persone su una pagina 404. Ecco perché il monitoraggio degli URL brevi ha bisogno sia di un segnale consapevole della destinazione sia di un segnale di velocità, e perché nessuno strumento da solo offre entrambi da un'unica fonte. L'articolo sotto i 15ms di p95 spiega come appare "sano" dal lato della velocità.

Cosa deve intercettare il monitoraggio dei link brevi

Divido i guasti in tre categorie, perché ognuna richiede uno strumento diverso.

Il link si è rotto. La sua destinazione restituisce un 4xx o un 5xx, va in timeout, oppure il dominio ha smesso di risolversi. Il tuo redirect funziona ancora, ma ora inoltra le persone verso una pagina di errore. Elido rileva questi casi con un controllo giornaliero della destinazione e solleva link.broken.

Il link si è fermato per progetto. Ha raggiunto la data di scadenza o il limite di click, quindi Elido ha smesso di reindirizzarlo. Dal punto di vista tecnico non c'è nulla che non va, eppure se una campagna punta ancora lì, qualcuno deve saperlo. Sono link.expired e link.cap_reached. Un dominio personalizzato mai verificato solleva domain.ssl_failed, che appartiene allo stesso gruppo.

Il redirect stesso è diventato lento o è andato giù. Questo è il segnale di velocità, ed è quello che Elido non emette come metrica. Lo osservi dall'esterno.

Il traffico è un quarto segnale, ma più sfumato. Una campagna che di solito fa migliaia di click all'ora e all'improvviso ne fa solo qualche decina di solito significa che qualcosa a monte è cambiato, come un annuncio messo in pausa o un adesivo QR staccato. I conteggi dei click vivono in Datadog, quindi è lì che va posizionato il monitor sui cali.

Cosa invia Elido a Sentry

Sentry è uno dei tipi di canale in uscita nel sistema di notifiche di Elido, insieme a Discord, Telegram e ai semplici webhook firmati. Viaggia sulla stessa pipeline di consegna dei webhook, con una differenza: invece dell'evento grezzo di Elido, invia un piccolo evento Sentry.

Ogni consegna è un evento JSON inviato all'endpoint store del tuo progetto, che Elido ricava dal DSN. Dato https://[email protected]/8, la destinazione è https://o4711.ingest.sentry.io/api/8/store/ e la chiave pubblica finisce nell'header X-Sentry-Auth. Non c'è nessun SDK Sentry lungo il percorso, e poiché l'host del DSN viene analizzato anziché codificato in modo fisso, un server self-hosted compatibile con Sentry funziona allo stesso modo. Il payload segue il formato degli eventi di Sentry:

{
  "event_id": "9f0c4e1b2a7d4c33b8e5d6a1f2c3b4a5",
  "timestamp": 1790000000,
  "level": "error",
  "logger": "elido",
  "platform": "other",
  "message": "<humanized event name, e.g. Link / Broken>",
  "environment": "production",
  "tags": { "event_type": "link.broken", "workspace_id": "42" }
}

Il livello viene scelto in base al nome dell'evento. Tutto ciò che significa "questo link non funziona in questo momento" arriva come error: .broken, .expired, cap_reached, ssl_failed. Cancellazioni e downgrade arrivano come warning, tutto il resto come info.

Ora la parte onesta sui tag. Ogni evento porta i tag event_type e workspace_id, e i campi environment e release vengono compilati quando li imposti sul canale. Un evento cap-reached porta anche un tag clicks. L'evento di link rotto, però, oggi non porta lo slug né la destinazione come tag, quindi l'issue su Sentry ti dice solo che un link nel workspace 42 si è rotto, e devi aprire l'elenco dei link in Elido, dove quello rotto porta un flag. Preferisco dirtelo subito piuttosto che farti cercare un tag slug alle due di notte.

Configurare un canale Sentry per gli avvisi sui link rotti

La configurazione richiede un paio di minuti e il DSN è l'unica credenziale necessaria. Il canale Sentry è contrassegnato come Beta perché sei tu a creare il progetto Sentry; un'installazione con un clic tramite la piattaforma di integrazione di Sentry è nella roadmap ma non è ancora stata costruita, quindi oggi si tratta di incollare un DSN.

1. In Sentry, crea un progetto, scegli la piattaforma Other e copia il DSN dalla schermata successiva. La spiegazione del DSN mostra quale parte è la chiave e quale è l'ID del progetto.
2. Nella dashboard di Elido, apri Notifications, aggiungi un canale, scegli Sentry, incolla il DSN e, facoltativamente, un nome di ambiente come production.
3. Mantieni gli eventi predefiniti oppure scegline di tuoi. Quelli predefiniti sono link.broken, link.expired, link.cap_reached e domain.ssl_failed.

Elido controlla il DSN quando salvi: deve essere http o https, includere una chiave pubblica e terminare con un ID di progetto. Un DSN malformato viene respinto subito, invece di fallire in silenzio più avanti.

Se gestisci la configurazione come codice, lo stesso canale è una singola chiamata API. I canali sono endpoint webhook con un kind:

curl -X POST https://api.elido.app/v1/workspaces/42/webhooks \
  -H "Authorization: Bearer elido_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "sentry",
    "url": "https://[email protected]/8",
    "events": ["link.broken", "link.expired", "link.cap_reached", "domain.ssl_failed"],
    "description": "Link health to Sentry",
    "config": { "environment": "production", "release": "spring-campaign" }
  }'

Le consegne verso Sentry non sono firmate con HMAC, perché Sentry autentica la richiesta tramite la propria chiave. Ricevono comunque la normale politica di retry: tre tentativi in totale, con i retry a cinque e quindici minuti dopo un fallimento, dopodiché la consegna viene contrassegnata come fallita. Puoi elencarle su /v1/workspaces/{workspace_id}/webhooks/{id}/deliveries e riprovarne una manualmente.

Non esiste un pulsante di test per questo canale. Il test più pulito che conosco: crea un link usa e getta con una scadenza tra un minuto o due e aspetta. Elido cerca i link appena scaduti ogni cinque minuti, quindi un'issue di livello error dovrebbe comparire su Sentry poco dopo.

Una volta che gli eventi sullo stato dei link arrivano su Sentry, la domanda successiva è cosa ci farai, e dipende da come Sentry li raggruppa. Se stai ancora scegliendo un piano, confronta cosa include ogni livello prima di collegare il canale.

Come Sentry raggruppa gli eventi sullo stato dei link di Elido

Questi eventi non hanno stack trace né eccezioni, quindi il raggruppamento di fallback di Sentry li raggruppa per messaggio. In pratica significa un'issue per ogni tipo di evento: tutti gli eventi di link rotto diventano un'unica issue il cui conteggio sale, tutte le scadenze un'altra.

Questo è utile per il paging e meno utile per il triage. Due accorgimenti aiutano:

• Imposta l'ambiente sul canale. Con canali separati per workspace o per ambiente (production, campaigns), ognuno ottiene un proprio filtro nel flusso delle issue, e puoi limitare le regole di alert a uno solo.
• Aggiungi una regola di fingerprint nelle impostazioni del progetto Sentry su tags.workspace_id se instradi più workspace verso un unico progetto e vuoi un'issue per workspace.

Per gli alert, costruisci sulle regole di alert per le issue native di Sentry: "viene creata una nuova issue" intercetta il primo link rotto, e "l'issue viene vista più di N volte in un'ora" intercetta un lotto, ad esempio un'intera campagna il cui dominio di atterraggio è andato giù. Tieni presente il ritmo di rilevamento che c'è dietro. Il controllo della destinazione gira una volta al giorno, il primo fallimento scatta subito, e un link che resta rotto scatta di nuovo dopo 24 ore. Sentry è la casella giusta per questo. Non è un rilevatore di interruzioni a cinque minuti, e non voglio far credere il contrario.

Dove si inserisce Datadog nel monitoraggio dei redirect

Datadog riceve i click, non lo stato dei link. Ogni click diventa un log inviato all'intake dei log del tuo sito Datadog, con source elido, tag workspace_id, vendor:elido e link_id, e i campi del click sotto attributes. Una volta al minuto, Elido invia anche tre gauge per workspace: elido.clicks, elido.clicks_by_country e elido.clicks_by_device.

Ciò che non c'è conta altrettanto. Nessuna metrica di latenza, nessun codice di stato, nessun tag su dominio, piano o regione. Una POST di log fallita ottiene un solo retry e poi viene scartata. Le impostazioni restano in cache fino a cinque minuti, quindi una chiave appena salvata impiega un momento ad attivarsi, e il pulsante Test connection della dashboard invia un log di test e mostra la risposta di Datadog, il che intercetta una chiave o un sito sbagliati ma non una pipeline che scarta i log, quindi un click reale resta comunque la prova che funziona.

Quindi il compito di Datadog qui è il traffico: volume di click al minuto, paesi principali e un monitor per "i click sono scesi quasi a zero". La guida al monitoraggio degli URL su Datadog contiene le query e i passaggi di configurazione, e la pagina di integrazione elenca i campi. Riconcilia i totali con l'analytics dei click di Elido, che resta la fonte di verità.

Monitorare la latenza dei redirect dall'esterno

Per il segnale di velocità, punta un controllo sintetico su un link breve canarino: un link che crei solo per il monitoraggio, così le sonde non si mescolano mai con i numeri della campagna. I test HTTP di Datadog fanno bene questo lavoro, e funziona anche qualsiasi servizio di uptime in grado di saltare i redirect.

Tre impostazioni decidono se il numero ha un senso:

• Disattiva il seguito dei redirect. Vuoi il tempo fino al ritorno del 301 o del 302, non il tempo che la tua landing page impiega a renderizzarsi.
• Verifica il codice di stato e l'header Location, così un redirect verso il posto sbagliato fa fallire il controllo.
• Invia uno User-Agent che contiene bot. Elido salta gli eventi di click per gli agent bot conosciuti, così la tua sonda non gonfia i conteggi dei click.

Esegui la sonda da località vicine al tuo pubblico. Un redirect con cache-hit nella stessa regione dovrebbe restare ben al di sotto del budget p95 di 15ms, e un aumento prolungato merita un page. Un controllo sul tuo dominio personalizzato ti dice anche che il suo certificato TLS funziona ancora, cosa che un semplice inoltratore di click non potrebbe mai dirti.

Quale strumento per cosa

Ecco la suddivisione che imposterei per un team che gestisce campagne a pagamento sui link brevi:

Un piccolo team può iniziare con il solo canale Sentry: copre i guasti che sprecano silenziosamente budget pubblicitario. Aggiungi Datadog quando qualcuno inizia davvero a guardare le dashboard sul traffico, e aggiungi la sonda il giorno in cui un redirect lento inizierebbe a costarti denaro. Se Sentry non è la casella del tuo team, gli stessi eventi sullo stato dei link arrivano anche su Discord o Telegram, e un link rotto può anche aprire un ticket su Linear.

Leggi l'articolo cardine → Restare sotto i 15ms di p95 per i redirect

Articoli correlati sul blog

• Monitoraggio degli URL su Datadog per i link brevi - metriche sui click, log e una board sulla latenza basata su Synthetics.
• Strategia di prevenzione del link rot - cosa fare dopo che arriva un'issue di link rotto.
• Avvisi su Discord e Telegram per i link brevi - gli stessi eventi sullo stato dei link in un canale di chat.
• Ticket su Linear dagli avvisi sui link - trasformare un link rotto in un task tracciato.