Surveillance des liens courts avec Sentry et Datadog

Si un lien court renvoie un 5xx pendant 30 secondes lors d'une campagne Instagram, vous perdez environ 4 à 7 % de la cohorte. La plupart des équipes d'ingénierie l'apprennent le lendemain matin quand quelqu'un colle une capture Slack dans un canal. Ce guide est le playbook que nous utilisons chez Elido pour détecter les défaillances de redirection en moins de 60 secondes grâce à deux outils que vous payez probablement déjà : Sentry pour les issues et Datadog pour les métriques. C'est le même câblage que nous utilisons pour nos propres edge POPs, qui servent environ 240 millions de redirections par mois avec un p99 de 13 ms.

En bref : Sentry fait une chose très bien pour les redirections, et cette chose est "un issue par destination cassée, avec la liste des slugs concernés." Datadog fait la chose orthogonale : les séries temporelles. Vous voulez les deux, et Elido émet nativement vers les deux. Sentry est actuellement en Beta (collez un DSN, c'est terminé) ; Datadog est en Live avec un metric collector dédié. Ci-dessous : quels signaux comptent, comment fonctionne le câblage Sentry en coulisses, et ce qu'un dashboard Datadog pour la santé des redirections doit réellement contenir.

Quels signaux comptent pour la surveillance des redirections

Avant de câbler quoi que ce soit, décidez ce qui vous importe vraiment. La surveillance des redirections est un problème plus ciblé que l'APM complet, et l'ensemble de signaux est restreint. Quatre signaux couvrent environ 95 % des incidents réels :

Événements de redirection 4xx. Un 404 sur un lien court est presque toujours l'une de ces trois choses : un slug a été supprimé, un slug a expiré, ou quelqu'un sonde votre domaine. Un 410 est intentionnel et bruité, donc nous le supprimons des alertes. Un 451 (blocage géographique) n'est intéressant qu'en agrégat. Le volume de 4xx par événement est trop bruité pour déclencher une alerte ; traitez-le comme une métrique, pas comme un issue.

Événements de redirection 5xx. Ceux-là justifient un appel à l'ingénieur d'astreinte. Un 5xx signifie soit que l'edge n'a pas pu joindre Redis (cache L2), soit qu'il n'a pas pu joindre api-core (gRPC origin), soit que l'URL de destination a eu un échec DNS lors d'un HEAD-check. Chacun de ces cas a son propre runbook. Le transformer Sentry dans api-core tague la cause racine pour que le titre de l'issue ressemble à 5xx: redis-timeout (12 slugs concernés, dernière occurrence il y a 14s) plutôt qu'un générique Internal Server Error.

Latence edge p99. Une redirection avec cache HIT devrait être servie en moins de 15 ms en p99 depuis n'importe lequel de nos trois POPs. Nous alertons si le p99 reste au-dessus de 50 ms pendant 5 minutes. La raison : une seule requête lente n'élèvera pas le p99 pendant 5 minutes, mais un réplica Redis qui perd sa synchronisation, oui. Voir redirect p95 sous 15 ms pour la décomposition du budget de latence.

Anomalie de taux de clics et échec de scan. Les anomalies de taux de clics sont le système d'alerte tardive. Si une campagne fait normalement 4 000 clics/heure et passe soudainement à 200, quelque chose a cassé en amont (votre annonce a été rejetée, votre sticker QR s'est décollé, quelqu'un a retiré le mauvais lien). Les échecs de scan proviennent du service url-scanner, qui analyse les destinations à la recherche de malwares. Un pic d'échecs de scan signifie généralement qu'un compte a été compromis et crée des liens de phishing.

Acheminer les signaux vers le bon outil

Tous les signaux ne vont pas dans tous les outils. Envoyer le volume de 4xx à Sentry en tant qu'issues noiera le vrai issue "destination cassée" sous le bruit. Envoyer la latence p99 à Sentry en tant qu'alertes est maladroit car le système d'alerte de Sentry est construit autour de la fréquence d'issues, pas des séries temporelles. Le modèle mental : Sentry = exceptions, Datadog = métriques, Slack = humains, Linear = tickets de suivi.

Elido émet là où se trouve le X. Nous n'envoyons pas les événements 4xx à Sentry parce que ce ne sont pas des exceptions. Nous n'envoyons pas non plus chaque événement de clic à Datadog parce que le volume ne vaut pas le coût (les métriques personnalisées Datadog sont facturées par combinaison unique de tags, et la cardinalité de slug x région x tier brûlerait 4 000 $/mois pour un workspace de taille moyenne). La répartition ci-dessus est celle vers laquelle nous avons convergé après 9 mois d'exploitation interne du système.

Câblage Sentry : coller le DSN et l'envelope transformer

L'intégration Sentry dans Elido est en Beta mais fonctionnellement complète. La configuration se fait en trois clics. Vous allez sur /integrations, trouvez Sentry, collez un DSN et choisissez les types d'événements à transférer. Le DSN est le seul secret. Nous le stockons dans Postgres avec un chiffrement d'enveloppe (KMS-wrapped selon l'ADR-0036), de sorte que même nos administrateurs de base de données ne peuvent pas le lire en clair.

