Monitoraggio dei link brevi con Sentry e Datadog

Se un link breve restituisce 5xx per 30 secondi durante una campagna Instagram, perdi circa il 4-7% della coorte. La maggior parte dei team di ingegneria lo scopre la mattina dopo quando qualcuno incolla uno screenshot di Slack. Questa guida è il playbook che usiamo da Elido per rilevare i guasti di reindirizzamento in meno di 60 secondi usando due strumenti che probabilmente paghi già: Sentry per le issue e Datadog per le metriche. E' la stessa configurazione che utilizziamo per i nostri edge POP, che servono circa 240 milioni di reindirizzamenti al mese con un p99 di 13 ms.

In breve: Sentry fa una cosa molto bene per i reindirizzamenti, e quella cosa è "una issue per ogni destinazione rotta, con la lista degli slug che l'hanno colpita." Datadog fa la cosa ortogonale: le serie temporali. Vuoi entrambe, ed Elido emette verso entrambe in modo nativo. Sentry è attualmente in Beta (incolla un DSN e hai finito); Datadog e' Live con un metric collector dedicato. Qui di seguito: quali segnali contano, come funziona l'integrazione con Sentry sotto il cofano e cosa dovrebbe contenere davvero un dashboard Datadog per la salute dei reindirizzamenti.

Quali segnali contano per il monitoraggio dei reindirizzamenti

Prima di configurare qualsiasi cosa, decidi cosa ti interessa davvero. Il monitoraggio dei reindirizzamenti è un problema più circoscritto dell'APM completo, e l'insieme di segnali è ridotto. Quattro segnali coprono circa il 95% degli incidenti reali:

Eventi di reindirizzamento 4xx. Un 404 su un link breve è quasi sempre una di tre cose: uno slug è stato eliminato, uno slug è scaduto, oppure qualcuno sta sondando il tuo dominio. Un 410 è intenzionale e rumoroso, quindi lo sopprimiamo dagli alert. Un 451 (blocco geografico) è interessante solo in aggregato. Il volume di 4xx per evento è troppo rumoroso per generare page; trattalo come una metrica, non come una issue.

Eventi di reindirizzamento 5xx. Questi giustificano una chiamata all'ingegnere di guardia. Un 5xx significa che l'edge non è riuscito a raggiungere Redis (cache L2), non è riuscito a raggiungere api-core (gRPC di origine) o che l'URL di destinazione ha avuto un errore DNS durante un HEAD-check. Ciascuno di questi casi ha un runbook diverso. Il transformer di Sentry in api-core etichetta la causa radice in modo che il titolo della issue sia qualcosa come 5xx: redis-timeout (12 slug coinvolti, ultima occorrenza 14s fa) invece del generico Internal Server Error.

Latenza edge p99. Un reindirizzamento con cache HIT dovrebbe essere servito in meno di 15 ms a p99 da qualsiasi nostro POP. Scattiamo alert se il p99 rimane sopra 50 ms per 5 minuti. Il motivo e' che una singola query lenta non alzerà il p99 per 5 minuti, ma una replica Redis che perde la sincronizzazione sì. Vedi redirect p95 sotto 15 ms per la ripartizione del budget di latenza.

Anomalia del tasso di clic e fallimento della scansione. Le anomalie del tasso di clic sono il sistema di allerta tardiva. Se una campagna fa normalmente 4.000 clic/ora e improvvisamente ne fa 200, qualcosa a monte si è rotto (il tuo annuncio è stato rifiutato, il tuo adesivo QR si è staccato, qualcuno ha rimosso il link sbagliato). I fallimenti di scansione provengono dal servizio url-scanner, che analizza le destinazioni alla ricerca di malware. Un picco di fallimenti di scansione di solito significa che un account è stato compromesso e sta creando link di phishing.

Instradare i segnali verso lo strumento giusto

Non ogni segnale appartiene a ogni strumento. Inviare il volume di 4xx a Sentry come issue seppellirà la vera issue "destinazione rotta" sotto il rumore. Inviare la latenza p99 a Sentry come alert è scomodo perché il sistema di alert di Sentry è costruito attorno alla frequenza delle issue, non alle serie temporali. Il modello mentale: Sentry = eccezioni, Datadog = metriche, Slack = persone, Linear = ticket di follow-up.

Elido emette dove c'e' la X. Non inviamo eventi 4xx a Sentry perché non sono eccezioni. Non inviamo ogni evento di clic a Datadog perché il volume non vale il costo (le metriche personalizzate di Datadog sono fatturate per combinazione unica di tag, e la cardinalità di slug x regione x tier brucerebbe $4.000/mese per un workspace di medie dimensioni). La suddivisione sopra è quella a cui siamo arrivati dopo 9 mesi di esercizio interno del sistema.

