Мониторинг коротких ссылок с 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 и обычными подписанными вебхуками. Он использует тот же конвейер доставки, что и вебхуки, с одним отличием: вместо «сырого» события Elido он отправляет небольшое событие в формате Sentry.

Каждая доставка - это одно JSON-событие, отправленное на store-endpoint вашего проекта, который Elido вычисляет из DSN. Для https://[email protected]/8 целевым адресом будет https://o4711.ingest.sentry.io/api/8/store/, а публичный ключ уходит в заголовок X-Sentry-Auth. Никакого SDK Sentry на этом пути нет, и поскольку хост DSN разбирается динамически, а не зашит жестко, self-hosted сервер, совместимый с Sentry, работает точно так же. 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 или destination в виде тегов, поэтому issue в Sentry сообщает лишь, что в рабочем пространстве 42 сломалась какая-то ссылка, а дальше вы открываете список ссылок в Elido, где сломанная помечена флагом. Лучше сказать вам об этом сейчас, чем чтобы вы искали тег slug в два часа ночи.

Настройка канала Sentry для оповещений о сломанных ссылках

Настройка занимает пару минут, и DSN - единственные учетные данные, которые нужны. Канал Sentry помечен как Beta, потому что проект в Sentry вы создаете сами; установка в один клик через платформу интеграций Sentry стоит в roadmap, но еще не реализована, так что сегодня это вставка 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. Каналы - это эндпоинты вебхуков с полем 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, счетчик событий которой растет, все истечения - другой.

Это удобно для оповещений и менее удобно для сортировки (triage). Помогают две настройки:

• Задайте окружение на канале. С отдельными каналами на каждое рабочее пространство или окружение (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 пропускает события клика для известных ботов, поэтому ваш зонд не будет раздувать счетчики кликов.

Запускайте зонд из локаций, близких к вашей аудитории. Редирект с попаданием в кеш в регионе должен укладываться намного ниже бюджета p95 в 15 мс, а устойчивый скачок стоит того, чтобы поднять тревогу (page). Проверка на вашем кастомном домене заодно подтверждает, что его TLS-сертификат по-прежнему работает - это то, что форвардер кликов никогда не мог бы показать.

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

Вот разделение, которое я бы настроил для команды, ведущей платные кампании на коротких ссылках:

Небольшая команда может начать только с канала Sentry - он покрывает сбои, которые молча тратят рекламный бюджет впустую. Добавляйте Datadog, когда кто-то действительно начинает смотреть на дашборды трафика, а зонд - в тот день, когда медленный редирект начнет стоить вам денег. Если Sentry - не инбокс вашей команды, те же события состояния ссылок могут идти в Discord или Telegram, а сломанная ссылка может также открывать тикет в Linear.

Читайте опорную статью → Как удержать p95 редиректов ниже 15 мс

Похожие статьи в блоге

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