Monitorowanie krótkich linków z Sentry i Datadog: co robi co

Monitorowanie krótkich linków dzieli się wyraźnie między dwa narzędzia. Sentry to miejsce, do którego Elido wysyła zdarzenia stanu linku: miejsce docelowe, które przestało odpowiadać, link, który wygasł, limit kliknięć, który został osiągnięty, własna domena, która nie przeszła weryfikacji. Datadog to miejsce, do którego Elido wysyła kliknięcia, jeden log na wizytę i trzy metryki liczby kliknięć na minutę. Opóźnienie przekierowania nie trafia do żadnego z nich, bo Elido go nie eksportuje; mierzysz je z zewnątrz syntetyczną sondą.

Ten wpis to połowa poświęcona przede wszystkim Sentry, plus prosta odpowiedź na "które narzędzie do czego". Jeśli szukasz dashboardów Datadog, przewodnik po metrykach przekierowań Datadog omawia metryki kliknięć, kształt logów i tablicę opóźnień opartą na Synthetics w pełnych szczegółach, więc tego nie będę powtarzać.

Jeszcze jeden kontekst przed podłączaniem. Przekierowanie może być całkowicie zdrowe, podczas gdy link jest martwy: krótki URL odpowiada w kilka milisekund i wysyła ludzi na stronę 404. Dlatego monitorowanie URL dla krótkich linków potrzebuje sygnału świadomego miejsca docelowego i sygnału prędkości, i dlatego żadne pojedyncze narzędzie nie daje Ci obu z jednego źródła. Rozbiór p95 poniżej 15ms wyjaśnia, jak wygląda "zdrowy" od strony prędkości.

Co musi wychwycić monitorowanie krótkich linków

Sortuję awarie na trzy kosze, bo każdy potrzebuje innego narzędzia.

Link się zepsuł. Jego miejsce docelowe zwraca 4xx albo 5xx, przekracza limit czasu albo domena przestała się rozwiązywać. Twoje przekierowanie wciąż działa, ale teraz kieruje ludzi na stronę błędu. Elido znajduje takie przypadki codziennym sprawdzeniem miejsca docelowego i podnosi link.broken.

Link zatrzymał się z założenia. Osiągnął datę wygaśnięcia albo limit kliknięć, więc Elido przestało go przekierowywać. Technicznie nic nie jest zepsute, ale jeśli kampania nadal na niego wskazuje, ktoś musi się dowiedzieć. To link.expired i link.cap_reached. Własna domena, która nigdy się nie zweryfikowała, podnosi domain.ssl_failed, co należy do tej samej sterty.

Samo przekierowanie zwolniło albo padło. To sygnał prędkości i ten, którego Elido nie emituje jako metryki. Obserwujesz go z zewnątrz.

Ruch to czwarty sygnał, ale łagodniejszy. Kampania, która zwykle robi tysiące kliknięć na godzinę i nagle robi kilkadziesiąt, zwykle oznacza, że coś zmieniło się wyżej w łańcuchu, jak wstrzymana reklama albo odklejona naklejka QR. Liczby kliknięć mieszkają w Datadog, więc tam trafia monitor spadku.

Co Elido wysyła do Sentry

Sentry to jeden z typów kanałów wychodzących w systemie powiadomień Elido, obok Discorda, Telegrama i zwykłych podpisanych webhooków. Jedzie tym samym rurociągiem dostaw co webhooki, z jedną różnicą: zamiast surowego zdarzenia Elido publikuje małe zdarzenie Sentry.

Każda dostawa to jedno zdarzenie JSON wysłane do endpointu store Twojego projektu, który Elido wyprowadza z DSN. Mając https://[email protected]/8, celem jest https://o4711.ingest.sentry.io/api/8/store/, a klucz publiczny trafia do nagłówka X-Sentry-Auth. Nigdzie na tej ścieżce nie ma SDK Sentry, a ponieważ host DSN jest parsowany, a nie zaszyty na sztywno, samodzielnie hostowany serwer kompatybilny z Sentry działa tak samo. Ładunek stosuje się do formatu ładunku zdarzenia Sentry:

{
  "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" }
}

Poziom jest dobierany na podstawie nazwy zdarzenia. Wszystko, co znaczy "ten link teraz nie działa", dociera jako error: .broken, .expired, cap_reached, ssl_failed. Usunięcia i degradacje docierają jako warning, wszystko inne jako info.

