Datadog URL-monitoring: redirectmetrics voor korte links

Datadog URL-monitoring voor Elido-korte links komt uit twee bronnen. Elido zelf stuurt klikdata: één log per klik naar de Datadog Logs-intake, plus drie klikaantalmetrics die elke 60 seconden worden verzonden. Redirectlatentie of statuscodes stuurt het niet. Daarvoor richt je een Datadog Synthetics HTTP-test op een canary-korte-link, en het dashboard voor redirectlatentie, de monitors en de SLO zitten allemaal bovenop dat tweetal.

Die splitsing is het hele ontwerp. De klikkant vertelt hoeveel mensen door je links gingen en vanwaar, en de synthetic-kant vertelt of de redirect antwoordde, hoe snel en met de juiste status. Dit artikel behandelt de exacte vormen van metrics en logs, hoe je ze koppelt, wat op het dashboard hoort en waar het ophoudt.

Ben je hier vanwege latentie, lees dan eerst hoe het p95-budget onder 15 ms werkt. Het legt uit hoe een gezond getal eruitziet voordat je een drempel kiest.

Wat Elido echt naar Datadog stuurt

Elke klik in een gekoppelde werkruimte neemt twee paden. Het logpad post een batch van één item naar https://http-intake.logs.<site>/api/v2/logs, direct nadat de klik is vastgelegd. Het metricspad verhoogt een in-memory teller, en een flusher post de aantallen eenmaal per minuut naar https://api.<site>/api/v2/series. Beide authenticeren met de header DD-API-KEY.

De metrics zijn gauges, en de waarde is het aantal klikken dat sinds de vorige flush is geteld. Een punt van 37 betekent dus 37 klikken in ongeveer de laatste minuut. Dat is de natuurlijke eenheid voor een ops-grafiek, en het betekent dat je over tijd optelt voor totalen in plaats van as_count() toe te passen. Let op wat ontbreekt: er zit geen tag link_id of slug op de metrics. Ik noem dat een verstandige keuze qua kosten, want Datadog factureert custom metrics per unieke tagcombinatie, en een slug-tag op een drukke werkruimte zou het aantal reeksen vermenigvuldigen met het aantal links.

De log draagt link_id ook als Datadog-tag en is getagd met service:click-ingester en host elido-edge, dus dat is de servicenaam om op te filteren. De velden komen genest onder een object attributes binnen, dus in Log Explorer zien de facetten eruit als @attributes.slug en @attributes.country. Klap één log open voordat je iets bouwt. Tien seconden, en het scheelt een kapotte query.

Datadog koppelen in je Elido-werkruimte

De setup bestaat uit twee velden. Je hebt een Datadog API-sleutel nodig (geen applicatiesleutel) en de site waarop je organisatie draait.

1. Open in Datadog Organization Settings, dan API Keys, en maak er een met een naam als elido-forwarder.
2. Controleer je site. De Datadog-sitegids koppelt elke inlog-URL aan zijn site; app.datadoghq.eu betekent dat je datadoghq.eu invoert, us5.datadoghq.com betekent dat je precies dat invoert.
3. Open in Elido Integraties, kies Datadog, plak de sleutel, typ de site en sla op. De sleutel wordt versleuteld opgeslagen.
4. Wacht maximaal vijf minuten, want de forwarder cachet de integratie-instellingen van de werkruimte, klik dan vanaf een telefoon op een van je eigen links en zoek source:elido in Log Explorer.

Laat je de site leeg, dan neemt Elido datadoghq.com aan. Voor een EU-organisatie is dat de klassieke stille fout. Een typfout doet hetzelfde. Elke POST mislukt en niemand ziet de fout.

De knop Verbinding testen stuurt één testlog (gemarkeerd met elido_test: true) naar je Datadog-site en toont het antwoord van Datadog, zodat een verkeerde sleutel of site daar meteen faalt met de 403 van Datadog. Een geslaagde test bewijst dat de sleutel werkt, niet dat je pipelines en indexen de logs bewaren, dus het echte bewijs blijft een kliklog die verschijnt. Dezelfde regel als bij de Mixpanel-klikforwarder: een echte klik, anders is het niet gebeurd.