Integrazione con Sentry: incollare il DSN e l'envelope transformer

L'integrazione di Sentry in Elido e' in Beta ma funzionalmente completa. La configurazione richiede tre clic. Vai su /integrations, trovi Sentry, incolli un DSN e scegli quali tipi di eventi inoltrare. Il DSN e' l'unico segreto. Lo memorizziamo in Postgres con cifratura a envelope (KMS-wrapped secondo ADR-0036) in modo che anche i nostri amministratori DB non possano leggerlo in chiaro.

Quello che succede sotto il cofano e' che api-core ha un webhook transformer che ascolta il bus di eventi interno (topic Redpanda redirect.errors) e confeziona gli eventi corrispondenti in envelope Sentry. Il formato envelope e' documentato nella specifica envelope di Sentry - e' semplicemente un HTTP POST con una riga di intestazione JSON, un'intestazione di item JSON e un payload di item JSON, separati da newline. Non c'e' nessun SDK Sentry nel percorso delle richieste. Questo mantiene il codice edge (services/edge-redirect) snello ed evita una dipendenza nell'hot path.

Il transformer fa tre cose utili:

Fingerprinting. Sentry raggruppa gli eventi per fingerprint. Un fingerprint ingenuo raggrupperebbe tutti i 5xx in un'unica issue gigante, il che e' inutile. Il nostro transformer fa il fingerprint per error_class:destination_host, in modo che un timeout Redis sui link che puntano a acme.com sia una issue separata da un timeout Redis sui link che puntano a globex.com. Questo rende il principio "una destinazione rotta = una issue" realmente vero.

Aggregazione degli slug. Ogni evento Sentry porta un blocco tags che elenca i primi 50 slug coinvolti, l'ID del workspace e il dominio di reindirizzamento. Quando 800 slug condividono una destinazione e quella destinazione inizia a restituire DNS NXDOMAIN, vedi una issue con slugs_affected: 800 e un campione di 50, non 800 alert separati.

Rate limiting per workspace. Un workspace che gestisce una campagna difettosa puo' generare 10.000 errori 5xx in 60 secondi. Sentry li accetterà tutti e te li addebiterà. Il transformer limita a 50 envelope al minuto per workspace e raggruppa il resto in un singolo evento "suppressed" con un contatore. Lo abbiamo imparato a nostre spese quando un cliente ha puntato 4 milioni di link brevi su un dominio che ha iniziato a restituire 503.

Se preferisci gestire l'ingest tu stesso piuttosto che tramite il transformer di Elido, la guida all'osservabilità illustra il percorso alternativo: iscriviti al nostro bus di eventi webhook e converti gli eventi in envelope Sentry nella tua infrastruttura. La maggior parte dei team non si preoccupa di farlo. Il transformer e' più rapido da adottare che da costruire.

Una nota su cosa appare come "issue": l'UI di Sentry tratta ogni evento raggruppato come una scheda di issue con una sparkline, un evento di esempio e una lista di tag. Per gli errori di reindirizzamento, il tag piu' utile e' cache_result (HIT, MISS, BYPASS). Se vedi un'ondata di 5xx con cache_result: BYPASS, probabilmente qualcuno nel tuo team ha deployato un cambiamento che forzava il bypass della cache per i test e ha dimenticato di ripristinarlo. Storia vera, successa due volte nell'ultimo anno.

Integrazione con Datadog: metric collector e dashboard

Datadog e' Live. La configurazione richiede anche qui tre clic, ma l'architettura e' diversa. Invece di un transformer per evento, eseguiamo un metric collector lato api-core che aggrega la telemetria di reindirizzamento nel formato metriche di Datadog e invia batch ogni 10 secondi tramite l'API di metriche personalizzate di Datadog. Il collector pre-aggrega in modo da non inviare mai eventi grezzi. Questo mantiene bassa la cardinalità delle metriche personalizzate e la tua fattura Datadog sotto controllo.

Le metriche che emettiamo di default:

• elido.redirect.count - contatore, etichettato per domain, tier, region, cache_result, status_class (2xx/3xx/4xx/5xx)
• elido.redirect.latency.ms - distribuzione, etichettata per domain, tier, region, cache_result
• elido.click.count - contatore, etichettato per domain, tier (deduplicato alla frontiera del click-ingester)
• elido.scanner.failure.count - contatore, etichettato per reason (malware, phishing, expired_cert, dns_nxdomain)

