Monitorowanie krótkich linków z Sentry i Datadog

Jeśli krótki link zwraca 5xx przez 30 sekund podczas kampanii na Instagramie, tracisz mniej więcej 4-7% kohorty. Większość zespołów inżynierskich dowiaduje się o tym następnego ranka, gdy ktoś wkleie zrzut ekranu ze Slacka. Ten przewodnik to playbook, którego używamy w Elido do wykrywania awarii przekierowań w mniej niż 60 sekund przy użyciu dwóch narzędzi, za które prawdopodobnie już płacisz: Sentry do issues i Datadog do metryk. To ta sama konfiguracja, której używamy dla własnych edge POP, obsługujących około 240 milionów przekierowań miesięcznie przy p99 wynoszącym 13 ms.

W skrócie: Sentry jest dobry w jednej rzeczy przy przekierowaniach - "jeden issue na uszkodzone miejsce docelowe, z listą slugów, które na nie trafiły." Datadog radzi sobie z ortogonalną sprawą - szeregami czasowymi. Potrzebujesz obu, a Elido nativnie emituje do obu. Sentry jest obecnie w Becie (wklej DSN i gotowe); Datadog jest Live z dedykowanym kolektorem metryk. Poniżej: które sygnały mają znaczenie, jak wewnętrznie działa integracja z Sentry i co powinien zawierać dashboard Datadog dotyczący kondycji przekierowań.

Które sygnały mają znaczenie przy monitorowaniu przekierowań

Zanim cokolwiek skonfigurujesz, zdecyduj, co naprawdę cię interesuje. Monitorowanie przekierowań to problem węższy niż pełny APM, a zestaw sygnałów jest mały. Cztery sygnały pokrywają około 95% rzeczywistych incydentów:

Zdarzenia przekierowań 4xx. 404 na krótkim linku to prawie zawsze jedna z trzech rzeczy: slug został usunięty, slug wygasł lub ktoś fuzuje twoją domenę. 410 jest celowe i hałaśliwe, więc pomijamy go w alertach. 451 (blokada geograficzna) jest interesujące tylko w agregacie. Wolumen 4xx na zdarzenie jest zbyt hałaśliwy do pagowania; traktuj go jako metrykę, nie jako issue.

Zdarzenia przekierowań 5xx. To wymaga zadzwonienia do osoby dyżurnej. 5xx oznacza, że edge nie mógł dotrzeć do Redis (cache L2), nie mógł dotrzeć do api-core (origin gRPC) lub docelowy URL miał błąd DNS podczas HEAD-check. Każdy z tych przypadków ma inny runbook. Transformer Sentry w api-core taguje przyczynę źródłową, więc tytuł issue brzmi coś w stylu 5xx: redis-timeout (12 slugów dotkniętych, ostatnio 14s temu) zamiast ogólnego Internal Server Error.

Latencja edge p99. Przekierowanie z cache HIT powinno być obsługiwane w mniej niż 15 ms przy p99 z dowolnego z naszych trzech POP. Alerty włączamy, jeśli p99 utrzymuje się powyżej 50 ms przez 5 minut. Powód: jedno wolne zapytanie nie podniesie p99 przez 5 minut, ale replika Redis wypadająca z synchronizacji już tak. Zobacz redirect p95 poniżej 15 ms dla szczegółów budżetu latencji.

Anomalia wskaźnika kliknięć i błąd skanowania. Anomalie wskaźnika kliknięć to system późnego ostrzegania. Jeśli kampania robi normalnie 4000 kliknięć/godzinę i nagle 200, coś się popsuło po stronie zewnętrznej (reklama została odrzucona, naklejka QR się odklejła, ktoś usunął zły link). Błędy skanowania pochodzą z serwisu url-scanner, który sprawdza miejsca docelowe pod kątem malware. Wzrost błędów skanowania zwykle oznacza, że konto zostało przejęte i tworzy linki phishingowe.

Kierowanie sygnałów do właściwego narzędzia

Nie każdy sygnał należy do każdego narzędzia. Wysyłanie wolumenu 4xx do Sentry jako issues przykryje właściwy issue "uszkodzone miejsce docelowe" pod hałasem. Wysyłanie latencji p99 do Sentry jako alertów jest nieporęczne, bo system alertów Sentry jest zbudowany wokół częstotliwości issues, a nie szeregów czasowych. Model myślowy: Sentry = wyjątki, Datadog = metryki, Slack = ludzie, Linear = tickety do wykonania.

Elido emituje tam, gdzie jest X. Nie wysyłamy zdarzeń 4xx do Sentry, bo nie są wyjątkami. Nie wysyłamy też każdego zdarzenia kliknięcia do Datadog, bo wolumen nie uzasadnia kosztu (niestandardowe metryki Datadog są rozliczane za unikalną kombinację tagów, a kardynalność slug x region x tier kosztowałaby $4000/miesiąc dla workspace średniej wielkości). Podział powyżej to wynik 9 miesięcy wewnętrznego działania systemu.

