Kurzlink-Monitoring mit Sentry und Datadog: Wer macht was

Kurzlink-Monitoring teilt sich sauber zwischen den beiden Tools auf. Sentry ist der Ort, an den Elido Link-Health-Events sendet: eine Zielseite, die nicht mehr antwortet, ein abgelaufener Link, ein erreichter Klick-Cap, eine Custom Domain, deren Verifizierung fehlgeschlagen ist. Datadog ist der Ort, an den Elido Klicks sendet, ein Log pro Besuch und drei Klick-Zähl-Metriken pro Minute. Redirect-Latenz geht an keines von beiden, weil Elido sie nicht exportiert; du misst sie von außen mit einer synthetischen Probe.

Dieser Beitrag ist die Sentry-Hälfte dieses Bilds, dazu eine klare Antwort auf "welches Tool wofür". Wenn du wegen Datadog-Dashboards hier bist: Der Leitfaden zu Datadog-Redirect-Metriken behandelt die Klick-Metriken, die Log-Struktur und ein Synthetics-basiertes Latenz-Board ausführlich, daher wiederhole ich das hier nicht.

Noch ein Stück Kontext vor der Verkabelung. Ein Redirect kann völlig gesund sein, während der Link tot ist: Die Kurz-URL antwortet in wenigen Millisekunden und schickt Leute zu einer 404. Deshalb braucht URL-Monitoring für Kurzlinks sowohl ein zielbewusstes Signal als auch ein Geschwindigkeitssignal, und deshalb liefert kein einzelnes Tool beides aus einem Feed. Die p95-unter-15ms-Analyse erklärt, wie "gesund" auf der Geschwindigkeitsseite aussieht.

Was Kurzlink-Monitoring erfassen muss

Ich sortiere Fehler in drei Kategorien, weil jede ein anderes Tool braucht.

Der Link ist kaputt. Seine Zielseite liefert einen 4xx oder 5xx, läuft in ein Timeout, oder die Domain lässt sich nicht mehr auflösen. Dein Redirect funktioniert noch, leitet Leute aber jetzt auf eine Fehlerseite weiter. Elido findet das mit einer täglichen Zielprüfung und löst link.broken aus.

Der Link wurde absichtlich gestoppt. Er hat sein Ablaufdatum oder seinen Klick-Cap erreicht, also hat Elido die Weiterleitung eingestellt. Technisch ist nichts falsch, aber wenn eine Kampagne noch darauf zeigt, muss es jemand wissen. Das sind link.expired und link.cap_reached. Eine Custom Domain, deren Verifizierung nie geklappt hat, löst domain.ssl_failed aus, was in denselben Topf gehört.

Der Redirect selbst wurde langsam oder ist ausgefallen. Das ist das Geschwindigkeitssignal, und genau das gibt Elido nicht als Metrik aus. Du beobachtest es von außen.

Traffic ist ein viertes Signal, aber ein weicheres. Eine Kampagne, die normalerweise Tausende Klicks pro Stunde macht und plötzlich nur noch ein paar Dutzend, bedeutet meist, dass sich vorgelagert etwas geändert hat, etwa eine pausierte Anzeige oder ein abgelöster QR-Aufkleber. Klickzahlen leben in Datadog, dort gehört also der Drop-Monitor hin.

Was Elido an Sentry sendet

Sentry ist einer der ausgehenden Kanal-Typen in Elidos Benachrichtigungssystem, neben Discord, Telegram und einfachen signierten Webhooks. Es nutzt dieselbe Zustellpipeline wie Webhooks, mit einem Unterschied: Statt des rohen Elido-Events postet es ein kleines Sentry-Event.

Jede Zustellung ist ein JSON-Event, das an den Store-Endpunkt deines Projekts gesendet wird, den Elido aus der DSN ableitet. Bei https://[email protected]/8 ist das Ziel https://o4711.ingest.sentry.io/api/8/store/, und der öffentliche Key geht in den X-Sentry-Auth-Header. Nirgendwo im Pfad steckt eine Sentry-SDK, und weil der DSN-Host geparst statt hart codiert wird, funktioniert ein selbst gehosteter Sentry-kompatibler Server genauso. Der Payload folgt dem Sentry-Event-Payload-Format:

{
  "event_id": "9f0c4e1b2a7d4c33b8e5d6a1f2c3b4a5",
  "timestamp": 1790000000,
  "level": "error",
  "logger": "elido",
  "platform": "other",
  "message": "<humanized event name, e.g. Link / Broken>",
  "environment": "production",
  "tags": { "event_type": "link.broken", "workspace_id": "42" }
}

