Мониторинг коротких ссылок с помощью Sentry и Datadog

Если короткая ссылка возвращает 5xx в течение 30 секунд во время кампании в Instagram, вы теряете примерно 4-7% когорты. Большинство инженерных команд узнаёт об этом на следующее утро, когда кто-то бросает скриншот со Slack. Этот гайд - плейбук, который мы используем в Elido, чтобы обнаруживать сбои редиректов менее чем за 60 секунд с помощью двух инструментов, за которые вы, скорее всего, уже платите: Sentry для issues и Datadog для метрик. Это та же схема, что мы используем на собственных edge POP, обрабатывающих около 240 миллионов редиректов в месяц при p99 в 13 мс.

Кратко: Sentry хорош в одном применительно к редиректам - "один issue на сломанный пункт назначения, со списком слагов, которые его задели." Datadog занимается ортогональным - временными рядами. Вам нужно и то, и другое, а Elido отправляет в оба нативно. Sentry сейчас в Beta (вставьте DSN - готово); Datadog в Live с выделенным коллектором метрик. Ниже: какие сигналы важны, как работает интеграция с Sentry изнутри и что на самом деле должен содержать дашборд Datadog для здоровья редиректов.

Какие сигналы важны при мониторинге редиректов

Прежде чем что-то настраивать, решите, что вам действительно важно. Мониторинг редиректов - задача уже, чем полноценный APM, и набор сигналов невелик. Четыре сигнала покрывают около 95% реальных инцидентов:

События редиректов 4xx. 404 на короткой ссылке - почти всегда одно из трёх: слаг удалён, слаг истёк или кто-то перебирает ваш домен. 410 намеренно и шумит - мы подавляем его в алертах. 451 (геоблок) интересен только в агрегате. Объём 4xx на событие слишком шумный для пейджинга; обращайтесь с ним как с метрикой, а не с issue.

События редиректов 5xx. Вот это - повод звонить дежурному. 5xx означает, что edge не смог добраться до Redis (кеш L2), до api-core (origin gRPC) или что целевой URL получил DNS-ошибку при HEAD-проверке. Для каждого случая есть отдельный runbook. Sentry-трансформер в api-core тегирует первопричину, поэтому заголовок issue будет примерно 5xx: redis-timeout (затронуто 12 слагов, последний раз 14с назад), а не обобщённый Internal Server Error.

p99 задержки на edge. Редирект с cache HIT должен обрабатываться менее чем за 15 мс при p99 из любого нашего POP. Мы алертим, если p99 устойчиво держится выше 50 мс в течение 5 минут. Причина: один медленный запрос не будет держать p99 высоким 5 минут, а вот реплика Redis, выпавшая из синхронизации, - будет. Смотрите redirect p95 ниже 15 мс для разбора бюджета задержки.

Аномалия частоты кликов и ошибки сканирования. Аномалии частоты кликов - поздняя система предупреждения. Если кампания обычно даёт 4000 кликов в час, а вдруг только 200 - где-то вверх по стеку что-то сломалось (объявление отклонили, QR-наклейка отвалилась, кто-то убрал не ту ссылку). Ошибки сканирования приходят от сервиса url-scanner, который проверяет пункты назначения на вредоносный контент. Всплеск ошибок сканирования обычно означает, что аккаунт скомпрометирован и создаёт фишинговые ссылки.

Маршрутизация сигналов в нужный инструмент

Не каждый сигнал подходит для каждого инструмента. Если отправлять объём 4xx в Sentry как issues, настоящий issue "сломанный пункт назначения" утонет в шуме. Отправлять p99 задержки в Sentry как алерты неудобно: система алертов Sentry построена вокруг частоты issues, а не временных рядов. Ментальная модель: Sentry = исключения, Datadog = метрики, Slack = люди, Linear = тикеты на доработку.

Elido отправляет туда, где стоит крестик. Мы не отправляем события 4xx в Sentry - они не являются исключениями. Мы также не отправляем каждое событие клика в Datadog - объём не оправдывает стоимость (кастомные метрики Datadog тарифицируются за уникальную комбинацию тегов, и кардинальность слаг x регион x тир обошлась бы в $4000 в месяц для среднего workspace). Разделение выше - результат 9 месяцев внутренней эксплуатации системы.