Integracja Sentry: wklejenie DSN i envelope transformer

Integracja Sentry w Elido jest w Becie, ale funkcjonalnie kompletna. Konfiguracja to trzy kliknięcia. Przechodzisz do /integrations, znajdujesz Sentry, wklejasz DSN i wybierasz, które typy zdarzeń przekazywać. DSN to jedyny sekret. Przechowujemy go w Postgresie z szyfrowaniem envelope (KMS-wrapped według ADR-0036), żeby nawet nasi administratorzy DB nie mogli go odczytać w postaci surowej.

Pod maską api-core ma webhook transformer, który nasłuchuje wewnętrznego szyny zdarzeń (temat Redpanda redirect.errors) i pakuje pasujące zdarzenia w koperty Sentry. Format envelope jest udokumentowany w specyfikacji envelope Sentry - to po prostu HTTP POST z linią nagłówka JSON, nagłówkiem elementu JSON i payloadem elementu JSON, oddzielonymi nową linią. Nie ma SDK Sentry w ścieżce żądań. To utrzymuje kod edge (services/edge-redirect) mały i unika zależności w hot path.

Transformer robi trzy przydatne rzeczy:

Fingerprinting. Sentry grupuje zdarzenia według fingerprintu. Naiwny fingerprint zgrupowałby wszystkie 5xx w jeden ogromny issue, co jest bezużyteczne. Nasz transformer tworzy fingerprint na podstawie error_class:destination_host, więc timeout Redis dla linków wskazujących na acme.com to osobny issue od timeoutu Redis dla linków na globex.com. To sprawia, że zasada "jedno uszkodzone miejsce docelowe = jeden issue" jest naprawdę prawdziwa.

Agregacja slugów. Każde zdarzenie Sentry zawiera blok tags z listą pierwszych 50 dotkniętych slugów, ID workspace'u i domeną przekierowania. Gdy 800 slugów dzieli jedno miejsce docelowe i to miejsce zaczyna zwracać DNS NXDOMAIN, widzisz jeden issue z slugs_affected: 800 i próbką 50, a nie 800 osobnych alertów.

Rate limiting na workspace. Workspace prowadzący nieudaną kampanię może wygenerować 10 000 błędów 5xx w 60 sekund. Sentry przyjmie wszystkie i wystawi za nie rachunek. Transformer ogranicza do 50 kopert na minutę na workspace i grupuje resztę w jedno zdarzenie "suppressed" z liczbą. Nauczyliśmy się tego na własnej skórze, gdy klient skierował 4 miliony krótkich linków na domenę, która zaczęła zwracać 503.

Jeśli wolisz samodzielnie obsługiwać ingest zamiast przez transformer Elido, dokumentacja obserwowalności opisuje alternatywną ścieżkę: subskrybuj nasz webhook event bus i konwertuj zdarzenia na koperty Sentry we własnej infrastrukturze. Większość zespołów nie zawraca sobie tym głowy. Transformer jest szybszy do wdrożenia niż do zbudowania.

Uwaga o tym, co pojawia się jako "issue": UI Sentry traktuje każde zgrupowane zdarzenie jako kartę issue ze sparkline, przykładowym zdarzeniem i listą tagów. Dla błędów przekierowań najbardziej przydatny tag to cache_result (HIT, MISS, BYPASS). Jeśli widzisz falę 5xx z cache_result: BYPASS, ktoś w twoim zespole prawdopodobnie wdrożył zmianę wymuszającą bypass cache do testów i zapomniał to cofnąć. Prawdziwa historia, dwa razy w ostatnim roku.

Integracja Datadog: kolektor metryk i dashboardy

Datadog jest Live. Konfiguracja też zajmuje trzy kliknięcia, ale architektura jest inna. Zamiast transformera na zdarzenie, uruchamiamy kolektor metryk po stronie api-core, który agreguje telemetrię przekierowań do formatu metryk Datadog i przesyła partie co 10 sekund przez API niestandardowych metryk Datadog. Kolektor wstępnie agreguje, więc nigdy nie przesyłamy surowych zdarzeń. To utrzymuje niską kardynalność niestandardowych metryk i rachunek Datadog pod kontrolą.

Metryki, które emitujemy domyślnie:

• elido.redirect.count - licznik, tagowany przez domain, tier, region, cache_result, status_class (2xx/3xx/4xx/5xx)
• elido.redirect.latency.ms - rozkład, tagowany przez domain, tier, region, cache_result
• elido.click.count - licznik, tagowany przez domain, tier (deduplikowany na granicy click-ingester)
• elido.scanner.failure.count - licznik, tagowany przez reason (malware, phishing, expired_cert, dns_nxdomain)

