Monitoring d'URL Datadog : métriques de redirection pour les liens courts

Le monitoring d'URL Datadog des liens courts Elido repose sur deux sources. Elido envoie lui-même les données de clics : un journal par clic vers l'endpoint d'ingestion des journaux Datadog, plus trois métriques de nombre de clics envoyées toutes les 60 secondes. Il n'envoie ni la latence des redirections ni les codes d'état. Pour ces données, vous dirigez un test HTTP Datadog Synthetics vers un lien court canari, puis le tableau de bord de latence des redirections, les moniteurs et le SLO reposent tous sur ce duo.

Cette séparation constitue tout le fonctionnement. Le volet clics vous indique combien de personnes ont suivi vos liens et d'où elles venaient, tandis que le volet synthétique vous indique si la redirection a répondu, à quelle vitesse et avec le bon état. Cet article couvre la forme exacte des métriques et des journaux, la manière de les relier, les éléments à placer sur le tableau de bord et les limites de l'ensemble.

Si la latence est la raison de votre venue, lisez d'abord le fonctionnement du budget p95 inférieur à 15 ms. Vous y verrez à quoi ressemble une valeur saine avant de choisir un seuil.

Ce qu'Elido envoie réellement à Datadog

Chaque clic dans un espace de travail connecté suit deux chemins. Le chemin des journaux envoie un lot d'une seule entrée à https://http-intake.logs.<site>/api/v2/logs, juste après l'enregistrement du clic. Le chemin des métriques incrémente un compteur en mémoire, puis un flusher envoie les nombres à https://api.<site>/api/v2/series une fois par minute. Les deux s'authentifient avec l'en-tête DD-API-KEY.

Les métriques sont des jauges, et la valeur correspond au nombre de clics comptés depuis l'envoi précédent. Ainsi, un point de 37 signifie 37 clics environ au cours de la dernière minute. C'est l'unité naturelle d'un graphique d'exploitation, et cela signifie que vous devez additionner les valeurs dans le temps pour obtenir les totaux, plutôt que d'appliquer as_count(). Notez ce qui manque : les métriques ne comportent ni tag link_id ni tag slug. Je considère que c'est un choix raisonnable du point de vue des coûts, car Datadog facture les métriques personnalisées selon chaque combinaison de tags unique, et un tag slug dans un espace de travail très actif multiplierait le nombre de séries par le nombre de liens.

Les champs des journaux arrivent imbriqués dans un objet attributes, si bien que, dans Log Explorer, les facettes ressemblent à @attributes.slug et @attributes.country. Développez un journal avant de construire quoi que ce soit. Dix secondes vous épargneront une requête défectueuse.

Connecter Datadog à votre espace de travail Elido

La configuration comporte deux champs. Vous avez besoin d'une clé API Datadog, et non d'une clé d'application, ainsi que du site sur lequel votre organisation est hébergée.

1. Dans Datadog, ouvrez Organization Settings, puis API Keys, et créez-en une nommée par exemple elido-forwarder.
2. Vérifiez votre site. Le guide des sites Datadog associe chaque URL de connexion à son site ; app.datadoghq.eu signifie que vous devez saisir datadoghq.eu, tandis que us5.datadoghq.com signifie que vous devez saisir exactement cette valeur.
3. Dans Elido, ouvrez Integrations, choisissez Datadog, collez la clé, saisissez le site et enregistrez. La clé est chiffrée au repos.
4. Attendez jusqu'à cinq minutes, car le forwarder met en cache les réglages d'intégration de l'espace de travail, puis cliquez sur l'un de vos propres liens depuis un téléphone et recherchez source:elido dans Log Explorer.

Laissez le site vide et Elido utilise datadoghq.com. Pour une organisation de l'UE, c'est l'échec silencieux classique. Une faute de frappe produit le même résultat. Chaque POST échoue et personne ne voit l'erreur.

