Моніторинг коротких посилань із Sentry і Datadog: хто за що відповідає

Моніторинг коротких посилань чітко розділяється між двома інструментами. Sentry - куди Elido надсилає події стану посилань: ціль, що перестала відповідати, посилання з вичерпаним терміном дії, досягнутий ліміт кліків, власний домен, що не пройшов верифікацію. Datadog - куди Elido надсилає кліки, один лог на відвідування і три метрики кількості кліків за хвилину. Затримка редиректу не йде в жоден з них, бо Elido її не експортує; ви вимірюєте її ззовні за допомогою синтетичного пробника.

Цей матеріал - Sentry-половина цієї картини плюс пряма відповідь на питання «який інструмент для чого». Якщо ви тут за дашбордами Datadog, гайд з метрик редиректу Datadog детально розглядає метрики кліків, структуру логів і дашборд затримки на основі Synthetics, тож я не буду це повторювати.

Один момент контексту перед налаштуванням. Редирект може бути цілком здоровим, а посилання - мертвим: коротка URL-адреса відповідає за кілька мілісекунд і надсилає людей на 404. Саме тому моніторинг URL для коротких посилань потребує і сигналу, чутливого до стану цілі, і сигналу швидкості, і чому жоден окремий інструмент не дає обидва з одного потоку. Розбір p95 нижче 15 мс пояснює, як виглядає «здоровий» стан з боку швидкості.

Що має відловлювати моніторинг коротких посилань

Я розподіляю збої на три категорії, бо кожна потребує свого інструменту.

Посилання зламалося. Його ціль повертає 4xx чи 5xx, обривається за таймаутом, або домен перестав резолвитися. Ваш редирект досі працює, але тепер направляє людей на сторінку помилки. Elido знаходить це за допомогою щоденної перевірки цілі і піднімає link.broken.

Посилання зупинилося за задумом. Воно досягло дати завершення чи ліміту кліків, тож Elido припинив його редиректити. Технічно все гаразд, але якщо кампанія досі веде на нього, комусь варто про це знати. Це link.expired і link.cap_reached. Власний домен, що так і не пройшов верифікацію, піднімає domain.ssl_failed, і це той самий тип проблеми.

Сам редирект сповільнився чи впав. Це сигнал швидкості, і саме його Elido не видає як метрику. Ви стежите за ним ззовні.

Трафік - четвертий сигнал, але м'якший. Кампанія, що зазвичай робить тисячі кліків на годину і раптом робить лише кілька десятків, зазвичай означає, що щось змінилося вище за потоком, наприклад зупинену рекламу чи відклеєну QR-наліпку. Кількість кліків живе в Datadog, тож туди й веде монітор падінь.

Що Elido надсилає в Sentry

Sentry - один з типів вихідних каналів у системі сповіщень Elido, поряд з Discord, Telegram і звичайними підписаними webhook. Він їде тим самим конвеєром доставки, що й webhook, з однією відмінністю: замість сирої події Elido він публікує невелику подію Sentry.

Кожна доставка - одна JSON-подія, надіслана на кінцеву точку store вашого проєкту, яку Elido виводить з DSN. Для https://[email protected]/8 цільова адреса - https://o4711.ingest.sentry.io/api/8/store/, а публічний ключ потрапляє в заголовок X-Sentry-Auth. Жодного SDK Sentry в цьому шляху немає, і оскільки хост DSN розбирається, а не захардкоджений, самостійно розгорнутий сервер, сумісний із Sentry, працює так само. Payload відповідає формату payload подій 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" }
}

Рівень обирається за назвою події. Усе, що означає «це посилання зараз не працює», надходить як error: .broken, .expired, cap_reached, ssl_failed. Видалення і пониження надходять як warning, все інше - як info.

Тепер чесно про теги. Кожна подія несе теги event_type і workspace_id, а поля environment і release заповнюються, коли ви встановлюєте їх на каналі. Подія досягнення ліміту також несе тег clicks. А от подія непрацюючого посилання поки не несе slug чи ціль як теги, тож issue в Sentry повідомляє лише, що посилання в робочому просторі 42 зламалося, і ви відкриваєте список посилань в Elido, де непрацююче позначене прапорцем. Краще сказати вам про це зараз, ніж лишити вас шукати тег slug о другій ночі.

Налаштування каналу Sentry для сповіщень про непрацюючі посилання

Налаштування займає кілька хвилин, і DSN - єдині облікові дані, що знадобляться. Канал Sentry позначено як Beta, бо проєкт Sentry ви створюєте самі; встановлення в один клік через платформу інтеграцій Sentry - в дорожній карті, але ще не реалізоване, тож наразі це вставляння DSN вручну.

1. У Sentry створіть проєкт, оберіть платформу Other і скопіюйте DSN з наступного екрана. Пояснення DSN показує, яка частина - ключ, а яка - ID проєкту.
2. У дашборді Elido відкрийте Notifications, додайте канал, оберіть Sentry, вставте DSN і, за бажанням, назву середовища на кшталт production.
3. Залиште події за замовчуванням або оберіть власні. За замовчуванням це link.broken, link.expired, link.cap_reached і domain.ssl_failed.

Elido перевіряє DSN під час збереження: він має бути http чи https, містити публічний ключ і закінчуватися ID проєкту. Некоректний DSN відхиляється одразу, а не провалюється мовчки пізніше.

Якщо ви керуєте конфігурацією як кодом, той самий канал - це один виклик API. Канали - це кінцеві точки webhook із 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 не підписуються HMAC, оскільки Sentry автентифікує запит за своїм ключем. Проте на них діє звичайна політика повторних спроб: три спроби загалом, з повторами через п'ять і п'ятнадцять хвилин після збою, після чого доставка позначається як невдала. Їх можна переглянути на /v1/workspaces/{workspace_id}/webhooks/{id}/deliveries і повторити вручну.