Интеграция с Sentry: вставить DSN и envelope-трансформер

Интеграция Sentry в Elido находится в Beta, но функционально завершена. Настройка - три клика. Идёте в /integrations, находите Sentry, вставляете DSN и выбираете типы событий для пересылки. DSN - единственный секрет. Мы храним его в Postgres с envelope-шифрованием (KMS-wrapped по ADR-0036), так что даже наши администраторы БД не могут прочитать его в открытом виде.

Под капотом api-core имеет webhook-трансформер, который слушает внутреннюю шину событий (топик Redpanda redirect.errors) и упаковывает совпадающие события в Sentry-конверты. Формат envelope задокументирован в спецификации envelope Sentry - это просто HTTP POST с заголовочной строкой JSON, заголовком элемента JSON и полезной нагрузкой элемента JSON, разделёнными переводами строк. Никакого SDK Sentry в пути запросов нет. Это сохраняет код edge (services/edge-redirect) лёгким и избегает зависимости в hot path.

Трансформер делает три полезных вещи:

Fingerprinting. Sentry группирует события по fingerprint. Наивный fingerprint свёл бы все 5xx в один огромный issue - это бесполезно. Наш трансформер строит fingerprint по error_class:destination_host, поэтому тайм-аут Redis на ссылках, ведущих на acme.com, - отдельный issue от тайм-аута Redis на ссылках на globex.com. Принцип "один сломанный пункт назначения = один issue" выполняется на самом деле.

Агрегация слагов. Каждое событие Sentry несёт блок tags со списком первых 50 затронутых слагов, ID workspace и доменом редиректа. Когда 800 слагов ведут на один пункт назначения и он начинает отдавать DNS NXDOMAIN, вы видите один issue с slugs_affected: 800 и выборкой из 50, а не 800 отдельных алертов.

Rate-limiting по workspace. Workspace с неудачной кампанией может сгенерировать 10 000 ошибок 5xx за 60 секунд. Sentry примет все и выставит за них счёт. Трансформер ограничивает до 50 конвертов в минуту на workspace и сворачивает остальные в одно событие "suppressed" с подсчётом. Мы узнали это на своём опыте, когда клиент направил 4 миллиона коротких ссылок на домен, начавший отдавать 503.

Если вы хотите обрабатывать ingest самостоятельно вместо трансформера Elido, документация по наблюдаемости описывает альтернативный путь: подпишитесь на наш webhook event bus и конвертируйте события в Sentry-конверты в своей инфраструктуре. Большинство команд не заморачиваются. Трансформер быстрее взять готовым, чем написать своё.

Замечание о том, что появляется как "issue": UI Sentry показывает каждое сгруппированное событие как карточку issue со sparkline, примерным событием и списком тегов. Для ошибок редиректов самый полезный тег - cache_result (HIT, MISS, BYPASS). Если вы видите волну 5xx с cache_result: BYPASS, кто-то в вашей команде, скорее всего, задеплоил изменение, принудительно включившее bypass кеша для тестирования, и забыл откатить. Реальная история, случилась дважды за последний год.

Интеграция с Datadog: коллектор метрик и дашборды

Datadog находится в Live. Настройка тоже три клика, но архитектура другая. Вместо трансформера на каждое событие мы запускаем коллектор метрик на стороне api-core, который агрегирует телеметрию редиректов в формат метрик Datadog и отправляет пакеты каждые 10 секунд через API кастомных метрик Datadog. Коллектор предагрегирует, поэтому мы никогда не отправляем сырые события. Это удерживает кардинальность кастомных метрик низкой и счёт Datadog под контролем.

Метрики, которые мы отправляем по умолчанию:

• elido.redirect.count - счётчик, тегированный по domain, tier, region, cache_result, status_class (2xx/3xx/4xx/5xx)
• elido.redirect.latency.ms - распределение, тегированное по domain, tier, region, cache_result
• elido.click.count - счётчик, тегированный по domain, tier (дедуплицировано на границе click-ingester)
• elido.scanner.failure.count - счётчик, тегированный по reason (malware, phishing, expired_cert, dns_nxdomain)