Teraz szczera część o tagach. Każde zdarzenie niesie tagi event_type i workspace_id, a pola environment i release są wypełniane, gdy ustawisz je na kanale. Zdarzenie osiągnięcia limitu niesie też tag clicks. Zdarzenie uszkodzonego linku jednak nie niesie dziś slugu ani miejsca docelowego jako tagów, więc issue Sentry mówi Ci, że w workspace'ie 42 zepsuł się jakiś link, a Ty otwierasz listę linków w Elido, gdzie uszkodzony niesie flagę. Wolę powiedzieć Ci to teraz, niż żebyś szukał taga slug o drugiej w nocy.

Konfigurowanie kanału Sentry dla alertów o uszkodzonych linkach

Konfiguracja zajmuje kilka minut, a DSN to jedyne poświadczenie. Kanał Sentry jest oznaczony jako Beta, bo sam tworzysz projekt Sentry; instalacja jednym kliknięciem przez platformę integracji Sentry jest na mapie drogowej, ale niezbudowana, więc dziś to wklejenie DSN.

1. W Sentry utwórz projekt, wybierz platformę Other i skopiuj DSN z następnego ekranu. Wyjaśnienie DSN pokazuje, która część to klucz, a która to identyfikator projektu.
2. W dashboardzie Elido otwórz Notifications, dodaj kanał, wybierz Sentry, wklej DSN i opcjonalnie nazwę środowiska, na przykład production.
3. Zostaw domyślne zdarzenia albo wybierz własne. Domyślne to link.broken, link.expired, link.cap_reached i domain.ssl_failed.

Elido sprawdza DSN przy zapisie: musi być http albo https, zawierać klucz publiczny i kończyć się identyfikatorem projektu. Źle sformułowany jest odrzucany od razu, zamiast zawieść po cichu później.

Jeśli zarządzasz konfiguracją jako kodem, ten sam kanał to jedno wywołanie API. Kanały to endpointy webhooków z 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" }
  }'

Dostawy do Sentry nie są podpisane HMAC, bo Sentry uwierzytelnia żądanie własnym kluczem zamiast tego. Podlegają za to normalnej polityce ponowień: trzy próby w sumie, z ponowieniami pięć i piętnaście minut po awarii, a potem dostawa jest oznaczana jako nieudana. Możesz je wylistować pod /v1/workspaces/{workspace_id}/webhooks/{id}/deliveries i ponowić jedną ręcznie.

Nie ma przycisku testowego dla tego kanału. Najczystszy test, jaki znam: utwórz jednorazowy link z wygaśnięciem za minutę czy dwie i poczekaj. Elido skanuje w poszukiwaniu nowo wygasłych linków co pięć minut, więc issue na poziomie error powinien wylądować w Sentry wkrótce potem.

Gdy zdarzenia stanu linku już lądują w Sentry, kolejne pytanie brzmi, co z nimi zrobisz, a to zależy od tego, jak Sentry je grupuje. Jeśli wciąż wybierasz plan, porównaj, co zawiera każdy poziom, zanim podłączysz kanał.

Jak Sentry grupuje zdarzenia stanu linku Elido

Te zdarzenia nie mają stack trace ani wyjątku, więc grupowanie zapasowe Sentry grupuje je po komunikacie. W praktyce oznacza to jeden issue na typ zdarzenia: wszystkie zdarzenia uszkodzonego linku stają się jednym issue, którego licznik zdarzeń rośnie, wszystkie wygaśnięcia to kolejny.

To przydatne do paging, a mniej przydatne do triażu. Pomagają dwie poprawki:

• Ustaw środowisko na kanale. Z osobnymi kanałami per workspace albo per środowisko (production, campaigns), każdy dostaje własny filtr w strumieniu issue i możesz zawęzić do niego reguły alertów.
• Dodaj regułę fingerprint w ustawieniach projektu Sentry na tags.workspace_id, jeśli kierujesz kilka workspace'ów do jednego projektu i chcesz jeden issue na workspace.

Do alertowania buduj na własnych regułach alertów issue Sentry: "utworzono nowy issue" wychwytuje pierwszy uszkodzony link, a "issue widziano więcej niż N razy w ciągu godziny" wychwytuje falę, powiedzmy całą kampanię, której domena docelowa padła. Miej na uwadze tempo wykrywania stojące za tym. Sprawdzenie miejsca docelowego działa raz dziennie, pierwsza awaria wyzwala od razu, a link, który pozostaje zepsuty, wyzwala ponownie po 24 godzinach. Sentry to właściwa skrzynka na to. To nie jest detektor przestoju w pięć minut, i nie udawałbym, że jest.

