Моніторинг URL-адрес у Datadog: метрики редиректів для коротких посилань

Моніторинг URL-адрес коротких посилань Elido у Datadog спирається на два джерела. Сам 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 у завантаженому робочому просторі збільшив би кількість рядів відповідно до кількості посилань.

Поля журналу надходять вкладеними в об'єкт 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. Зачекайте до п'яти хвилин, оскільки forwarder кешує налаштування інтеграції робочого простору, потім відкрийте одне зі своїх посилань із телефона та знайдіть source:elido у Log Explorer.

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

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

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

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

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

• URL: окреме канаркове посилання, бажано на вашому власному домені, що вказує на щось просте й стабільне.
• Follow redirects: вимкнено. Якщо залишити цю опцію ввімкненою, ви вимірюватимете час завантаження цільової сторінки, і повільне головне зображення розбудить вас о 3-й ночі через редирект, який працював нормально.
• Assertions: код стану дорівнює 302 (типове значення; використовуйте 301 або 307, якщо саме його ви налаштували, а в матеріалі 301 проти 302 пояснено компроміс), заголовок location містить вашу цільову адресу, а час відповіді нижчий за поріг.
• Locations: щонайменше три, одна з них - у регіоні ЄС, де перебуває ваша аудиторія. Запускайте щохвилини.
• Header: 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 нічого не надсилає в тиху хвилину, "no data" тут справді означає "no clicks" - саме цю подію вам потрібно відстежувати під час кампанії.

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

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

SLO, який можна обґрунтувати

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

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

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

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

У самостійно розгорнутій інсталяції ви отримуєте ще одне джерело. Сервіс редиректів відкриває кінцеву точку Prometheus за адресою /metrics, а перевірка OpenMetrics Datadog Agent може зчитувати її. Корисний ряд - elido_edge_redirect_total, лічильник із мітками fleet і outcome, де значення outcome включають ok, notfound, expired, paused і error.

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

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

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

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

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

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

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

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

Пов'язані матеріали в блозі

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