Теги - это рычаг. Вы можете получить "p99 задержки для link.acme.com в FRA за последние 4 часа" однострочным запросом. Не нужно заранее строить дашборды для каждого домена. Смотрите /integrations/datadog для справки по метрикам и таксономии тегов.

Четыре панели выше - то, что мы показываем на собственном экране NOC. Они покрывают ежедневный вид дежурного. p99 задержки на edge по регионам выявляет регрессии на уровне POP (сбой Hetzner FRA выглядит иначе, чем сбой OVH SGP, и вы хотите видеть их рядом). Частота ошибок по домену top-10 вытаскивает шумных клиентов - если acme.com даёт 8% 5xx, а все остальные 0,02%, у вас не проблема Elido, у вас проблема acme. Объём кликов по тирам (f / s / b для free, starter, business через изоляцию по тирам) показывает, идёт ли всплеск трафика от платящего тенанта или от кампании бесплатного тира, которую нужно ограничить. Количество сломанных редиректов за последние 24ч - закрывающая метрика: редирект, вернувший 4xx, должен быть либо починен, либо истёкшим и удалённым в течение 24 часов; путь авторемонта описан в предотвращении деградации ссылок.

Рекомендуемые пороги алертов (это наши дефолты; можно переопределить на уровне workspace):

• elido.redirect.latency.ms p99 > 50 мс устойчиво 5 мин - звонить дежурному
• elido.redirect.count{status_class:5xx} частота > 0,5% устойчиво 2 мин - звонить дежурному
• elido.redirect.count{status_class:4xx} частота > 5% устойчиво 10 мин - только Slack
• elido.scanner.failure.count частота > 10/мин для workspace - проверка безопасности, без пейджа

Порог 0,5% для 5xx консервативен. Наш базис - ~0,01% (в основном DNS-сбои на пунктах назначения клиентов), поэтому 0,5% - отклонение в 50 раз, что реально.

Когда что использовать

Для небольшой команды с продуктом, ориентированным на разработчиков, на /solutions/developers, Sentry в одиночку, вероятно, достаточно. Вы будете получать пейджи при реальных 5xx, видеть issues и чинить их. У вас не будет культуры дашбордов, ради которой стоит платить $1,50/хост/месяц за Datadog.

Для крупной компании на /solutions/enterprise с ротацией дежурств SRE нужны оба. Sentry для потока issues, Datadog для дашбордов, Slack-алерты, подключённые к PagerDuty, для пейджинга. Руководство по наблюдаемости описывает маппинг сервисов PagerDuty, если вы пойдёте этим путём.

Для всех между: Sentry с первого дня (бесплатный тир Sentry подходит для менее 5000 событий в месяц), Datadog когда у вас появляется больше одного домена редиректа или больше одного региона трафика. Счёт за коллектор метрик Datadog на типичном workspace Elido Business - около $35 в месяц, то есть цена того, чтобы инженер не гонял grep по nginx-логам в воскресенье.

Что это даёт такого, чего нет у обычных uptime-мониторов

Проверка Pingdom или UptimeRobot на f.elido.me скажет вам, доступен ли edge. Она не скажет, что пункт назначения слага summer24 начал отдавать DNS NXDOMAIN 12 минут назад, или что p99 в SGP в 4 раза выше p99 в FRA, потому что лидер раздела Redpanda перезапустился. Мониторинг редиректов - задача, осознающая пункт назначения. Сам редирект может быть здоров, тогда как ссылка мертва.

Связка Sentry + Datadog выше даёт вам видимость, осознающую пункт назначения, без написания кастомных проб. Sentry говорит, что сломано на уровне пункта назначения. Datadog говорит, что деградирует на уровне edge. Slack информирует людей, Linear хранит задачи. Подключение - вставить DSN для Sentry и пройти один OAuth-флоу для Datadog. Начните с Sentry сегодня; добавьте Datadog, когда количество ваших доменов редиректов превысит один.

Цены и что входит в каждый тир смотрите на /pricing. Для API-поверхности вокруг подписок на события, если хотите выстроить своё решение, /features/analytics и разбор Sentry на 12 Go-сервисах покрывают таксономию событий.