Кнопки тестування для цього каналу немає. Найчистіший спосіб перевірити, який я знаю: створіть одноразове посилання з терміном дії через хвилину-дві і зачекайте. Elido сканує на предмет щойно завершених посилань кожні п'ять хвилин, тож issue рівня error має з'явитися в Sentry невдовзі після цього.

Щойно події стану посилань потрапляють у Sentry, наступне питання - що з ними робити, а це залежить від того, як Sentry їх групує. Якщо ви ще обираєте план, порівняйте, що включає кожен рівень, перш ніж підключати канал.

Як Sentry групує події стану посилань Elido

Ці події не мають ні стека викликів, ні винятку, тож резервне групування Sentry групує їх за повідомленням. На практиці це означає один issue на тип події: усі події непрацюючих посилань стають одним issue, лічильник якого росте, усі завершення терміну дії - іншим.

Це корисно для сповіщень і менш корисно для тріажу. Допомагають два налаштування:

• Встановіть середовище на каналі. З окремими каналами для кожного робочого простору чи середовища (production, campaigns) кожен отримує власний фільтр у потоці issue, і ви можете обмежити правила сповіщень одним з них.
• Додайте правило fingerprint у налаштуваннях проєкту Sentry на tags.workspace_id, якщо ви спрямовуєте кілька робочих просторів в один проєкт і хочете окремий issue на кожен.

Для сповіщень будуйте на власних правилах сповіщень про issue Sentry: «створено новий issue» ловить перше непрацююче посилання, а «issue трапляється понад N разів за годину» ловить пакет, скажімо, цілу кампанію, чий посадковий домен впав. Майте на увазі темп виявлення, що стоїть за цим. Перевірка цілі виконується раз на день, перший збій запускається одразу, а посилання, що лишається непрацюючим, запускає подію знову через 24 години. Sentry - правильна скринька вхідних для цього. Це не детектор простою за п'ять хвилин, і я не буду вдавати інше.

Де в моніторингу редиректів місце Datadog

Datadog отримує кліки, а не стан посилань. Кожен клік стає одним логом, надісланим у Logs intake вашого сайту Datadog, з джерелом elido, тегами workspace_id, vendor:elido і link_id, а поля кліка - під attributes. Раз на хвилину Elido також надсилає три gauge-метрики на робочий простір: elido.clicks, elido.clicks_by_country і elido.clicks_by_device.

Те, чого там немає, важить не менше. Жодної метрики затримки, жодних кодів статусу, жодних тегів домену, рівня чи регіону. Невдалий POST лога отримує одну повторну спробу і потім відкидається. Налаштування кешуються до п'яти хвилин, тож щойно збереженому ключу потрібна мить, щоб запрацювати, а кнопка Test connection в дашборді надсилає один тестовий лог і показує відповідь Datadog, що вловлює неправильний ключ чи сайт, але не конвеєр, який губить логи, тож реальний клік лишається доказом того, що це працює.

Тож завдання Datadog тут - трафік: обсяг кліків за хвилину, топ країн і монітор для «кліки впали майже до нуля». Гайд з моніторингу URL Datadog містить запити, кроки налаштування, а сторінка інтеграції перелічує поля. Звіряйте підсумки з аналітикою кліків Elido, яка лишається джерелом істини.

Стеження за затримкою редиректу ззовні

Для сигналу швидкості спрямуйте синтетичну перевірку на канаркове коротке посилання: посилання, яке ви створюєте лише для моніторингу, щоб пробники ніколи не змішувалися з цифрами кампаній. HTTP-тести Datadog добре справляються з цим, і будь-який сервіс аптайму, що вміє пропускати редиректи, теж підійде.

Три налаштування вирішують, чи означає число хоч щось:

• Вимкніть слідування за редиректом. Вам потрібен час до повернення 301 чи 302, а не час, який потрібен вашій посадковій сторінці для рендеру.
• Перевіряйте код статусу і заголовок Location, щоб редирект у неправильне місце провалював перевірку.
• Надсилайте User-Agent, що містить bot. Elido пропускає події кліків для відомих агентів-ботів, тож ваш пробник не роздуватиме лічильники кліків.

Запускайте пробник з локацій поблизу вашої аудиторії. Редирект із cache hit у регіоні має впевнено вкладатися в бюджет p95 15 мс, а стійкий стрибок вартий уваги. Перевірка вашого власного домену також покаже, чи досі працює його TLS-сертифікат, а це ніколи не покаже простий пересилач кліків.

Який інструмент для чого

Ось розподіл, який я налаштував би для команди, що веде платні кампанії на коротких посиланнях:

Невелика команда може почати лише з каналу Sentry; він покриває збої, що тихо витрачають рекламний бюджет. Додайте Datadog, коли хтось справді почне дивитися на дашборди трафіку, і додайте пробник того дня, коли повільний редирект коштуватиме вам грошей. Якщо Sentry - не скринька вхідних вашої команди, ті самі події стану посилань надходять у Discord чи Telegram, а непрацююче посилання також може відкрити тікет у Linear.

Прочитайте наріжний матеріал → Досягнення p95 нижче 15 мс для редиректів

Пов'язане в блозі

• Моніторинг URL Datadog для коротких посилань - метрики кліків, логи і дашборд затримки на Synthetics.
• Стратегія запобігання link rot - що робити після того, як прийшов issue про непрацююче посилання.
• Сповіщення в Discord і Telegram для коротких посилань - ті самі події стану посилань у чат-каналі.
• Тікети Linear з попереджень про посилання - перетворення непрацюючого посилання на відстежуване завдання.