Surveillance des liens courts avec Sentry et Datadog : qui fait quoi

La surveillance des liens courts se répartit nettement entre les deux outils. Sentry est là où Elido envoie les événements de santé de lien : une destination qui a cessé de répondre, un lien qui a expiré, un plafond de clics atteint, un domaine personnalisé qui a échoué à la vérification. Datadog est là où Elido envoie les clics, un journal par visite et trois métriques de comptage de clics par minute. La latence de redirection ne va vers aucun des deux, car Elido ne l'exporte pas ; vous la mesurez de l'extérieur avec une sonde synthétique.

Cet article est la moitié centrée sur Sentry de ce tableau, plus une réponse simple à « quel outil pour quoi ». Si vous êtes ici pour les tableaux de bord Datadog, le guide des métriques de redirection Datadog couvre en profondeur les métriques de clics, la forme des journaux et un tableau de latence basé sur Synthetics, donc je ne le répéterai pas.

Un peu de contexte avant le câblage. Une redirection peut être parfaitement saine alors que le lien est mort : l'URL courte répond en quelques millisecondes et envoie les gens vers une erreur 404. C'est pourquoi la surveillance d'URL pour les liens courts a besoin d'un signal sensible à la destination et d'un signal de vitesse, et pourquoi aucun outil unique ne vous donne les deux depuis un seul flux. L'analyse du p95 sous 15 ms explique à quoi ressemble « sain » côté vitesse.

Ce que la surveillance des liens courts doit détecter

Je classe les défaillances en trois catégories, car chacune nécessite un outil différent.

Le lien s'est cassé. Sa destination renvoie une erreur 4xx ou 5xx, expire, ou le domaine a cessé de se résoudre. Votre redirection fonctionne toujours, mais elle envoie désormais les gens vers une page d'erreur. Elido les détecte avec une vérification quotidienne de destination et déclenche link.broken.

Le lien s'est arrêté par conception. Il a atteint sa date d'expiration ou son plafond de clics, donc Elido a cessé de le rediriger. Rien n'est techniquement cassé, mais si une campagne pointe toujours vers lui, quelqu'un doit le savoir. C'est link.expired et link.cap_reached. Un domaine personnalisé qui n'a jamais été vérifié déclenche domain.ssl_failed, ce qui appartient au même tas.

La redirection elle-même est devenue lente ou est tombée. C'est le signal de vitesse, et c'est celui qu'Elido n'émet pas comme métrique. Vous le surveillez de l'extérieur.

Le trafic est un quatrième signal, mais plus discret. Une campagne qui fait habituellement des milliers de clics à l'heure et en fait soudain quelques dizaines signifie généralement que quelque chose en amont a changé, comme une publicité mise en pause ou un autocollant QR décollé. Les comptes de clics vivent dans Datadog, donc c'est là que va le moniteur de chute.

Ce qu'Elido envoie à Sentry

Sentry est l'un des types de canal sortant dans le système de notification d'Elido, à côté de Discord, Telegram et de simples webhooks signés. Il emprunte le même pipeline de livraison que les webhooks, avec une différence : au lieu de l'événement Elido brut, il publie un petit événement Sentry.

Chaque livraison est un événement JSON unique envoyé au point d'entrée de stockage de votre projet, qu'Elido dérive du DSN. Étant donné https://[email protected]/8, la cible est https://o4711.ingest.sentry.io/api/8/store/ et la clé publique va dans l'en-tête X-Sentry-Auth. Il n'y a de SDK Sentry nulle part dans le chemin, et comme l'hôte du DSN est analysé plutôt que codé en dur, un serveur compatible Sentry auto-hébergé fonctionne de la même manière. La charge utile suit le format de charge utile d'événement de Sentry :

{
  "event_id": "9f0c4e1b2a7d4c33b8e5d6a1f2c3b4a5",
  "timestamp": 1790000000,
  "level": "error",
  "logger": "elido",
  "platform": "other",
  "message": "<nom d'événement humanisé, ex. Link / Broken>",
  "environment": "production",
  "tags": { "event_type": "link.broken", "workspace_id": "42" }
}

Le niveau est choisi à partir du nom de l'événement. Tout ce qui signifie « ce lien ne fonctionne pas en ce moment » arrive comme error : .broken, .expired, cap_reached, ssl_failed. Les suppressions et rétrogradations arrivent comme warning, tout le reste comme info.