Le bouton Test connection envoie un journal de test (marqué elido_test: true) vers votre site Datadog et affiche la réponse de Datadog. Une clé ou un site incorrect échoue donc immédiatement avec le 403 de Datadog. Une réussite prouve que la clé fonctionne, mais pas que vos pipelines et vos index conservent les journaux ; la véritable preuve reste l'apparition d'un journal de clic. Même règle que pour le forwarder de clics Mixpanel : un vrai clic, sinon rien.

Construire un tableau de bord de latence des redirections qui mesure l'étape de redirection

Puisqu'Elido n'envoie pas les durées, les données de latence doivent venir d'un élément qui effectue des requêtes. Un test HTTP Datadog Synthetics est l'outil adapté, et il mesure ce que ressent le visiteur, DNS et TLS compris.

Voici le test que je configure dans chaque espace de travail :

• URL : un lien canari dédié, idéalement sur votre propre domaine personnalisé, qui pointe vers quelque chose de banal et stable.
• Follow redirects : désactivé. Lorsque cette option est activée, vous mesurez votre page de destination, et une image principale lente vous réveillera à 3 h du matin pour une redirection qui fonctionnait parfaitement.
• Assertions : le code d'état est 302 (la valeur par défaut ; utilisez 301 ou 307 si c'est ce que vous avez configuré, et 301 contre 302 explique le compromis), l'en-tête location contient votre destination et le temps de réponse est inférieur à un seuil.
• Emplacements : au moins trois, dont un dans la région de l'UE où se trouve votre audience. Exécutez le test chaque minute.
• En-tête : un User-Agent contenant bot, afin qu'Elido traite la sonde comme un bot et ignore l'événement de clic.

Choisissez le seuil à partir de ce que vous observez pendant une semaine, et non d'après un article de blog. Les durées synthétiques incluent le propre chemin réseau de la sonde, si bien qu'une sonde située sur un autre continent n'atteindra jamais une valeur régionale, et ce n'est pas un problème. Ce que vous voulez, c'est une ligne qui reste stable.

Le tableau de bord a ensuite besoin de quatre widgets. Le temps de réponse par emplacement, sous forme de série temporelle du test synthétique. Le taux de réussite des assertions. Les clics par minute provenant de elido.clicks. Et une liste des principaux pays.

# 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')

Pourquoi default_zero ? Parce qu'une minute sans clic ne produit aucun point et que, sans la fonction d'interpolation, Datadog trace une ligne droite à travers le trou. Cette ligne ment.

Moniteurs pour les baisses de clics et les liens courts défectueux

Trois moniteurs couvrent la plupart des problèmes liés aux liens, et chacun utilise une source différente. C'est là que la séparation de la première section prend tout son sens.

Redirection défectueuse ou lente. Le test synthétique est déjà un moniteur. Déclenchez une alerte lorsque deux emplacements ou plus échouent lors de la même exécution, afin qu'une seule région de sonde instable ne réveille personne. Toute réponse autre que votre 302 fait échouer l'assertion de statut, si bien qu'un lien canari supprimé, expiré ou mis en pause apparaît ici sous la forme d'une 404 ou d'une 410.

Trafic à l'arrêt. Créez un moniteur de métrique sur sum:elido.clicks{workspace_id:42} et activez la notification pour les données manquantes après, disons, 30 minutes. Puisqu'Elido n'envoie rien pendant une minute calme, "no data" signifie réellement "no clicks" ici, et c'est l'événement qui vous intéresse pendant une campagne.

Trafic inhabituel. Un moniteur d'anomalie sur la même métrique, avec la direction réglée sur below, détecte une campagne qui réalise normalement 4 000 clics par heure et qui tombe soudainement à 200. J'ai vu ce schéma trois fois, et chaque fois la cause se trouvait en dehors du lien : une publicité refusée, une newsletter envoyée au mauvais segment, une affiche QR masquée par un échafaudage. Donnez-lui quelques semaines d'historique avant de faire confiance à ses bandes.

Vous voulez des alertes par lien ? Les métriques ne le permettent pas, mais les journaux oui. Créez une métrique fondée sur les journaux à partir de source:elido, regroupée par @attributes.slug, et vous obtiendrez un nombre de clics par slug que vous pourrez surveiller. Limitez-la à un ensemble filtré de slugs de campagne, sinon le coût de cardinalité reviendra par la porte de derrière.