Ce qui se passe sous le capot : api-core dispose d'un webhook transformer qui écoute le bus d'événements interne (topic Redpanda redirect.errors) et conditionne les événements correspondants en enveloppes Sentry. Le format d'enveloppe est documenté dans la spécification d'enveloppe de Sentry - c'est simplement un HTTP POST avec une ligne d'en-tête JSON, un en-tête d'item JSON et un payload d'item JSON, séparés par des sauts de ligne. Il n'y a pas de SDK Sentry dans le chemin de requête. Cela maintient le code edge (services/edge-redirect) léger et évite une dépendance dans le hot path.

Le transformer fait trois choses utiles :

Fingerprinting. Sentry groupe les événements par fingerprint. Un fingerprint naïf regrouperait tous les 5xx en un seul issue géant, ce qui est inutile. Notre transformer crée un fingerprint à partir de error_class:destination_host, de sorte qu'un timeout Redis sur des liens pointant vers acme.com est un issue distinct d'un timeout Redis sur des liens pointant vers globex.com. Cela rend le principe "une destination cassée = un issue" réellement vrai.

Agrégation de slugs. Chaque événement Sentry porte un bloc tags listant les 50 premiers slugs concernés, l'ID du workspace et le domaine de redirection. Quand 800 slugs partagent une destination et que cette destination commence à renvoyer DNS NXDOMAIN, vous voyez un issue avec slugs_affected: 800 et un échantillon de 50, pas 800 alertes séparées.

Rate limiting par workspace. Un workspace menant une campagne défectueuse peut générer 10 000 erreurs 5xx en 60 secondes. Sentry les acceptera tous et vous les facturera. Le transformer limite à 50 enveloppes par minute par workspace et regroupe le reste dans un unique événement "suppressed" avec un compteur. Nous l'avons appris à la dure quand un client a pointé 4 millions de liens courts vers un domaine qui a commencé à renvoyer des 503.

Si vous préférez gérer l'ingestion vous-même plutôt que via le transformer d'Elido, le guide d'observabilité couvre le chemin alternatif : abonnez-vous à notre bus d'événements webhook et convertissez les événements en enveloppes Sentry dans votre propre infrastructure. La plupart des équipes ne s'en donnent pas la peine. Le transformer est plus rapide à adopter qu'à construire.

Une note sur ce qui apparaît comme "issue" : l'UI Sentry traite chaque événement groupé comme une carte d'issue avec une sparkline, un exemple d'événement et une liste de tags. Pour les erreurs de redirection, le tag le plus utile est cache_result (HIT, MISS, BYPASS). Si vous voyez une vague de 5xx avec cache_result: BYPASS, quelqu'un dans votre équipe a probablement déployé un changement qui forçait le bypass du cache pour des tests et a oublié de le remettre. Histoire vraie, arrivée deux fois dans l'année écoulée.

Câblage Datadog : metric collector et dashboards

Datadog est en Live. Le câblage se fait aussi en trois clics, mais l'architecture est différente. Plutôt qu'un transformer par événement, nous faisons tourner un metric collector côté api-core qui agrège la télémétrie de redirection au format de métriques Datadog et soumet des lots toutes les 10 secondes via l'API de métriques personnalisées Datadog. Le collector pré-agrège pour ne jamais soumettre d'événements bruts. Cela maintient la cardinalité des métriques personnalisées faible et votre facture Datadog sous contrôle.

Les métriques que nous émettons par défaut :

• elido.redirect.count - compteur, tagué par domain, tier, region, cache_result, status_class (2xx/3xx/4xx/5xx)
• elido.redirect.latency.ms - distribution, taguée par domain, tier, region, cache_result
• elido.click.count - compteur, tagué par domain, tier (dédupliqué à la frontière du click-ingester)
• elido.scanner.failure.count - compteur, tagué par reason (malware, phishing, expired_cert, dns_nxdomain)