Passons maintenant à la partie honnête sur les tags. Chaque événement porte les tags event_type et workspace_id, et les champs environment et release sont remplis quand vous les définissez sur le canal. Un événement de plafond atteint porte aussi un tag clicks. L'événement de lien cassé, en revanche, ne porte pas le slug ou la destination comme tags aujourd'hui, donc l'issue Sentry vous dit qu'un lien dans l'espace de travail 42 s'est cassé, et vous ouvrez la liste de liens dans Elido, où celui qui est cassé porte un drapeau. Je préfère vous le dire maintenant plutôt que de vous laisser chercher un tag slug à 2 h du matin.

Configurer un canal Sentry pour les alertes de lien cassé

La configuration prend quelques minutes et le DSN est le seul identifiant. Le canal Sentry est marqué Bêta parce que vous créez vous-même le projet Sentry ; une installation en un clic via la plateforme d'intégration de Sentry est sur la feuille de route mais pas construite, donc aujourd'hui c'est coller-un-DSN.

1. Dans Sentry, créez un projet, choisissez la plateforme Other, et copiez le DSN sur l'écran suivant. L'explicatif DSN montre quelle partie est la clé et quelle partie est l'ID du projet.
2. Dans le tableau de bord Elido, ouvrez Notifications, ajoutez un canal, choisissez Sentry, collez le DSN et, éventuellement, un nom d'environnement comme production.
3. Gardez les événements par défaut ou choisissez les vôtres. Les valeurs par défaut sont link.broken, link.expired, link.cap_reached et domain.ssl_failed.

Elido vérifie le DSN quand vous enregistrez : il doit être http ou https, inclure une clé publique, et se terminer par un ID de projet. Un DSN malformé est rejeté sur place plutôt que d'échouer silencieusement plus tard.

Si vous gérez la configuration comme du code, le même canal est un seul appel API. Les canaux sont des points d'entrée de webhook avec 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": "Santé de lien vers Sentry",
    "config": { "environment": "production", "release": "spring-campaign" }
  }'

Les livraisons Sentry ne sont pas signées HMAC, puisque Sentry authentifie la requête par sa clé à la place. Elles obtiennent quand même la politique normale de nouvelle tentative : trois tentatives au total, avec les nouvelles tentatives cinq et quinze minutes après un échec, puis la livraison est marquée échouée. Vous pouvez les lister à /v1/workspaces/{workspace_id}/webhooks/{id}/deliveries et en relancer une manuellement.

Il n'y a pas de bouton de test pour ce canal. Le test le plus propre que je connaisse : créez un lien jetable avec une expiration à une ou deux minutes et attendez. Elido scanne les liens nouvellement expirés toutes les cinq minutes, donc une issue de niveau error devrait atterrir dans Sentry peu après.

Une fois que les événements de santé de lien atterrissent dans Sentry, la question suivante est ce que vous allez en faire, et cela dépend de la façon dont Sentry les regroupe. Si vous êtes encore en train de choisir un plan, comparez ce qu'inclut chaque niveau avant de câbler le canal.

Comment Sentry regroupe les événements de santé de lien Elido

Ces événements n'ont ni trace de pile ni exception, donc le regroupement de secours de Sentry les regroupe par message. En pratique, cela signifie une issue par type d'événement : tous les événements de lien cassé deviennent une issue dont le nombre d'événements grimpe, toutes les expirations une autre.

C'est utile pour les alertes et moins utile pour le tri. Deux ajustements aident :

• Définissez l'environnement sur le canal. Avec des canaux séparés par espace de travail ou par environnement (production, campaigns), chacun obtient son propre filtre dans le flux d'issues, et vous pouvez cibler des règles d'alerte sur un seul.
• Ajoutez une règle d'empreinte dans les paramètres du projet Sentry sur tags.workspace_id si vous acheminez plusieurs espaces de travail vers un seul projet et voulez une issue par espace de travail.

