Как сравнить живой трафик Astrina с логами сервера
Сравнивать живой трафик Astrina с серверными логами кажется простым делом, пока не появляется первое расхождение. В одном отчёте — 18 посещений. В логах — 24 запроса. У такого разрыва обычно есть причина, и чаще всего она до скучного банальна: редирект, бот, прокси или отметка времени, которая «уплыла» на 60 секунд.
Задача не в том, чтобы любой ценой заставить оба числа совпасть. Задача в том, чтобы сделать сравнение достаточно честным, чтобы ему можно было доверять. Если вы хотите понять, как сравнить живой трафик Astrina с логами сервера, начните с того, чтобы сузить задачу, прежде чем спорить с цифрами. На практике полезно держать в голове и формулировку «сопоставление live traffic и server logs», потому что именно она помогает не смешивать разные источники и ожидания.
1. Сначала подтвердите охват серверных логов, а потом сравнивайте
Сначала выберите точные файлы логов. Многие команды сваливают в одну таблицу продакшн, стейджинг и превью-трафик, а потом удивляются, почему Astrina показывает один рисунок, а сервер — другой. Оставьте один сайт, одну среду и один срез трафика. То есть заранее, простым текстом, зафиксируйте хост, приложение и источник логов.
Если ваша серверная конфигурация пишет несколько файлов в день, отметьте правило ротации. Если у вас есть отдельные логи для CDN-края и для origin-сервера, выберите один путь и придерживайтесь его в первом проходе. Чёткий охват делает остальную работу проще. Сумбурный охват делает каждое расхождение подозрительным.
Практический пример: сравнивайте только www.example.com в продакшне, только запросы к страницам и только последние 24 часа. Не добавляйте в то же сравнение API-трафик, health-check и админские URL. Это уже другие сущности.
2. Возьмите один точный временной интервал и приведите метки времени к одному виду
Живой трафик Astrina лучше всего работает, когда интервал задан точно. Серверные логи — тоже. Используйте один и тот же стартовый и конечный минутный рубеж в обоих местах, а не «примерно в полдень» или «где-то после обеда». Граница на уровне минут важна, потому что один запрос на стыке может изменить счётчик.
Используйте для обеих сторон одну временную зону. Если Astrina показывает UTC, а серверные логи — местное время, сравнение провалится ещё до начала. Один раз преобразуйте метки времени в логах и дальше держите их в этом формате весь анализ. Сдвиг на 15 минут может создать ложный всплеск. Сдвиг на час может сделать данные похожими на сломанные.
Есть простое правило, которое экономит время: никогда не сравнивайте скользящее 5-минутное окно Astrina с выгрузкой логов за календарный день. Это кажется очевидным. Но люди всё равно так делают. Выберите одно окно, запишите его и используйте везде.
3. Сведите серверные логи к запросам от людей к страницам
Серверные логи содержат всё подряд, и в этом проблема. Изображения, CSS, JavaScript-бандлы, запросы favicon, prefetch и обращения краулеров лежат рядом с посещениями страниц. Astrina обычно считает посещения страниц, поэтому лог нужно сузить до того же типа запроса.
Сначала отфильтруйте ресурсы. Затем уберите health-check, uptime-проверки, админские эндпоинты и внутренние инструменты. Если балансировщик раз в минуту запрашивает /health, эти строки быстро исказят итог. Страница вроде /pricing не должна сравниваться с 400 запросами к ассетам и тремя мониторинговыми пингами.
Отдельного внимания заслуживает фильтрация ботов. Некоторые боты несколько секунд выглядят как люди, а некоторые браузеры выглядят роботизированно из-за своего user agent. Не опирайтесь на один сигнал. По возможности используйте комбинацию пути запроса, user agent и известных диапазонов внутренних IP. Если в логах есть метка «bot» от WAF или reverse proxy, сохраните её. Позже она поможет.
4. Сопоставьте поля Astrina с полями логов
Прежде чем пытаться матчить записи, сделайте простую карту полей. В Astrina могут быть время, путь страницы, referrer и идентификатор, похожий на сессионный. В логах может быть сырая строка запроса, код статуса, user agent и IP-адрес. Это не одно и то же, и обращаться с ними так, будто это одно и то же, не стоит. Именно здесь особенно важно аккуратное сопоставление live traffic и server logs, потому что оно задаёт рамку для всех следующих шагов.
Сделайте таблицу из двух колонок на бумаге или в таблице. Слева — поле Astrina. Справа — поле лога. Время сопоставляется с временем запроса, путь — с путём URL, referrer — с заголовком referer, user agent — со строкой user agent. Идентификаторы, похожие на сессионные, сложнее, потому что в серверном логе их может не быть вовсе. Это не провал. Это просто ограничение.
| Поле Astrina | Ближайшее поле лога | Примечания |
|---|---|---|
| Timestamp | Request time | Сначала приведите к одной временной зоне |
| Page path | URL path | Уберите query string для группировки |
| Referrer | Referer header | Может отсутствовать или быть урезанным |
| User agent | User agent string | Полезно для проверки ботов |
Не ждите, что у каждого поля Astrina найдётся равнозначное поле в логе. Некоторые значения выводятся по косвенным признакам. Некоторые моделируются. Некоторые вообще отсутствуют в серверных логах. Именно поэтому карта важна: она показывает, где возможно прямое сравнение, а где — только приблизительное. И если на этом этапе возникает вопрос, почему не совпадают данные Astrina и серверных логов, чаще всего ответ скрывается именно в несовпадающих полях и допущениях.
5. Сводите трафик по URL-пути, а не по сырой строке запроса
Сырые строки запросов шумные. Один визит на /docs может выглядеть как /docs, /docs/ или /docs?utm_source=newsletter. Если сравнивать эти строки буквально, одна страница распадётся на три. Astrina, возможно, уже нормализует часть этого. Ваш лог, скорее всего, нет.
Используйте канонические пути. Сведите все варианты к одному и тому же пути страницы перед сравнением чисел. Уберите query string, если он не является частью идентичности страницы. Сведите воедино варианты с завершающим слэшем, если сайт считает их одной и той же страницей. Если участвуют редиректы, считайте конечную точку назначения, а не первый шаг.
На этом шаге часто обнаруживается неожиданность. Страница с 50 посещениями в Astrina может показать 63 записи в логах, потому что 13 запросов сначала попали на неканоническую версию, а потом были перенаправлены. Это не ошибка трафика. Это проблема пути. Сначала исправьте правило группировки, а уже потом меняйте трактовку.
6. Проверьте расхождения, вызванные кэшем, прокси или CDN
Промежуточные уровни меняют то, что доходит до origin-сервера. CDN может ответить на запрос раньше, чем origin вообще его увидит. Прокси может переписать заголовки. Кэш может отдать страницу пользователю, не оставив соответствующей записи в origin-логе. Это значит, что Astrina может увидеть визит, а серверный лог — промолчать.
Обратное тоже возможно. Origin-лог может записать запрос, который Astrina не засчитает, потому что браузер не успел полностью загрузить страницу, скрипт был заблокирован или запрос произошёл до запуска кода трекинга. Быстрая тестовая страница может сделать это очевидным. Откройте страницу в браузере, посмотрите вкладку network и проверьте, срабатывает ли запрос трекинга до завершения загрузки страницы.
Если вы используете CDN, уточните, откуда взят источник логов — с edge или с origin. Это разные записи. Ответ 304, закэшированный HTML-ответ или устаревший объект на edge могут создавать ложные различия. Вот где короткая заметка в таблице сравнения потом экономит час.
Для команд, которые впервые настраивают трекер, важен и путь установки. Проверять агент проще, если следовать тому же способу развёртывания, что используется в продакшне, поэтому многие команды держат руководство по настройке в runbook рядом со скриптом выгрузки логов.
7. Ведите короткий журнал расхождений, чтобы классифицировать каждый разрыв
Не оставляйте несоответствия безымянными красными ячейками. Ведите журнал расхождений: одна строка — один разрыв. Каждой строке присвойте категорию. На старте обычно хватает пяти: бот-шум, неполный охват логов, задержка доставки, дубликаты запросов и проблема нормализации пути.
Простой формат такой: путь страницы, число в Astrina, число в логе, размер разрыва, категория, заметка. В заметке должна быть одна конкретная причина, а не ощущение. «CDN отдал кэшированный HTML» — полезно. «Как-то странно» — нет. Если разрыв повторяется на трёх страницах, это подсказка. Если он появился один раз, это тоже подсказка, просто поменьше.
Одна команда может выяснить, что разрыв в 12 запросов вызван задержкой доставки логов. Другая — что расширение браузера блокирует скрипт трекинга на внутренних устройствах. Третья — что сервер пишет дублирующиеся строки при повторной попытке. Категории не дают воспринимать каждое несоответствие как один и тот же тип сбоя.
Если вам нужен более глубокий операционный контекст для этой работы, astrina для внутренних продуктовых команд, отслеживающих может стать полезным дополнением, особенно когда расхождение в трафике оказывается связано с деплоем.
8. Перед масштабированием повторите сравнение на маленькой выборке
Начните с одной страницы или одного дня. Не с десяти страниц. Не с полного месяца. Одна выборка заставляет правила стать явными, а это хорошо. Если выборка включает только /pricing, вы можете вручную проверить каждое расхождение и увидеть, работает ли метод.
Сначала ищите стабильность, а не широту охвата. Если один и тот же фильтр, правило пути и временной интервал дважды дают один и тот же ответ, переходите ко второй странице. Если после добавления ещё одного дня числа скачут, остановитесь и проверьте, не был ли в середине деплой, смена кэша или ротация логов. Маленькую выборку исправить быстрее, чем большую.
Есть полезная дисциплина: меняйте только одну переменную за раз. Перейдите с одной страницы на три страницы или с одного дня на два дня, но не делайте оба изменения одновременно. Иначе вы не поймёте, какое именно изменение сломало совпадение. Звучит медленно. На деле это быстрее, чем потом откатывать 40 строк неверных допущений.
Команды, которые мигрируют с другого аналитического инструмента, часто видят тот же паттерн во время перехода. Если это ваш случай, как перейти с Plausible — практичный материал, который стоит держать открытым, пока вы сверяете первую выборку с логами.
Что проверить, если цифры всё ещё не сходятся
Если после восьми шагов выше сравнение всё ещё выглядит неверным, проверьте три вещи по порядку: источник логов, правило пути и временной интервал. Не прыгайте сразу к скрипту трекинга. Удивительно часто «ошибки трекинга» на самом деле оказываются ошибками выгрузки логов. Ещё одна частая причина — незамеченный редирект с /page на /page/.
Также проверьте, не заканчивается ли браузерная сессия до завершения запроса трекинга. Мобильные соединения более хрупкие, чем десктопные. Страница может визуально загрузиться, а аналитический запрос — быть отменён. Тогда у Astrina окажется меньше посещений, чем в серверном логе. И наоборот тоже бывает, когда браузер повторяет запрос, а сервер считает обе попытки.
Ещё одна деталь: если на сайте есть страница обслуживания или режим обслуживания, учитывайте этот трафик отдельно. Событие обслуживания меняет и поведение пользователей, и форму логов. Если нужен дополнительный ориентир для такой ситуации, что делать, когда в Astrina uptime поможет правильно оформить инцидент до сравнения с логами.
Самые сильные сравнения — маленькие, задокументированные и воспроизводимые. Чистый охват, одно временное окно, отфильтрованные запросы страниц и канонические пути обычно объясняют большую часть разницы. Оставшееся расхождение и есть то место, где начинается полезная работа.
