Як порівняти живий трафік Astrina з серверними журналами
Порівнювати живий трафік Astrina із серверними журналами здається просто, доки не з’являється перша невідповідність. Один звіт показує 18 відвідувань. Журнал — 24 запити. Така різниця зазвичай має причину, і часто ця причина цілком буденна: редирект, бот, проксі або часовий зсув на 60 секунд.
Завдання не в тому, щоб будь-якою ціною змусити обидві цифри збігтися. Завдання — зробити порівняння достатньо чесним, щоб йому можна було довіряти. Якщо ви хочете зрозуміти, як порівняти трафік Astrina з серверними журналами, почніть із того, щоб звузити проблему ще до того, як сперечатися з цифрами.
1. Підтвердіть межі серверного журналу перед порівнянням
Спершу виберіть точні файли журналів. Багато команд змішують виробничий, тестовий і попередній трафік в одній таблиці, а потім дивуються, чому Astrina показує один шаблон, а сервер — інший. Залиште один сайт, одне середовище й один зріз трафіку. Тобто спершу вкажіть текстом хост, застосунок і джерело журналу — і лише потім переходьте далі.
Якщо ваша серверна конфігурація створює кілька файлів на день, зафіксуйте правило ротації. Якщо у вас окремі журнали для CDN edge та origin-сервера, оберіть один шлях і дотримуйтеся його на першому проході. Чіткі межі зменшують обсяг роботи. Розмиті межі роблять кожну невідповідність підозрілою.
Практичний приклад: порівнюйте лише www.example.com у продакшені, лише запити до сторінок і лише останні 24 години. Не додавайте до цього API-трафік, перевірки стану чи адмін-URL. Це вже інші сутності.
2. Оберіть один точний часовий проміжок і нормалізуйте часові позначки
Живий трафік Astrina працює найкраще, коли проміжок точний. Серверні журнали працюють найкраще, коли проміжок точний. Використовуйте однакову хвилину початку й однакову хвилину завершення в обох місцях, а не “десь опівдні” чи “після обіду”. Обрізка на рівні хвилин має значення, бо один запит на межі може змінити підрахунок.
Використовуйте один часовий пояс для обох сторін. Якщо Astrina показує UTC, а серверні журнали записані в місцевому часі, порівняння зламається ще до початку. Один раз переведіть часові позначки журналу, а потім залиште їх у цьому форматі на весь аналіз серверних журналів і трафіку. Зсув на 15 хвилин може створити хибний пік. Зсув на 1 годину може зробити дані схожими на зламані.
Є просте правило, яке економить час: ніколи не порівнюйте рухоме 5-хвилинне вікно Astrina з витягом журналу за календарний день. Це здається очевидним. Люди все одно так роблять. Оберіть одне вікно, запишіть його і використовуйте всюди.
3. Відфільтруйте журнали до людських запитів до сторінок
Серверні журнали містять усе, і саме в цьому проблема. Поруч із відвідуваннями сторінок у них є зображення, CSS, JavaScript-бандли, запити favicon, prefetch-запити та звернення ботів. Astrina зазвичай рахує перегляди сторінок, тож журнал треба звузити до того самого типу запиту.
Спершу відфільтруйте ресурси. Потім приберіть перевірки стану, uptime-запити, адмін-ендпоїнти та внутрішні інструменти. Якщо ваш балансувальник навантаження викликає /health щохвилини, ці рядки швидко спотворять підсумки. Сторінку на кшталт /pricing не можна порівнювати з 400 запитами до ресурсів і трьома моніторинговими пінгами.
Фільтрація ботів теж заслуговує уваги. Деякі боти кілька секунд виглядають як люди, а деякі браузери здаються роботизованими через user agent. Не покладайтеся лише на один сигнал. По можливості використовуйте комбінацію шляху запиту, user agent і відомих внутрішніх діапазонів IP. Якщо у вашому журналі є мітка “bot” від WAF або зворотного проксі, залиште її. Вона стане в пригоді пізніше.
4. Зіставте поля Astrina з полями журналу
Перш ніж намагатися узгодити записи, створіть просту карту полів. Astrina може показувати часову позначку, шлях сторінки, реферер і схожий на сесію ідентифікатор. Журнал може містити сирий рядок запиту, код статусу, user agent та IP-адресу. Це не одне й те саме, і так до них ставитися не слід.
Зробіть таблицю з двох колонок на папері або в таблиці. Ліворуч — поле Astrina. Праворуч — поле журналу. Часова позначка відповідає часовій позначці, шлях сторінки — шляху запиту, реферер — заголовку referer, user agent — рядку user agent. Ідентифікатори, схожі на сесію, складніші, бо в серверному журналі їх може взагалі не бути. Це не провал. Це лише межа можливостей.
| Поле Astrina | Найближче поле журналу | Примітки |
|---|---|---|
| Часова позначка | Час запиту | Спершу переведіть усе в один часовий пояс |
| Шлях сторінки | Шлях URL | Для групування приберіть рядки запиту |
| Реферер | Заголовок Referer | Може бути відсутнім або скороченим |
| User agent | Рядок user agent | Корисно для перевірки ботів |
Не очікуйте, що кожне поле Astrina матиме повний аналог у журналі. Деякі значення є похідними. Деякі змодельовані. Деяких просто немає в серверному журналі. Саме тому карта важлива: вона показує, де можливе пряме порівняння, а де воно лише приблизне.
5. Узгоджуйте трафік за шляхом URL, а не за сирим рядком запиту
Сирі рядки запиту шумні. Один візит до /docs може виглядати як /docs, /docs/ або /docs?utm_source=newsletter. Якщо порівнювати ці рядки буквально, одна сторінка розіб’ється на три. Astrina може вже частково нормалізувати це. Ваш журнал, найімовірніше, ні.
Використовуйте канонічні шляхи. Об’єднайте всі варіанти в один шлях сторінки перед порівнянням кількості. Приберіть рядки запиту, якщо вони не є частиною ідентичності сторінки. Зведіть кінцеві слеші до одного варіанта, якщо сайт трактує їх як ту саму сторінку. Якщо є редиректи, рахуйте кінцеву адресу, а не перший крок.
На цьому етапі часто відкривається несподіванка. Сторінка з 50 візитами в Astrina може показати 63 записи в журналі, бо 13 запитів спершу потрапили на неконанічну версію, а потім були перенаправлені. Це не помилка трафіку. Це проблема шляху. Виправте правило групування, перш ніж змінювати інтерпретацію.
6. Перевірте невідповідності, спричинені кешуванням, проксі або CDN
Проміжні рівні змінюють те, що доходить до origin-сервера. CDN може відповісти на запит ще до того, як origin його взагалі побачить. Проксі може переписати заголовки. Кешована відповідь може віддати сторінку користувачеві, не залишивши відповідного рядка в origin-журналі. Це означає, що Astrina може побачити візит, а серверний журнал — ні.
Зворотна ситуація теж можлива. Origin-журнал може зафіксувати запит, який Astrina не рахує, бо браузер не встиг повністю завантажити сторінку, скрипт було заблоковано або запит відбувся до виконання коду відстеження. Простий тестовий розділ може це наочно показати. Відкрийте сторінку в браузері, перевірте вкладку мережі й подивіться, чи спрацьовує запит відстеження до завершення завантаження сторінки.
Якщо ви використовуєте CDN, перевірте, чи джерелом журналу є edge чи origin. Це різні записи. Відповідь 304, кешована HTML-відповідь або застарілий об’єкт на edge можуть створювати хибні відмінності. Саме тут коротка примітка в таблиці порівняння економить годину пізніше.
Для команд, які вперше налаштовують трекер, важливий і шлях встановлення. Налаштування агента легше перевірити, якщо ви використовуєте той самий спосіб розгортання, що й у продакшені, тому багато команд тримають посібник із налаштування поруч зі скриптом експорту журналів у своєму runbook.
7. Використовуйте короткий журнал розбіжностей, щоб класифікувати кожен розрив
Не залишайте невідповідності анонімними червоними клітинками. Ведіть журнал розбіжностей по одному рядку на кожен розрив. Для кожного рядка вкажіть категорію. На старті зазвичай вистачає п’яти категорій: бот-шум, відсутнє покриття журналу, затримка надходження, дубльовані хіти та проблема нормалізації шляху.
Ось простий формат: шлях сторінки, кількість у Astrina, кількість у журналі, розмір розриву, категорія, примітка. У примітці має бути одна конкретна причина, а не відчуття. “CDN віддав кешований HTML” — корисно. “Виглядає дивно” — ні. Якщо розрив повторюється на трьох сторінках, це підказка. Якщо він з’являється один раз, це теж підказка, просто менша.
Одна команда може з’ясувати, що розрив у 12 запитів спричинено затримкою доставки журналів. Інша — що розширення браузера блокує скрипт відстеження на внутрішніх пристроях. Третя — що сервер записує дублікати рядків під час повторної спроби. Категорії не дають сприймати кожну невідповідність як один і той самий збій.
Якщо вам потрібен глибший операційний контекст для цієї роботи, astrina для внутрішніх продуктових команд, які відстежують може бути корисним супровідним матеріалом, особливо якщо розбіжність трафіку виявиться пов’язаною з релізом.
8. Перезапустіть порівняння на невеликій вибірці, перш ніж масштабувати
Почніть з однієї сторінки або одного дня. Не з десяти сторінок. Не з повного місяця. Одна вибірка змушує зробити правила явними, а це добре. Якщо у вибірку входить лише /pricing, ви зможете вручну перевірити кожну невідповідність і побачити, чи працює метод.
Шукайте стабільність, а не широту. Якщо той самий фільтр, правило шляху й часовий проміжок двічі дають однакову відповідь, переходьте до другої сторінки. Якщо цифри стрибають після додавання ще одного дня, зупиніться й перевірте, чи не було під час цього релізу, зміни кешу або ротації журналів. Маленьку вибірку легше виправити, ніж велику.
Тут корисна одна дисципліна: змінюйте лише одну змінну за раз. Перейдіть з однієї сторінки на три сторінки або з одного дня на два, але не все одразу. Інакше ви не знатимете, яка зміна зламала збіг. Це звучить повільно. Але це швидше, ніж потім розгрібати 40 рядків хибних припущень.
Команди, які переходять з іншого аналітичного інструмента, часто бачать той самий шаблон під час міграції. Якщо це ваш випадок, як мігрувати з Plausible — практичний матеріал, який варто тримати відкритим, поки ви перевіряєте першу вибірку на відповідність журналам.
Що перевірити, якщо цифри все одно не збігаються
Якщо після восьми кроків порівняння все ще виглядає неправильним, перевірте три речі в такому порядку: джерело журналу, правило шляху і часовий проміжок. Не стрибайте одразу до скрипта відстеження. Дивовижна кількість “помилок відстеження” насправді є помилками витягу журналів. Інша поширена причина — пропущений редирект з /page на /page/.
Також перевірте, чи не закінчується браузерна сесія до завершення запиту відстеження. Мобільні з’єднання менш стабільні за настільні. Сторінка може візуально завантажитися, а аналітичний виклик — бути скасованим. Тоді в Astrina буде менше відвідувань, ніж у серверному журналі. І навпаки теж буває: браузер повторює запит, а сервер рахує обидві спроби.
І ще один момент: якщо на вашому сайті є сторінка обслуговування або режим обслуговування, обробляйте цей трафік окремо. Подія обслуговування змінює і поведінку користувачів, і форму журналів. Якщо вам потрібен супровідний матеріал для такої ситуації, що робити, коли час роботи Astrina допоможе сформулювати інцидент ще до порівняння з журналами.
Найнадійніші порівняння — малі, задокументовані й повторювані. Чисті межі, одне часовe вікно, відфільтровані запити до сторінок і канонічні шляхи зазвичай пояснюють більшість розриву. Те, що залишається, і є місцем для корисної роботи.