Een dashboard voor redirectlatentie dat de stap meet

Omdat Elido geen timings stuurt, moet de latentiedata komen van iets wat zelf verzoeken doet. Een Datadog Synthetics HTTP-test is daarvoor het juiste gereedschap, en meet wat de bezoeker voelt, inclusief DNS en TLS.

Dit is de test die ik in elke werkruimte opzet:

• URL: een speciale canary-link, bij voorkeur op je eigen domein, die naar iets saais en stabiels wijst.
• Redirects volgen: uit. Staat het aan, dan meet je je landingspagina, en een trage heroafbeelding pagineert je om 3 uur 's nachts voor een redirect die prima was.
• Assertions: de statuscode is 302 (de standaard; gebruik 301 of 307 als je die hebt ingesteld, en 301 vs. 302 legt de afweging uit), de location-header bevat je bestemming en de responstijd ligt onder een drempel.
• Locaties: minstens drie, waarvan één in de EU-regio van je publiek. Draai elke minuut.
• Header: een User-Agent met bot, zodat Elido de probe als bot behandelt en het klikevent overslaat.

Kies de drempel op basis van wat je een week lang waarneemt, niet op basis van een blogartikel. Synthetic timings bevatten het eigen netwerkpad van de probe, dus een probe op een ander continent komt nooit overeen met een getal in de regio, en dat is prima. Wat je wilt is een lijn die vlak blijft.

Het dashboard heeft dan vier widgets nodig. Responstijd per locatie, als tijdreeks van de synthetic test. Het slagingspercentage van de assertions. Klikken per minuut uit elido.clicks. En een toplijst van landen.

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

Waarom default_zero? Omdat een minuut zonder klikken helemaal geen punt oplevert, en zonder de interpolatiefunctie trekt Datadog een rechte lijn over het gat. Die lijn liegt.

Monitors voor klikdalingen en kapotte korte links

Drie monitors dekken het meeste van wat er met links misgaat, en elk gebruikt een andere bron, en daar loont de splitsing uit het eerste gedeelte.

Redirect kapot of traag. De synthetic test is zelf al een monitor. Alarmeer wanneer twee of meer locaties in dezelfde run falen, zodat één wankele proberegio niemand wakker maakt. Elk ander antwoord dan je 302 laat de statusassertion falen, dus een verwijderde, verlopen of gepauzeerde canary-link verschijnt hier als 404 of 410.

Verkeer gestopt. Maak een metricmonitor op sum:elido.clicks{workspace_id:42} en zet de melding voor ontbrekende data aan na bijvoorbeeld 30 minuten. Omdat Elido in een stille minuut niets stuurt, betekent "geen data" hier echt "geen klikken", en dat is het event waar je tijdens een campagne om geeft.

Verkeer vreemd. Een anomaliemonitor op dezelfde metric, met de richting op onder, vangt een campagne die normaal 4.000 klikken per uur doet en plotseling 200. Ik heb dat patroon drie keer gezien, en elke keer lag de oorzaak buiten de link: een afgekeurde advertentie, een nieuwsbrief die naar het verkeerde segment ging, een QR-poster achter een steiger. Geef hem een paar weken historie voordat je zijn banden vertrouwt.

Wil je alerting per link? De metrics kunnen dat niet, de logs wel. Maak een log-based metric van source:elido gegroepeerd op @attributes.slug, en je krijgt een klikaantal per slug dat je kunt monitoren. Beperk het tot een gefilterde set campagneslugs, anders komen de cardinaliteitskosten via de achterdeur terug.

Een SLO die je kunt verdedigen

Een service level objective op een korte link betekent alleen iets als de bron de redirect meet. Bouw hem op de synthetic test. Een monitorgebaseerde SLO met die ene test als monitor doet het werk.

