Моніторинг URL у Datadog

Моніторинг URL у Datadog для коротких посилань Elido складається з двох джерел. Сам Elido надсилає дані про кліки: один лог на клік у Datadog Logs intake плюс три метрики кількості кліків, що скидаються кожні 60 секунд. Затримку редиректу чи коди статусу він не надсилає. Для них ви спрямовуєте HTTP-тест Datadog Synthetics на канарне коротке посилання, і дашборд затримки редиректів, монітори та SLO стоять поверх цієї пари.

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

Якщо ви тут через затримку, спершу прочитайте, як працює бюджет p95 до 15 мс. Він пояснює, як виглядає здорове число, перш ніж обирати поріг.

Що Elido насправді надсилає в Datadog

Кожен клік у підключеному робочому просторі йде двома шляхами. Шлях логів надсилає пакет з одного запису на https://http-intake.logs.<site>/api/v2/logs відразу після запису кліку. Шлях метрик збільшує лічильник у пам'яті, а скидальник раз на хвилину надсилає значення на https://api.<site>/api/v2/series. Обидва автентифікуються заголовком DD-API-KEY.

Метрики - це gauge, а значення - кількість кліків, пораховану з попереднього скидання. Тож точка 37 означає 37 кліків приблизно за останню хвилину. Це природна одиниця для операційного графіка, і вона означає, що для підсумків ви підсумовуєте за часом, а не застосовуєте as_count(). Зверніть увагу, чого бракує: на метриках немає тегів link_id чи slug. Я б назвав це розумним рішенням щодо вартості, бо Datadog тарифікує кастомні метрики за кожну унікальну комбінацію тегів, а тег slug на завантаженому робочому просторі помножив би кількість рядів на кількість посилань.

Лог також несе link_id як тег Datadog і має тег service:click-ingester із хостом elido-edge, тож це назва сервісу для фільтра. Поля надходять вкладеними в об'єкт attributes, тому в Log Explorer фасети виглядають як @attributes.slug і @attributes.country. Розгорніть один лог, перш ніж будувати щось. Десять секунд, і це рятує від зламаного запиту.

Підключення Datadog у вашому робочому просторі Elido

Налаштування - це два поля. Вам потрібен ключ API Datadog (не ключ застосунку) і сайт, на якому працює ваша організація.

1. У Datadog відкрийте Organization Settings, потім API Keys і створіть ключ з назвою на кшталт elido-forwarder.
2. Перевірте свій сайт. Посібник із сайтів Datadog зіставляє кожну URL входу з її сайтом; app.datadoghq.eu означає, що ви вводите datadoghq.eu, us5.datadoghq.com означає, що ви вводите саме це.
3. В Elido відкрийте Integrations, оберіть Datadog, вставте ключ, введіть сайт і збережіть. Ключ зашифровано у спокої.
4. Зачекайте до п'яти хвилин, бо пересилач кешує налаштування інтеграції робочого простору, потім клацніть одне зі своїх посилань з телефона й пошукайте source:elido у Log Explorer.

Залиште сайт порожнім, і Elido припустить datadoghq.com. Для організації з ЄС це класична тиха відмова. Описка робить те саме. Кожен POST провалюється, і ніхто не бачить помилки.

Кнопка Test connection надсилає один тестовий лог (позначений elido_test: true) на ваш сайт Datadog і показує відповідь Datadog, тож хибний ключ чи сайт провалиться одразу з 403 від Datadog. Успіх доводить, що ключ працює, а не те, що ваші пайплайни та індекси зберігають логи, тож справжній доказ - досі лог кліку, що з'явився. Те саме правило, що й для пересилача кліків у Mixpanel: справжній клік, або цього не було.

Побудова дашборда затримки редиректів, що вимірює стрибок

Оскільки Elido не надсилає таймінгів, дані про затримку мають надходити від того, що робить запити. HTTP-тест Datadog Synthetics - правильний інструмент, і він вимірює те, що відчуває відвідувач, включно з DNS і TLS.

Ось тест, який я налаштовую в кожному робочому просторі:

• URL: окреме канарне посилання, бажано на вашому власному домені, що веде кудись нудне та стабільне.
• Слідувати за редиректами: вимкнено. Увімкнене - ви міряєте свою цільову сторінку, і повільне головне зображення розбудить вас о 3 ранку через редирект, який був у порядку.
• Перевірки: код статусу 302 (типово; використовуйте 301 чи 307, якщо задали їх, а 301 проти 302 пояснює компроміс), заголовок location містить ваше призначення, а час відповіді нижчий за поріг.
• Локації: щонайменше три, одна в регіоні ЄС, де ваша аудиторія. Запуск щохвилини.
• Заголовок: User-Agent, що містить bot, щоб Elido вважав пробу ботом і пропускав подію кліку.

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

Далі дашборду потрібні чотири віджети. Час відповіді за локаціями, як часовий ряд синтетичного тесту. Частка пройдених перевірок. Кліки за хвилину з elido.clicks. І топ країн.

# Clicks per minute across the workspace (gaps become zeros)
default_zero(sum:elido.clicks{workspace_id:42})

# Hourly click totals
sum:elido.clicks{workspace_id:42}.rollup(sum, 3600)

# Top 10 countries over the dashboard window
top(sum:elido.clicks_by_country{workspace_id:42} by {country}, 10, 'sum', 'desc')

