Kurzlink-Monitoring mit Sentry und Datadog

Wenn ein Kurzlink während einer Instagram-Kampagne 30 Sekunden lang 5xx zurückgibt, verlierst du schätzungsweise 4-7% der Kohorte. Die meisten Engineering-Teams erfahren es erst am nächsten Morgen, wenn jemand einen Slack-Screenshot einwirft. Diese Anleitung ist das Playbook, das wir bei Elido einsetzen, um Redirect-Ausfälle in unter 60 Sekunden zu erkennen - mit zwei Tools, die du wahrscheinlich bereits bezahlst: Sentry für Issues und Datadog für Metriken. Es ist dieselbe Verdrahtung, die wir für unsere eigenen Edge-POPs betreiben, die monatlich rund 240 Millionen Redirects bei einem p99 von 13 ms ausliefern.

Kurz zusammengefasst: Sentry kann bei Redirects eine Sache besonders gut, nämlich "ein Issue pro defektem Ziel, mit einer Liste der Slugs, die ihn getroffen haben." Datadog kann die orthogonale Sache: Zeitreihen. Du brauchst beides, und Elido sendet nativ an beide. Sentry ist derzeit im Beta-Stadium (DSN einfügen, fertig); Datadog ist Live mit einem dedizierten Metric-Collector. Im Folgenden: welche Signale wichtig sind, wie die Sentry-Verdrahtung intern funktioniert und was ein Datadog-Dashboard für Redirect-Gesundheit tatsächlich enthalten sollte.

Welche Signale beim Redirect-Monitoring zählen

Bevor du irgendetwas verdrahtest, entscheide, was dir wirklich wichtig ist. Redirect-Monitoring ist ein engeres Problem als vollständiges APM, und die Signalmenge ist überschaubar. Vier Signale decken ungefähr 95% der realen Incidents ab:

4xx-Redirect-Events. Ein 404 auf einem Kurzlink ist fast immer eines von drei Dingen: Ein Slug wurde gelöscht, ein Slug ist abgelaufen, oder jemand testet deine Domain systematisch durch. Ein 410 ist absichtlich und erzeugt viel Rauschen, daher unterdrücken wir ihn in Alerts. Ein 451 (Geo-Block) ist nur in der Gesamtheit interessant. Das 4xx-Volumen pro Event ist zu rauschintensiv für Paging; behandle es als Metrik, nicht als Issue.

5xx-Redirect-Events. Diese rechtfertigen eine On-Call-Benachrichtigung. Ein 5xx bedeutet, dass der Edge Redis (L2-Cache) nicht erreichen konnte, api-core (Origin-gRPC) nicht erreichen konnte oder die Ziel-URL bei einem HEAD-Check einen DNS-Fehler hatte. Jeder Fall hat ein anderes Runbook. Der Sentry-Transformer in api-core taggt die Ursache, sodass der Issue-Titel so etwas lautet wie 5xx: redis-timeout (12 Slugs betroffen, zuletzt vor 14s) statt einem generischen Internal Server Error.

Edge-Latenz p99. Ein Cache-HIT-Redirect sollte von jedem unserer drei POPs in unter 15 ms bei p99 ausgeliefert werden. Wir alarmieren, wenn p99 länger als 5 Minuten über 50 ms bleibt. Der Grund: Eine einzelne langsame Anfrage wird p99 nicht 5 Minuten lang anheben, aber ein Redis-Replikat, das aus der Synchronisation gerät, schon. Siehe Redirect p95 unter 15 ms für die Latenzbudget-Aufschlüsselung.

Click-Rate-Anomalie und Scan-Fehler. Click-Rate-Anomalien sind das Frühwarnsystem. Wenn eine Kampagne normalerweise 4.000 Klicks/Stunde hat und plötzlich nur 200, ist vorgelagert etwas kaputtgegangen (deine Anzeige wurde abgelehnt, dein QR-Sticker ist abgefallen, jemand hat den falschen Link gezogen). Scan-Fehler kommen vom url-scanner-Service, der Ziele auf Malware überprüft. Ein Anstieg von Scan-Fehlern deutet meist darauf hin, dass ein Konto kompromittiert wurde und Phishing-Links erstellt.

Signale dem richtigen Tool zuordnen

Nicht jedes Signal gehört in jedes Tool. 4xx-Volumen als Issues an Sentry zu schicken, begräbt das eigentliche "defekter-Ziel"-Issue unter Rauschen. p99-Latenz als Alerts an Sentry zu schicken ist umständlich, weil Sentys Alerting um Issue-Häufigkeit herum gebaut ist, nicht um Zeitreihen. Das Denkmodell: Sentry = Exceptions, Datadog = Metriken, Slack = Menschen, Linear = Follow-up-Tickets.

Elido sendet dort, wo das X gesetzt ist. Wir schicken 4xx-Events nicht an Sentry, weil es keine Exceptions sind. Wir schicken auch nicht jeden Click-Event an Datadog, weil das Volumen den Aufwand nicht rechtfertigt (Datadog Custom Metrics werden pro eindeutiger Tag-Kombination abgerechnet, und die Kardinalität von Slug x Region x Tier würde einen mittelgroßen Workspace $4.000/Monat kosten). Die obige Aufteilung ist das Ergebnis von 9 Monaten internem Betrieb.