Les tags sont le levier. Vous pouvez afficher "la latence p99 pour link.acme.com à FRA pendant les 4 dernières heures" avec une requête d'une seule ligne. Vous n'avez pas besoin de pré-construire des dashboards pour chaque domaine. Voir /integrations/datadog pour la référence des métriques et la taxonomie des tags.

Les quatre panneaux ci-dessus sont ceux que nous affichons sur notre propre écran NOC. Ils couvrent la vue quotidienne d'astreinte. Latence p99 de l'edge par région détecte les régressions au niveau POP (une perturbation Hetzner FRA ressemble différemment d'une perturbation OVH SGP, et vous voulez les voir côte à côte). Taux d'erreur par domaine top-10 met en évidence les clients bruyants - si acme.com est à 8 % de 5xx et que tout le monde est à 0,02 %, vous n'avez pas un problème Elido, vous avez un problème acme. Volume de clics par tier (f / s / b pour free, starter, business via l'isolation par tier) indique si un pic de trafic provient d'un tenant payant ou d'une campagne du tier gratuit qui devrait être limitée. Nombre de redirections cassées sur 24h est la métrique de clôture : une redirection qui a renvoyé du 4xx devrait soit avoir été corrigée, soit être expirée et supprimée dans les 24 heures ; voir prévention de la dégradation des liens pour le chemin de réparation automatique.

Seuils d'alerte recommandés (ce sont nos valeurs par défaut ; vous pouvez les remplacer par workspace) :

• elido.redirect.latency.ms p99 > 50 ms soutenu 5 min - appel à l'astreinte
• elido.redirect.count{status_class:5xx} taux > 0,5 % soutenu 2 min - appel à l'astreinte
• elido.redirect.count{status_class:4xx} taux > 5 % soutenu 10 min - Slack uniquement
• elido.scanner.failure.count taux > 10/min pour un workspace - revue de sécurité, pas d'appel

Le seuil de 0,5 % pour les 5xx est conservateur. Notre baseline est ~0,01 % (principalement des accrocs DNS sur les destinations des clients), donc 0,5 % représente une déviation de 50x, ce qui est réel.

Quand utiliser quoi

Pour une petite équipe qui gère un produit orienté développeurs sur /solutions/developers, Sentry seul est probablement suffisant. Vous serez alerté sur les vrais 5xx, vous verrez les issues et les corrigerez. Vous n'aurez pas la culture du dashboard pour que Datadog vaille $1,50/hôte/mois en surcoût.

Pour une grande entreprise sur /solutions/enterprise avec une rotation d'astreinte SRE, vous voulez les deux. Sentry pour le flux d'issues, Datadog pour les dashboards, alertes Slack reliées à PagerDuty pour l'appel. Le guide d'observabilité explique le mapping de service PagerDuty si vous empruntez cette voie.

Pour tout le monde entre les deux, notre recommandation est : Sentry dès le premier jour (le tier gratuit de Sentry convient pour moins de 5 000 événements/mois), Datadog quand vous commencez à avoir plus d'un domaine de redirection ou plus d'une région de trafic. La facture du metric collector Datadog pour un workspace Elido Business typique est d'environ $35/mois, soit le prix d'épargner à un ingénieur de grepper des logs nginx un dimanche.

Ce que cela vous apporte que les moniteurs uptime génériques n'offrent pas

Un check Pingdom ou UptimeRobot sur f.elido.me vous dira si l'edge est actif. Il ne vous dira pas que la destination du slug summer24 a commencé à renvoyer DNS NXDOMAIN il y a 12 minutes, ni que le p99 à SGP est 4 fois supérieur au p99 à FRA parce qu'un leader de partition Redpanda a rebondi. La surveillance des redirections est un problème conscient de la destination. La redirection elle-même peut être saine tandis que le lien est mort.

La combinaison Sentry + Datadog ci-dessus vous donne une visibilité consciente de la destination sans écrire de sondes personnalisées. Sentry vous dit ce qui est cassé au niveau de la destination. Datadog vous dit ce qui se dégrade au niveau de l'edge. Slack informe les humains, Linear gère le suivi. Le câblage, c'est coller-un-DSN pour Sentry et un unique flux OAuth pour Datadog. Commencez avec Sentry aujourd'hui ; ajoutez Datadog quand votre nombre de domaines de redirection dépasse un.

Pour les tarifs et ce que chaque tier inclut comme intégration, voir /pricing. Pour la surface API autour des abonnements aux événements si vous voulez construire le vôtre, /features/analytics et le détail de Sentry sur 12 services Go couvrent la taxonomie des événements.