Навіщо default_zero? Бо хвилина без кліків не дає жодної точки, і без функції інтерполяції Datadog проводить пряму лінію через розрив. Ця лінія бреше.

Монітори для падінь кліків і зламаних коротких посилань

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

Редирект зламаний або повільний. Синтетичний тест уже є монітором. Сповіщайте, коли два чи більше розташувань провалюються в одному запуску, щоб одна нестабільна область проб нікого не будила. Будь-яка відповідь, крім вашого 302, провалює перевірку статусу, тож видалене, прострочене чи призупинене канарне посилання з'являється тут як 404 або 410.

Трафік зупинився. Створіть метричний монітор на sum:elido.clicks{workspace_id:42} і ввімкніть сповіщення про відсутні дані через, скажімо, 30 хвилин. Оскільки Elido нічого не надсилає за тиху хвилину, «немає даних» тут справді означає «немає кліків», а це подія, яка вас цікавить під час кампанії.

Трафік дивний. Монітор аномалій на тій самій метриці з напрямком «нижче» ловить кампанію, що зазвичай дає 4000 кліків на годину, а раптом дає 200. Я бачив цей патерн тричі, і щоразу причина була поза посиланням: відхилена реклама, розсилка не тому сегменту, QR-плакат за риштуванням. Дайте йому кілька тижнів історії, перш ніж довіряти його смугам.

Хочете сповіщення по окремих посиланнях? Метрики цього не вміють, але логи вміють. Створіть метрику на основі логів із source:elido, згруповану за @attributes.slug, і отримаєте кількість кліків по slug, яку можна моніторити. Обмежте її відфільтрованим набором slug кампаній, інакше вартість кардинальності повернеться через бічні двері.

SLO, який справді можна захистити

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

Я б почав із 99,9% за 30 днів. Це близько 43 хвилин невдалих перевірок на місяць, і це бюджет, який можна пояснити маркетинг-лідеру одним реченням. Не будуйте його на обсязі кліків. Кліки вимірюють попит, а не здоров'я; посилання, на яке ніхто не клікає, цілком доступне.

Якщо рівної лінії на цьому віджеті SLO вам якраз бракувало, налаштуйте робочий простір, спрямуйте канарку на власний домен і запустіть на тиждень, перш ніж задавати ціль.

Самостійно розгорнутий Elido: збір лічильників редиректів

Якщо ви запускаєте сервіс редиректів самостійно (можливо лише як розгортання за контрактом Enterprise у вашій інфраструктурі; Elido не продається як самостійно розгортуваний продукт для завантаження), у вас є ще одне джерело. Сервіс редиректів відкриває кінцеву точку Prometheus на /metrics, і перевірка OpenMetrics агента Datadog може її збирати. Корисний ряд - elido_edge_redirect_total, лічильник із мітками fleet і outcome, де результати включають ok, notfound, expired, paused, disabled, blocked, capped та error.

Це дає те, чого не дає інтеграція SaaS: справжню частку 404 по всьому трафіку, обчислену як notfound до загальної кількості. Другий лічильник, edge_redirect_clicks_filtered_bot_total, показує, скільки редиректів було віддано ботам без події кліку. Гістограми затримки на цій кінцевій точці немає. Затримка й надалі береться із Synthetics, самостійно розгорнуто чи ні. Плейбук самостійного розгортання на k3s описує, де ця кінцева точка стоїть у розгортанні.

Де зупиняється інтеграція з Datadog

Тепер обмеження, ті, що вкусять першими.

Доставка працює за принципом найкращих зусиль і йде з конвеєра кліків, тож може трохи відставати від редиректу. Невдалий POST логу отримує одну повторну спробу за секунду, а потім відкидається. Невдале скидання метрик не повторюється взагалі; та хвилина втрачена, а наступне вікно починається з чистого аркуша. Сприймайте elido.clicks як лінію тренду й зводьте підсумки з власною аналітикою кліків Elido, яка є джерелом істини.

Логи несуть IP відвідувача і повну URL призначення, включно з тегами UTM. Якщо ваша організація Datadog у США, це персональні дані, що залишають ЄС, а посібник із резидентності даних ЄС для маркетингових команд показує, як це зважити. Щонайменше оберіть сайт ЄС, якщо він у вас є.

Вартість логів зростає з кліками, один прийнятий лог на клік. Вірусне посилання дає вірусний рахунок. Фільтри виключення або метрика на основі логів у парі з індексом короткого зберігання тримають це в розумних межах.

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

Сторінки документації Datadog, на які є посилання вище, переглянуто з датою звернення 2026-10-25. Про бюджет затримки за редиректом див. допис про p95 до 15 мс

Читайте також у блозі

• Відстеження посилань у Mixpanel - той самий пересилач кліків, спрямований на продуктову аналітику.
• Стратегія кешу для редиректів URL - чому затримка редиректу виглядає саме так.
• Стратегія запобігання гниттю посилань - що робити після спрацювання монітора 404.
• Кліки за короткими посиланнями проти сесій GA4 - чому ваші кліки й сесії аналітики розходяться.
• Серверне відстеження GA4 через редиректи - серверні події кліків, надіслані до Google.
• Відстеження посилань у Klaviyo - той самий пересилач кліків, що надсилає кожен клік у Klaviyo.