Tagi to dźwignia. Możesz wyciągnąć "p99 latencji dla link.acme.com w FRA przez ostatnie 4 godziny" jednolinijkowym zapytaniem. Nie musisz z góry budować dashboardów dla każdej domeny. Zobacz /integrations/datadog dla referencji metryk i taksonomii tagów.

Cztery panele powyżej to to, co wyświetlamy na własnym ekranie NOC. Pokrywają codzienny widok dyżurny. p99 latencji edge według regionu wykrywa regresje na poziomie POP (problem Hetzner FRA wygląda inaczej niż problem OVH SGP i chcesz je widzieć obok siebie). Wskaźnik błędów na domenę top-10 wyciąga hałaśliwych klientów - jeśli acme.com ma 8% 5xx a wszyscy inni 0,02%, to nie masz problemu z Elido, masz problem z acme. Wolumen kliknięć według tieru (f / s / b dla free, starter, business przez izolację tierów) mówi, czy skok ruchu pochodzi od płacącego tenanta, czy od kampanii darmowego tieru, która powinna być ograniczona. Liczba uszkodzonych przekierowań w ciągu ostatnich 24h to metryka zamykająca - przekierowanie, które zwróciło 4xx, powinno być naprawione albo wygasłe i usunięte w ciągu 24 godzin; ścieżkę auto-naprawy znajdziesz w zapobieganiu psuciu się linków.

Zalecane progi alertów (to nasze wartości domyślne; możesz je nadpisać per workspace):

• elido.redirect.latency.ms p99 > 50 ms przez 5 min - dzwonisz do dyżurnego
• elido.redirect.count{status_class:5xx} wskaźnik > 0,5% przez 2 min - dzwonisz do dyżurnego
• elido.redirect.count{status_class:4xx} wskaźnik > 5% przez 10 min - tylko Slack
• elido.scanner.failure.count wskaźnik > 10/min dla workspace'u - przegląd bezpieczeństwa, bez page

Próg 0,5% 5xx jest konserwatywny. Nasza linia bazowa to ~0,01% (głównie problemy DNS na miejscach docelowych klientów), więc 0,5% to odchylenie 50-krotne, co jest realne.

Kiedy używać czego

Dla małego zespołu prowadzącego produkt ukierunkowany na deweloperów w /solutions/developers Sentry sam w sobie prawdopodobnie wystarczy. Będziesz pagowany przy prawdziwych 5xx, zobaczysz issues i je naprawisz. Nie będziesz mieć kultury dashboardów, żeby Datadog opłacał się przy koszcie $1,50/host/miesiąc.

Dla większej firmy w /solutions/enterprise z rotacją dyżurów SRE chcesz obu. Sentry do strumienia issues, Datadog do dashboardów, alerty Slack podpięte do PagerDuty do pagowania. Przewodnik po obserwowalności przeprowadza przez mapowanie serwisów PagerDuty, jeśli pójdziesz tą drogą.

Dla wszystkich pomiędzy, nasza rekomendacja: Sentry od pierwszego dnia (darmowy tier Sentry wystarczy do 5000 zdarzeń/miesiąc), Datadog gdy zaczniesz mieć więcej niż jedną domenę przekierowania lub więcej niż jeden region ruchu. Rachunek za kolektor metryk Datadog na typowym workspace Elido Business to około $35/miesiąc, czyli cena oszczędzenia jednemu inżynierowi grepa po logach nginx w niedzielę.

Co to daje, czego generyczne monitory uptime nie oferują

Check Pingdom lub UptimeRobot na f.elido.me powie ci, czy edge działa. Nie powie ci, że miejsce docelowe sluga summer24 zaczęło zwracać DNS NXDOMAIN 12 minut temu, ani że p99 w SGP jest 4x większe niż p99 w FRA, bo lider partycji Redpanda się przeładował. Monitorowanie przekierowań to problem świadomy miejsca docelowego. Sam redirect może być zdrowy, podczas gdy link jest martwy.

Kombinacja Sentry + Datadog powyżej daje ci widoczność świadomą miejsca docelowego bez pisania własnych sond. Sentry mówi ci, co się psuje na poziomie miejsca docelowego. Datadog mówi ci, co się degraduje na poziomie edge. Slack informuje ludzi, Linear przechowuje follow-up. Konfiguracja to wklejenie DSN dla Sentry i pojedynczy przepływ OAuth dla Datadog. Zacznij od Sentry dziś; dodaj Datadog, gdy liczba twoich domen przekierowań przekroczy jeden.

Cennik i to, która integracja jest dostępna w którym tierze, znajdziesz na /pricing. Dla powierzchni API wokół subskrypcji zdarzeń jeśli chcesz zbudować własne rozwiązanie, /features/analytics i szczegóły Sentry na 12 serwisach Go obejmują taksonomię zdarzeń.