Gdzie Datadog pasuje do monitorowania przekierowań

Datadog dostaje kliknięcia, nie stan linku. Każde kliknięcie staje się jednym logiem wysłanym do wchłaniania logów Twojej witryny Datadog, ze źródłem elido, tagami workspace_id, vendor:elido i link_id, a pola kliknięcia pod attributes. Raz na minutę Elido wysyła też trzy gauge per workspace: elido.clicks, elido.clicks_by_country i elido.clicks_by_device.

To, czego tam nie ma, liczy się tak samo. Żadnej metryki opóźnienia, żadnych kodów statusu, żadnej domeny, poziomu ani tagów regionu. Nieudany POST loga dostaje jedno ponowienie, a potem jest porzucany. Ustawienia są cachowane do pięciu minut, więc świeżo zapisany klucz potrzebuje chwili, żeby zacząć działać, a przycisk Test connection w dashboardzie wysyła jeden testowy log i pokazuje odpowiedź Datadog, co wychwytuje błędny klucz lub błędną witrynę, ale nie potok, który gubi logi, więc prawdziwe kliknięcie wciąż jest dowodem, że działa.

Więc rola Datadog tutaj to ruch: wolumen kliknięć na minutę, czołowe kraje i monitor na "kliknięcia spadły niemal do zera". Przewodnik po monitorowaniu URL w Datadog zawiera zapytania, kroki konfiguracji, a strona integracji wymienia pola. Uzgadniaj sumy z analityką kliknięć Elido, która pozostaje zapisem prawdy.

Obserwowanie opóźnienia przekierowania z zewnątrz

Dla sygnału prędkości skieruj sprawdzenie syntetyczne na krótki link-kanarek: link tworzony wyłącznie do monitorowania, żeby sondy nigdy nie mieszały się z liczbami kampanii. Testy HTTP Datadog robią to dobrze, a każda usługa uptime, która potrafi pominąć przekierowania, też się nadaje.

Trzy ustawienia decydują, czy liczba coś znaczy:

• Wyłącz podążanie za przekierowaniem. Chcesz czasu do momentu powrotu 301 albo 302, nie czasu, jaki zajmuje wyrenderowanie Twojej strony docelowej.
• Sprawdzaj kod statusu i nagłówek Location, żeby przekierowanie w złe miejsce nie przeszło sprawdzenia.
• Wyślij User-Agent zawierający bot. Elido pomija zdarzenia kliknięć dla znanych agentów-botów, więc Twoja sonda nie napompuje liczby kliknięć.

Uruchamiaj sondę z lokalizacji blisko Twojej publiczności. Przekierowanie z trafieniem w cache w regionie powinno mieścić się wyraźnie poniżej budżetu p95 15ms, a trwały skok jest wart uwagi. Sprawdzenie względem Twojej własnej domeny mówi Ci też, czy jej certyfikat TLS wciąż działa, czego przekaźnik kliknięć nigdy by nie powiedział.

Które narzędzie do czego

Oto podział, który ustawiłbym dla zespołu prowadzącego płatne kampanie na krótkich linkach:

Mały zespół może zacząć od samego kanału Sentry; pokrywa awarie, które po cichu marnują budżet reklamowy. Dodaj Datadog, gdy ktoś faktycznie zacznie patrzeć na dashboardy ruchu, i dodaj sondę w dniu, w którym wolne przekierowanie zacznie Cię kosztować pieniądze. Jeśli Sentry nie jest skrzynką odbiorczą Twojego zespołu, te same zdarzenia stanu linku idą do Discorda albo Telegrama, a uszkodzony link może też otworzyć zgłoszenie w Linear.

Przeczytaj artykuł filarowy → Osiąganie p95 poniżej 15ms dla przekierowań

Powiązane na blogu

• Monitorowanie URL w Datadog dla krótkich linków - metryki kliknięć, logi i tablica opóźnień Synthetics.
• Strategia zapobiegania rozpadowi linków - co zrobić po tym, jak wyląduje issue uszkodzonego linku.
• Alerty Discord i Telegram dla krótkich linków - te same zdarzenia stanu linku na kanale czatu.
• Zgłoszenia Linear z alertów linków - zamiana uszkodzonego linku w śledzone zadanie.