Pour les alertes, construisez sur les propres règles d'alerte d'issue de Sentry : « une nouvelle issue est créée » capture le premier lien cassé, et « l'issue est vue plus de N fois en une heure » capture un lot, disons une campagne entière dont le domaine de destination est tombé. Gardez à l'esprit le rythme de détection derrière tout ça. La vérification de destination tourne une fois par jour, le premier échec se déclenche immédiatement, et un lien qui reste cassé se redéclenche après 24 heures. Sentry est la bonne boîte de réception pour ça. Ce n'est pas un détecteur de panne en cinq minutes, et je ne prétendrai pas le contraire.

Où se situe Datadog dans la surveillance de redirection

Datadog reçoit les clics, pas la santé des liens. Chaque clic devient un journal envoyé à l'ingestion de logs de votre site Datadog, avec la source elido, les tags workspace_id, vendor:elido et link_id, et les champs de clic sous attributes. Une fois par minute, Elido envoie aussi trois jauges par espace de travail : elido.clicks, elido.clicks_by_country et elido.clicks_by_device.

Ce qui n'est pas là compte tout autant. Pas de métrique de latence, pas de codes de statut, pas de domaine, de niveau ou de tags de région. Un envoi de journal échoué reçoit une nouvelle tentative puis est abandonné. Les paramètres sont mis en cache jusqu'à cinq minutes, donc une clé nouvellement enregistrée met un moment à s'activer, et le bouton Tester la connexion du tableau de bord envoie un journal de test et affiche la réponse de Datadog, ce qui repère une clé ou un site erroné mais pas un pipeline qui abandonne les journaux, donc un vrai clic reste la preuve que ça fonctionne.

Le travail de Datadog ici est donc le trafic : volume de clics par minute, pays principaux, et un moniteur pour « les clics sont tombés à près de zéro ». Le guide de surveillance d'URL Datadog a les requêtes, les étapes de configuration et la page d'intégration liste les champs. Réconciliez les totaux avec les analyses de clics d'Elido, qui restent la référence exacte.

Surveiller la latence de redirection depuis l'extérieur

Pour le signal de vitesse, pointez une vérification synthétique vers un lien court canari : un lien que vous créez uniquement pour la surveillance, afin que les sondes ne se mélangent jamais aux chiffres de campagne. Les tests HTTP de Datadog font bien ce travail, et tout service de disponibilité pouvant sauter les redirections fonctionne aussi.

Trois réglages déterminent si le chiffre a du sens :

• Désactivez le suivi de redirection. Vous voulez le temps jusqu'au retour du 301 ou 302, pas le temps que met votre page de destination à s'afficher.
• Vérifiez le code de statut et l'en-tête Location, pour qu'une redirection vers le mauvais endroit fasse échouer le test.
• Envoyez un User-Agent contenant bot. Elido saute les événements de clic pour les agents robots connus, donc votre sonde ne gonflera pas les comptes de clics.

Exécutez la sonde depuis des emplacements proches de votre audience. Une redirection en cache dans la région devrait rester bien en dessous du budget p95 de 15 ms, et un bond soutenu mérite une alerte. Un test contre votre domaine personnalisé vous dit aussi si son certificat TLS fonctionne toujours, ce qu'un transmetteur de clics ne pourrait jamais faire.

Quel outil pour quoi

Voici la répartition que je mettrais en place pour une équipe menant des campagnes payantes sur des liens courts :

Une petite équipe peut commencer avec le seul canal Sentry ; il couvre les défaillances qui gaspillent silencieusement le budget publicitaire. Ajoutez Datadog une fois que quelqu'un regarde réellement les tableaux de bord de trafic, et ajoutez la sonde le jour où une redirection lente vous coûterait de l'argent. Si Sentry n'est pas la boîte de réception de votre équipe, les mêmes événements de santé de lien vont vers Discord ou Telegram, et un lien cassé peut aussi ouvrir un ticket Linear.

Lisez le pilier → Atteindre un p95 sous 15 ms pour les redirections

À lire aussi sur le blog

• Surveillance d'URL Datadog pour les liens courts - métriques de clics, journaux et un tableau de latence Synthetics.
• Stratégie de prévention de la pourriture de liens - que faire après qu'une issue de lien cassé atterrit.
• Alertes Discord et Telegram pour les liens courts - les mêmes événements de santé de lien dans un canal de discussion.
• Tickets Linear depuis les alertes de lien - transformer un lien cassé en tâche suivie.