Ik zou beginnen met 99,9% over 30 dagen. Dat is ongeveer 43 minuten mislukte checks per maand, en het is een budget dat je in één zin aan een marketinglead kunt uitleggen. Bouw hem niet op klikvolume. Klikken meten vraag, geen gezondheid; een link waar niemand op klikt is perfect beschikbaar.

Als een vlakke lijn op die SLO-widget is wat je miste, maak een werkruimte aan, richt de canary op je eigen domein en laat hem een week draaien voordat je het doel bepaalt.

Zelf gehost Elido: de redirecttellers scrapen

Draai je de redirectservice zelf (alleen mogelijk als Enterprise-contractimplementatie in je eigen infrastructuur; Elido wordt niet als downloadbaar self-hosted product verkocht), dan heb je nog een bron. De redirectservice stelt een Prometheus-endpoint beschikbaar op /metrics, en de OpenMetrics-check van de Datadog Agent kan die scrapen. De bruikbare reeks is elido_edge_redirect_total, een teller met de labels fleet en outcome, waarbij de uitkomsten onder meer ok, notfound, expired, paused, disabled, blocked, capped en error zijn.

Dat geeft je wat de SaaS-integratie niet geeft: een echt 404-percentage over al het verkeer, berekend als notfound gedeeld door het totaal. Een tweede teller, edge_redirect_clicks_filtered_bot_total, toont hoeveel redirects aan bots zijn bediend zonder klikevent. Er is op dat endpoint echter geen latentiehistogram. Latentie komt ook zelf gehost nog steeds uit Synthetics. De k3s-playbook voor zelf hosten behandelt waar dat endpoint in de deployment zit.

Waar de Datadog-integratie ophoudt

Nu de beperkingen, de meest waarschijnlijke eerst.

De aflevering is best effort en komt uit de klikpijplijn, dus kan een moment achterlopen op de redirect. Een mislukte log-POST krijgt na een seconde één nieuwe poging en daarna vervalt hij. Een mislukte metricsflush wordt helemaal niet opnieuw geprobeerd; die minuut is weg en het volgende venster begint schoon. Beschouw elido.clicks als een trendlijn en reconcilieer totalen met de eigen klikanalytics van Elido, de bron van waarheid.

De logs dragen het IP van de bezoeker en de volledige bestemmings-URL, UTM-tags inbegrepen. Zit je Datadog-organisatie in de VS, dan verlaten persoonsgegevens de EU, en de gids over dataresidentie in de EU voor marketingteams legt uit hoe je dat weegt. Kies minstens de EU-site als je er een hebt.

De logkosten schalen met klikken, één opgenomen log per klik. Een virale link geeft een virale rekening. Uitsluitingsfilters, of een log-based metric samen met een index met korte bewaartermijn, houden het redelijk.

En de reikwijdte is klikken. Geen events voor aangemaakte links, geen conversies, geen latentie, geen statuscodes. Eerlijk gezegd weet ik niet zeker of een klikforwarder latentie moet dragen; de probe die van buitenaf meet is toch de eerlijker getuige.

De hierboven gelinkte Datadog-docpagina's zijn geraadpleegd op 2026-10-25. Voor het latentiebudget achter de redirect, zie het artikel over p95 onder 15 ms

Gerelateerd op de blog

• Mixpanel-linktracking - dezelfde klikforwarder, gericht op productanalytics.
• Cachestrategie voor URL-redirects - waarom redirectlatentie eruitziet zoals hij eruitziet.
• Strategie tegen linkrot - wat je doet nadat de 404-monitor afgaat.
• Klikken op korte links vs. GA4-sessies - waarom je klikaantallen en analyticssessies verschillen.
• Server-side GA4-tracking via redirects - server-side klikevents, in plaats daarvan naar Google gestuurd.
• Klaviyo-linktracking - dezelfde klikforwarder, die elke klik naar Klaviyo stuurt.