I tag sono la leva. Puoi visualizzare "latenza p99 per link.acme.com a FRA nelle ultime 4 ore" con una query di una sola riga. Non devi pre-costruire dashboard per ogni dominio. Vedi /integrations/datadog per il riferimento alle metriche e la tassonomia dei tag.

I quattro pannelli sopra sono quelli che mettiamo sul nostro schermo NOC. Coprono la vista quotidiana di guardia. Latenza p99 dell'edge per regione rileva le regressioni a livello di POP (un problema Hetzner FRA appare diverso da uno OVH SGP, e vuoi vederli fianco a fianco). Tasso di errore per dominio top-10 mette in evidenza i clienti problematici: se acme.com e' all'8% di 5xx e tutti gli altri sono allo 0,02%, non hai un problema Elido, hai un problema acme. Volume di clic per tier (f / s / b per free, starter, business tramite l'isolamento per tier) indica se un picco di traffico proviene da un tenant pagante o da una campagna del tier gratuito che dovrebbe essere limitata. Conteggio reindirizzamenti rotti nelle ultime 24h e' la metrica di chiusura: un reindirizzamento che ha restituito 4xx dovrebbe essere stato corretto oppure scaduto e rimosso entro 24 ore; vedi prevenzione del deterioramento dei link per il percorso di riparazione automatica.

Soglie di alert raccomandate (queste sono le nostre impostazioni predefinite; puoi sovrascriverle per workspace):

• elido.redirect.latency.ms p99 > 50 ms sostenuto 5 min - chiama il guardia
• elido.redirect.count{status_class:5xx} tasso > 0,5% sostenuto 2 min - chiama il guardia
• elido.redirect.count{status_class:4xx} tasso > 5% sostenuto 10 min - solo Slack
• elido.scanner.failure.count tasso > 10/min per un workspace - revisione di sicurezza, nessun page

La soglia dello 0,5% per i 5xx e' conservativa. La nostra baseline e' ~0,01% (principalmente problemi DNS sulle destinazioni dei clienti), quindi lo 0,5% e' una deviazione di 50x, che e' reale.

Quando usare quale strumento

Per un team piccolo che gestisce un prodotto orientato agli sviluppatori su /solutions/developers, Sentry da solo e' probabilmente sufficiente. Verrai avvisato per i veri 5xx, vedrai le issue e le risolverai. Non avrai la cultura del dashboard per far valere a Datadog l'overhead di $1,50/host/mese.

Per un'azienda piu' grande su /solutions/enterprise con una rotazione di guardia SRE, vuoi entrambi. Sentry per il flusso di issue, Datadog per i dashboard, alert Slack collegati a PagerDuty per le chiamate. La guida all'osservabilità illustra il mapping dei servizi PagerDuty se segui quella strada.

Per tutti nel mezzo, la nostra raccomandazione e': Sentry dal primo giorno (il tier gratuito di Sentry va bene per meno di 5.000 eventi/mese), Datadog quando inizi ad avere piu' di un dominio di reindirizzamento o piu' di una regione di traffico. La fattura del metric collector di Datadog per un workspace Elido Business tipico e' di circa $35/mese, il prezzo di non dover fare grep sui log nginx di domenica.

Cosa ti da' questo che i monitor di uptime generici non offrono

Un check Pingdom o UptimeRobot su f.elido.me ti dira' se l'edge e' attivo. Non ti dira' che la destinazione dello slug summer24 ha iniziato a restituire DNS NXDOMAIN 12 minuti fa, o che il p99 in SGP e' 4 volte il p99 in FRA perche' un leader di partizione Redpanda ha fatto un restart. Il monitoraggio dei reindirizzamenti e' un problema consapevole della destinazione. Il reindirizzamento stesso puo' essere sano mentre il link e' morto.

La combinazione Sentry + Datadog ti da' visibilita' consapevole della destinazione senza scrivere sonde personalizzate. Sentry ti dice cosa e' rotto a livello di destinazione. Datadog ti dice cosa si sta degradando a livello di edge. Slack informa le persone, Linear gestisce il follow-up. La configurazione e' incolla-un-DSN per Sentry e un unico flusso OAuth per Datadog. Inizia con Sentry oggi; aggiungi Datadog quando il numero dei tuoi domini di reindirizzamento supera uno.

Per i prezzi e cosa include ogni tier in termini di integrazioni, vedi /pricing. Per la superficie API intorno alle sottoscrizioni agli eventi se vuoi costruire il tuo, /features/analytics e il dettaglio di Sentry su 12 servizi Go coprono la tassonomia degli eventi.