Sentry-Verdrahtung: DSN einfügen und der Envelope-Transformer

Die Sentry-Integration in Elido ist im Beta-Stadium, aber funktional vollständig. Die Einrichtung dauert drei Klicks. Du gehst zu /integrations, suchst Sentry, fügst einen DSN ein und wählst, welche Event-Typen weitergeleitet werden sollen. Der DSN ist das einzige Secret. Wir speichern ihn in Postgres mit Envelope-Verschlüsselung (KMS-wrapped per ADR-0036), sodass selbst unsere DB-Admins ihn nicht im Klartext lesen können.

Was im Hintergrund passiert: api-core hat einen Webhook-Transformer, der den internen Event-Bus (Redpanda-Topic redirect.errors) abonniert und passende Events in Sentry-Envelopes verpackt. Das Envelope-Format ist in Sentys Envelope-Spezifikation dokumentiert - es ist einfach ein HTTP-POST mit einer JSON-Header-Zeile, einem JSON-Item-Header und einem JSON-Item-Payload, durch Zeilenumbrüche getrennt. Es befindet sich kein Sentry-SDK im Request-Pfad. Das hält den Edge-Code (services/edge-redirect) schlank und vermeidet eine Hot-Path-Abhängigkeit.

Der Transformer erledigt drei nützliche Dinge:

Fingerprinting. Sentry gruppiert Events nach Fingerprint. Ein naiver Fingerprint würde jeden 5xx in einem riesigen Issue zusammenfassen, was nutzlos ist. Unser Transformer fingerprinted nach error_class:destination_host, sodass ein Redis-Timeout bei Links, die auf acme.com zeigen, ein separates Issue ist von einem Redis-Timeout bei Links auf globex.com. Das macht "ein defektes Ziel = ein Issue" tatsächlich wahr.

Slug-Aggregation. Jedes Sentry-Event trägt einen tags-Block, der die ersten 50 betroffenen Slugs, die Workspace-ID und die Redirect-Domain auflistet. Wenn 800 Slugs ein Ziel teilen und dieses Ziel DNS-NXDOMAIN zurückzuliefern beginnt, siehst du ein Issue mit slugs_affected: 800 und einem Sample von 50 - nicht 800 separate Alerts.

Rate-Limiting pro Workspace. Ein Workspace, der eine fehlerhafte Kampagne betreibt, kann in 60 Sekunden 10.000 5xx erzeugen. Sentry akzeptiert alle und berechnet sie dir. Der Transformer begrenzt auf 50 Envelopes pro Minute pro Workspace und fasst den Rest in einem einzelnen "suppressed"-Event mit einer Zählung zusammen. Wir haben das auf die harte Tour gelernt, als ein Kunde 4 Millionen Kurzlinks auf eine Domain gerichtet hatte, die anfing, 503 zurückzugeben.

Wenn du den Ingest lieber selbst handhaben möchtest statt über Elidos Transformer, beschreibt der Observability-Leitfaden den alternativen Weg: Abonniere unseren Webhook-Event-Bus und konvertiere Events in deiner eigenen Infra in Sentry-Envelopes. Die meisten Teams machen sich die Mühe nicht. Der Transformer ist schneller gebaut als du es selbst bauen könntest.

Ein Hinweis dazu, was als "Issue" erscheint: Sentys UI behandelt jedes gruppierte Event als Issue-Karte mit einer Sparkline, einem Beispiel-Event und einer Tag-Liste. Für Redirect-Fehler ist der nützlichste Tag cache_result (HIT, MISS, BYPASS). Wenn du eine Welle von 5xx mit cache_result: BYPASS siehst, hat jemand in deinem Team wahrscheinlich einen Cache-Bypass-für-Tests deployed und vergessen, ihn wieder zurückzusetzen. Eine wahre Geschichte, zweimal im letzten Jahr.

Datadog-Verdrahtung: Metric-Collector und Dashboards

Datadog ist Live. Die Verdrahtung funktioniert ebenfalls mit drei Klicks, aber die Architektur ist anders. Statt eines Event-Transformers betreiben wir einen Metric-Collector auf der api-core-Seite, der Redirect-Telemetrie in Datadogs Metrik-Format aggregiert und Batches alle 10 Sekunden über Datadogs Custom Metric API einsendet. Der Collector pre-aggregiert, sodass wir nie rohe Events einreichen. Das hält die Custom-Metric-Kardinalität niedrig und deine Datadog-Rechnung unter Kontrolle.

Die Metriken, die wir standardmäßig senden:

• elido.redirect.count - Counter, getaggt nach Domain, Tier, Region, cache_result, status_class (2xx/3xx/4xx/5xx)
• elido.redirect.latency.ms - Distribution, getaggt nach Domain, Tier, Region, cache_result
• elido.click.count - Counter, getaggt nach Domain, Tier (dedupliziert an der click-ingester-Grenze)
• elido.scanner.failure.count - Counter, getaggt nach Reason (malware, phishing, expired_cert, dns_nxdomain)

