Моніторинг коротких посилань за допомогою 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-сервісах покривають таксономію подій.