Das Level wird aus dem Event-Namen abgeleitet. Alles, was bedeutet "dieser Link funktioniert gerade nicht", kommt als error an: .broken, .expired, cap_reached, ssl_failed. Löschungen und Downgrades kommen als warning an, alles andere als info.

Jetzt der ehrliche Teil zu den Tags. Jedes Event trägt die Tags event_type und workspace_id, und die Felder environment und release werden gefüllt, wenn du sie am Kanal festlegst. Ein Cap-reached-Event trägt zusätzlich ein clicks-Tag. Das Broken-Link-Event trägt heute allerdings weder den Slug noch das Ziel als Tag, das Sentry-Issue sagt dir also nur, dass ein Link im Workspace 42 kaputt ist, und du öffnest die Link-Liste in Elido, wo der defekte Link eine Markierung trägt. Das sage ich dir lieber jetzt, als dass du um 2 Uhr nachts nach einem slug-Tag suchst.

Einen Sentry-Kanal für Broken-Link-Alerts einrichten

Das Setup dauert ein paar Minuten, und die DSN ist die einzige Credential. Der Sentry-Kanal ist als Beta markiert, weil du das Sentry-Projekt selbst erstellst; eine Ein-Klick-Installation über Sentrys Integrationsplattform steht auf der Roadmap, ist aber noch nicht gebaut, heute heißt es also DSN einfügen.

1. Erstelle in Sentry ein Projekt, wähle die Plattform Other und kopiere die DSN vom nächsten Bildschirm. Der DSN-Erklärer zeigt, welcher Teil der Key ist und welcher die Projekt-ID.
2. Öffne im Elido-Dashboard Notifications, füge einen Kanal hinzu, wähle Sentry, füge die DSN ein und optional einen Umgebungsnamen wie production.
3. Behalte die Standard-Events oder wähle eigene. Die Standardwerte sind link.broken, link.expired, link.cap_reached und domain.ssl_failed.

Elido prüft die DSN beim Speichern: Sie muss http oder https sein, einen öffentlichen Key enthalten und mit einer Projekt-ID enden. Eine fehlerhafte DSN wird sofort abgelehnt, statt später stillschweigend zu scheitern.

Wenn du Config as Code verwaltest, ist derselbe Kanal ein einziger API-Aufruf. Kanäle sind Webhook-Endpunkte mit einem 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": "Link health to Sentry",
    "config": { "environment": "production", "release": "spring-campaign" }
  }'

Sentry-Zustellungen sind nicht HMAC-signiert, weil Sentry die Anfrage stattdessen über ihren Key authentifiziert. Sie bekommen aber die normale Retry-Policy: insgesamt drei Versuche, mit Wiederholungen fünf und fünfzehn Minuten nach einem Fehlschlag, danach wird die Zustellung als fehlgeschlagen markiert. Du kannst sie unter /v1/workspaces/{workspace_id}/webhooks/{id}/deliveries auflisten und eine davon manuell wiederholen.

Für diesen Kanal gibt es keinen Test-Button. Der sauberste Test, den ich kenne: Erstelle einen Wegwerf-Link mit einer Ablaufzeit ein bis zwei Minuten in der Zukunft und warte. Elido scannt alle fünf Minuten nach neu abgelaufenen Links, ein Issue auf Error-Level sollte also kurz danach in Sentry landen.

Sobald Link-Health-Events in Sentry landen, stellt sich die nächste Frage: Was machst du damit, und das hängt davon ab, wie Sentry sie gruppiert. Falls du noch einen Plan auswählst, vergleiche, was jede Stufe enthält, bevor du den Kanal verkabelst.

Wie Sentry Elidos Link-Health-Events gruppiert

Diese Events haben weder Stack Trace noch Exception, also gruppiert Sentrys Fallback-Gruppierung sie nach Message. In der Praxis bedeutet das ein Issue pro Event-Typ: Alle Broken-Link-Events werden zu einem Issue, dessen Event-Zahl steigt, alle Ablauf-Events zu einem anderen.

Das ist nützlich fürs Paging und weniger nützlich für die Triage. Zwei Anpassungen helfen:

• Setze die Umgebung am Kanal. Mit separaten Kanälen pro Workspace oder pro Umgebung (production, campaigns) bekommt jeder einen eigenen Filter im Issue-Stream, und du kannst Alert-Regeln auf einen davon eingrenzen.
• Füge in den Sentry-Projekteinstellungen eine Fingerprint-Regel auf tags.workspace_id hinzu, wenn du mehrere Workspaces in ein Projekt routest und ein Issue pro Workspace willst.