Tags sind der Hebel. Du kannst "p99-Latenz für link.acme.com in FRA in den letzten 4 Stunden" mit einer einzeiligen Query aufrufen. Du musst keine Dashboards für jede Domain vorab bauen. Sieh /integrations/datadog für die Metrik-Referenz und Tag-Taxonomie.

Die vier Panels oben sind das, was wir auf unserem eigenen NOC-TV zeigen. Sie decken die tägliche On-Call-Ansicht ab. p99-Edge-Latenz nach Region erkennt POP-Level-Regressionen (ein Hetzner-FRA-Ausreißer sieht anders aus als ein OVH-SGP-Ausreißer, und du willst beide nebeneinander sehen). Fehlerrate pro Domain Top-10 macht laute Kunden sichtbar - wenn acme.com bei 8% 5xx liegt und alle anderen bei 0,02%, hast du kein Elido-Problem, sondern ein acme-Problem. Click-Volumen nach Tier (f / s / b für Free, Starter, Business via Tier-Isolation) zeigt, ob ein Traffic-Spike von einem zahlenden Tenant kommt oder von einer Free-Tier-Kampagne, die rate-limited werden sollte. Broken-Redirect-Count last 24h ist die schließende Metrik: Ein Redirect, der 4xx zurückgegeben hat, sollte entweder innerhalb von 24 Stunden behoben oder abgelaufen und entfernt worden sein; sieh Link-Rotting-Prävention für den Auto-Repair-Pfad.

Empfohlene Alert-Schwellenwerte (das sind unsere Standardwerte; du kannst sie pro Workspace überschreiben):

• elido.redirect.latency.ms p99 > 50 ms für 5 min anhaltend - On-Call-Page
• elido.redirect.count{status_class:5xx} Rate > 0,5% für 2 min anhaltend - On-Call-Page
• elido.redirect.count{status_class:4xx} Rate > 5% für 10 min anhaltend - nur Slack
• elido.scanner.failure.count Rate > 10/min für einen Workspace - Security-Review, kein Page

Der 0,5%-5xx-Schwellenwert ist konservativ. Unsere Baseline liegt bei ~0,01% (meist DNS-Aussetzer bei Kundenzielen), also ist 0,5% eine 50-fache Abweichung - das ist real.

Wann welches Tool verwenden

Für ein kleines Team, das ein Developer-fokussiertes Produkt auf /solutions/developers betreibt, reicht Sentry wahrscheinlich aus. Du wirst bei echten 5xx gepaged, siehst Issues und behebst sie. Du wirst nicht die Dashboard-Kultur haben, die Datadog den Overhead von $1,50/Host/Monat wert macht.

Für ein größeres Unternehmen auf /solutions/enterprise mit einer SRE-On-Call-Rotation willst du beides. Sentry für den Issue-Stream, Datadog für die Dashboards, Slack-Alerts mit PagerDuty für den Page. Der Observability-Leitfaden erklärt das PagerDuty-Service-Mapping, wenn du diesen Weg gehst.

Für alle dazwischen: Sentry am Tag eins (der Free-Tier von Sentry ist für unter 5.000 Events/Monat in Ordnung), Datadog, wenn du mehr als eine Redirect-Domain oder mehr als eine Traffic-Region hast. Die Rechnung für den Datadog-Metric-Collector auf einem typischen Elido-Business-Workspace liegt bei rund $35/Monat - das ist der Preis dafür, dass ein Engineer nicht sonntags nginx-Logs durchsuchen muss.

Was du damit bekommst, was generische Uptime-Monitore nicht bieten

Ein Pingdom- oder UptimeRobot-Check auf f.elido.me sagt dir, ob der Edge erreichbar ist. Er sagt dir nicht, dass das Ziel des Slugs summer24 vor 12 Minuten angefangen hat, DNS-NXDOMAIN zurückzugeben, oder dass p99 in SGP 4x über p99 in FRA liegt, weil ein Redpanda-Partition-Leader neu gestartet hat. Redirect-Monitoring ist ein destination-aware-Problem. Der Redirect selbst kann gesund sein, während der Link tot ist.

Die Kombination aus Sentry und Datadog gibt dir destination-aware Sichtbarkeit, ohne eigene Probes schreiben zu müssen. Sentry sagt dir, was auf Ziel-Ebene kaputt ist. Datadog sagt dir, was auf Edge-Ebene degradiert. Slack informiert Menschen, Linear hält das Follow-up. Die Verdrahtung ist DSN-einfügen für Sentry und ein einzelner OAuth-Flow für Datadog. Starte heute mit Sentry; füge Datadog hinzu, wenn deine Redirect-Domain-Anzahl über eins steigt.

Preise und welcher Tier welche Integration enthält, findest du unter /pricing. Für die API-Schnittstelle rund um Event-Subscriptions, wenn du es selbst bauen willst, decken /features/analytics und der Sentry-über-12-Go-Services-Überblick die Event-Taxonomie ab.