Un SLO que vous pouvez réellement défendre

Un objectif de niveau de service sur un lien court n'a de sens que si sa source mesure la redirection. Construisez-le sur le test synthétique. Un SLO fondé sur un moniteur utilisant ce test unique comme moniteur fait l'affaire.

Je commencerais à 99,9 % sur 30 jours. Cela représente environ 43 minutes de contrôles échoués par mois, et c'est un budget que vous pouvez expliquer en une phrase à un responsable marketing. Ne le construisez pas sur le volume de clics. Les clics mesurent la demande, pas la santé ; un lien sur lequel personne ne clique peut être parfaitement disponible.

Si la ligne stable de ce widget SLO est ce qui vous manquait, créez un espace de travail, dirigez le lien canari vers votre propre domaine et faites-le fonctionner pendant une semaine avant de définir la cible.

Elido auto-hébergé : récupérer les compteurs de redirection

Avec une installation auto-hébergée, vous disposez d'une source supplémentaire. Le service de redirection expose un endpoint Prometheus à /metrics, que le contrôle OpenMetrics de l'agent Datadog peut récupérer. La série utile est elido_edge_redirect_total, un compteur comportant les labels fleet et outcome, dont les valeurs incluent ok, notfound, expired, paused et error.

Cela vous donne ce que l'intégration SaaS ne donne pas : un véritable taux de 404 sur l'ensemble du trafic, calculé comme notfound sur le total. Un deuxième compteur, edge_redirect_clicks_filtered_bot_total, indique combien de redirections ont été servies à des bots sans événement de clic. Cet endpoint ne comporte toutefois aucun histogramme de latence. La latence provient toujours de Synthetics, que l'installation soit auto-hébergée ou non. Le guide d'auto-hébergement k3s explique où se trouve cet endpoint dans le déploiement.

Les limites de l'intégration Datadog

Voici maintenant les limites susceptibles de vous affecter en premier.

La livraison se fait au mieux. Un POST de journal échoué fait l'objet d'une seule nouvelle tentative après une seconde, puis est abandonné. Un envoi de métriques échoué n'est pas retenté du tout ; la minute est perdue et la fenêtre suivante recommence à zéro. Considérez elido.clicks comme une ligne de tendance et rapprochez les totaux des propres analyses de clics d'Elido, qui constituent la source de vérité.

Les journaux contiennent l'adresse IP du visiteur et l'URL de destination complète, y compris les tags UTM. Si votre organisation Datadog se trouve aux États-Unis, il s'agit de données personnelles qui quittent l'UE, et le guide de résidence des données dans l'UE pour les équipes marketing explique comment évaluer cette situation. Au minimum, choisissez le site de l'UE si vous en avez un.

Le coût des journaux évolue avec le nombre de clics, à raison d'un journal ingéré par clic. Un lien viral produit une facture virale. Les filtres d'exclusion, ou une métrique fondée sur les journaux associée à un index à courte rétention, permettent de garder la situation sous contrôle.

Et le périmètre se limite aux clics. Aucun événement de création de lien, aucune conversion, aucune latence, aucun code d'état. Honnêtement, je ne suis pas certain qu'un forwarder de clics doive transporter la latence ; la sonde qui mesure depuis l'extérieur est de toute façon un témoin plus fiable.

Consultez l'article de référence → Atteindre un p95 inférieur à 15 ms pour les redirections

Articles associés sur le blog

• Suivi des liens Mixpanel - le même forwarder de clics, dirigé vers l'analytics produit.
• Stratégie de cache pour les redirections d'URL - pourquoi la latence des redirections se présente ainsi.
• Stratégie de prévention des liens morts - que faire après le déclenchement du moniteur de 404.
• Clics sur les liens courts contre sessions GA4 - pourquoi vos nombres de clics et vos sessions d'analytics ne concordent pas.
• Suivi côté serveur GA4 via les redirections - des événements de clic côté serveur, envoyés à Google à la place.
• Suivi des liens Klaviyo - le même forwarder de clics, qui envoie chaque clic dans Klaviyo.