Fürs Alerting baust du auf Sentrys eigenen Issue-Alert-Regeln auf: "a new issue is created" fängt den ersten defekten Link ab, und "the issue is seen more than N times in an hour" fängt einen ganzen Schwung ab, etwa eine komplette Kampagne, deren Landing-Domain ausgefallen ist. Denk dabei an das Erkennungstempo dahinter. Die Zielprüfung läuft einmal täglich, der erste Fehlschlag löst sofort aus, und ein Link, der defekt bleibt, löst nach 24 Stunden erneut aus. Sentry ist dafür die richtige Inbox. Es ist kein Fünf-Minuten-Ausfall-Detektor, und das würde ich auch nicht behaupten.

Wo Datadog beim Redirect-Monitoring reinpasst

Datadog bekommt Klicks, keine Link-Health. Jeder Klick wird zu einem Log, das an die Logs-Intake deiner Datadog-Site gesendet wird, mit Source elido, den Tags workspace_id, vendor:elido und link_id, und den Klick-Feldern unter attributes. Einmal pro Minute sendet Elido außerdem drei Gauges pro Workspace: elido.clicks, elido.clicks_by_country und elido.clicks_by_device.

Was dort fehlt, ist genauso wichtig. Keine Latenz-Metrik, keine Status-Codes, keine Domain-, Tier- oder Region-Tags. Ein fehlgeschlagener Log-POST bekommt einen Retry und wird dann verworfen. Einstellungen werden bis zu fünf Minuten gecacht, ein neu gespeicherter Key braucht also einen Moment, bis er greift, und der Test-connection-Button im Dashboard sendet ein Test-Log und zeigt Datadogs Antwort an, was einen falschen Key oder die falsche Site aufdeckt, aber keine Pipeline, die die Logs verwirft - ein echter Klick ist also weiterhin der Beweis, dass es funktioniert.

Datadogs Aufgabe hier ist also Traffic: Klickvolumen pro Minute, Top-Länder und ein Monitor für "Klicks auf nahezu null gefallen". Der Leitfaden zu Datadog-URL-Monitoring hat die Queries und die Setup-Schritte, und die Integrationsseite listet die Felder. Gleiche die Summen mit Elidos Klick-Analytics ab, die weiterhin die Quelle der Wahrheit bleibt.

Redirect-Latenz von außen beobachten

Für das Geschwindigkeitssignal richtest du einen synthetischen Check auf einen Canary-Kurzlink: einen Link, den du nur fürs Monitoring erstellst, damit sich Probes nie mit Kampagnenzahlen vermischen. Datadogs HTTP-Tests machen das gut, und jeder Uptime-Dienst, der Redirects überspringen kann, funktioniert ebenso.

Drei Einstellungen entscheiden, ob die Zahl überhaupt etwas bedeutet:

• Schalte Redirect-Following aus. Du willst die Zeit bis zum 301 oder 302, nicht die Zeit, die deine Landingpage zum Rendern braucht.
• Prüfe den Status-Code und den Location-Header, damit ein Redirect an die falsche Stelle den Check fehlschlagen lässt.
• Sende einen User-Agent, der bot enthält. Elido überspringt Klick-Events für bekannte Bot-Agents, deine Probe bläht die Klickzahlen also nicht auf.

Lass die Probe von Standorten in der Nähe deiner Zielgruppe laufen. Ein Cache-Hit-Redirect in der Region sollte deutlich unter dem 15ms-p95-Budget liegen, und ein anhaltender Sprung ist einen Page wert. Ein Check gegen deine Custom Domain sagt dir außerdem, ob ihr TLS-Zertifikat noch funktioniert, was ein reiner Klick-Weiterleiter nie könnte.

Welches Tool wofür

Hier die Aufteilung, die ich für ein Team einrichten würde, das bezahlte Kampagnen über Kurzlinks fährt:

Ein kleines Team kann allein mit dem Sentry-Kanal starten; er deckt die Fehlschläge ab, die stillschweigend Werbebudget verbrennen. Füge Datadog hinzu, sobald jemand tatsächlich auf Traffic-Dashboards schaut, und füge die Probe an dem Tag hinzu, an dem ein langsamer Redirect dich Geld kosten würde. Wenn Sentry nicht die Inbox deines Teams ist, gehen dieselben Link-Health-Events an Discord oder Telegram, und ein defekter Link kann auch ein Linear-Ticket öffnen.

Lies den Cornerstone-Beitrag → p95 unter 15ms für Redirects erreichen

Weiterführend im Blog

• Datadog-URL-Monitoring für Kurzlinks - Klick-Metriken, Logs und ein Synthetics-Latenz-Board.
• Strategie gegen Link Rot - was nach einem Broken-Link-Issue zu tun ist.
• Discord- und Telegram-Alerts für Kurzlinks - dieselben Link-Health-Events in einem Chat-Kanal.
• Linear-Tickets aus Link-Alerts - aus einem defekten Link eine getrackte Aufgabe machen.