Анализ журнала: Что журнал веб-сервера показывает о ваших посетителях

Для нормального функционирования компьютера операционная система, как правило, должна одновременно выполнять различные процессы. Большинство этих «задач» происходит в фоновом режиме, и пользователь о них даже не подозревает. Но действия выполняемых программ все равно регистрируются, поскольку они автоматически ведут протокол в специальных файлах, называемых лог-файлами. В них перечисляются определенные действия и события каждого приложения — например, сообщения об ошибках, изменения настроек, обращения к программе или сообщения о сбоях. Уполномоченные пользователи могут извлекать из них файлы и искать ошибки. Оценивая файлы журнала веб-сервера, вы также можете получить информацию об общем поведении пользователей сайта. Подобный анализ журнала называется анализом файлов журнала.

Что такое анализ журнальных файлов?

Анализ файлов журнала, или сокращенно лог-анализ, относится к процессу целенаправленной проверки и анализа данных журнала. Этот метод позволяет отследить ошибки баз данных и передачи электронной почты или проанализировать деятельность брандмауэра. Чаще всего он используется для оптимизации поисковых систем. Если вы потратите время на анализ журнальных файлов вашего сервера, вы сможете получить полезную информацию о ваших посетителях и их действиях. Просмотр журнала веб-сервера может выявить следующие данные о пользователях:

  • IP-адрес и имя хоста
  • Время доступа
  • Браузер, используемый посетителем
  • Операционная система, используемая посетителем
  • Исходная ссылка или URL
  • Используемая поисковая машина, включая использованные ключевые слова
  • Продолжительность доступа
  • Количество просмотренных страниц
  • Последняя страница, открытая перед уходом с сайта

Поскольку ручной анализ журнальных файлов просто невозможен из-за их большого количества, существуют различные инструменты анализа, которые представляют соответствующую информацию из журналов в визуальной форме. Теперь единственная задача аналитика — сделать правильные выводы из визуализированных данных. Помимо анализа посетителей сайта, журнал веб-сервера также используется для определения технических ошибок (в части сети, приложений или отдельных компонентов) и проблем безопасности, а также автоматического доступа ботов.

Анализ журнала сервера: Типичные проблемы и решения

Самая большая проблема при анализе журналов веб-сервера заключается в том, что HTTP — это протокол без статических данных: Протокол передачи данных, отвечающий за связь между сервером и клиентом, обрабатывает каждый запрос отдельно. Веб-сервер также назначает два разных просмотра страницы одному клиенту — что довольно непрактично для анализа общего поведения пользователя. Существует несколько способов решения этой проблемы:

  1. Присвоение идентификатора сессии: Идентификатор сессии генерируется сервером и хранится в браузере пользователя. Если пользователю присвоен такой идентификационный номер, то все запросы, которые он отправляет на веб-сервер, обрабатываются по этому же номеру. Таким образом, все их действия объединяются в один сеанс. Существует два варианта присвоения идентификационного номера: Один вариант — использование файлов cookie, которые сохраняются, начиная с первого запроса клиента, и затем передаются при каждом последующем обращении к серверу. Куки не видны в лог-файле и поэтому требуют специального программирования, если вы хотите иметь возможность проанализировать их позже. Другой вариант — передавать идентификатор сессии в качестве параметра URL. Но для таких ссылок, ориентированных на конкретного пользователя, требуется больше усилий по программированию. С точки зрения SEO, отдельные URL-адреса могут вызвать проблемы. Один и тот же контент доступен по разным URL при каждом посещении страницы краулером, поэтому его легко можно неправильно истолковать как дублированный контент.
  2. Идентификация пользователя по IP-адресу: Пока все действия пользователя приписываются одному и тому же IP-адресу, его можно однозначно идентифицировать с помощью этого метода. Необходимым условием (по мнению многих экспертов по защите данных) является предварительное согласие пользователя на сбор его IP-адреса для целей анализа. Проблемы возникают, если IP-адрес присваивается посетителям динамически и поэтому учитывается несколько раз, или если несколько пользователей используют один и тот же IP-адрес — например, через прокси-сервер.
  3. Использование независимых от сервера мер: Так называемые пиксели отслеживания — основные элементы тегов страниц — которые заметно встроены в веб-сайт, предоставляют расширенную информацию, такую как разрешение экрана и какие плагины установлены в браузере пользователя. В сочетании с IP-адресом и информацией о браузере и операционной системе можно в определенной степени разграничить пользователей. Стопроцентное разделение пользователей с помощью этого метода невозможно. Но, с помощью пиксельных виджетов или элементов AJAX, отследить можно. При простом анализе лог-файла вы не получите никакой специальной информации о том, как он используется.

Еще одной проблемой при анализе журнальных файлов является функция кэширования веб-браузера или применяемого прокси-сервера. Хотя это очень важно для быстрой доставки запрошенных данных, это также означает, что пользователи не всегда вступают в контакт с веб-сервером. Запросы, касающиеся кэшированного содержимого, появляются лишь в ограниченном виде в файлах журнала сервера (код статуса 304 «Не изменен»). Следует также отметить, что для постоянного протоколирования, хранения и оценки обращений к серверу требуются дополнительные ресурсы — особенно для веб-проектов с большим объемом трафика. Кроме того, анализ журнальных файлов не включает такие важные показатели, как показатель отказов или продолжительность посещений, поэтому его следует использовать только в качестве дополнения к другим инструментам тестирования, а не как единственный метод анализа посетителей.

Анализ журнальных данных — как

Чтобы получить представление о результативности анализа журнала, сначала следует взглянуть на содержание и структуру файла журнала. Например, журнал веб-сервера Apache с именем access.log автоматически создается в каталоге apache.

Информация, предоставляемая журналом Apache

Созданные записи сохраняются в общем формате журнала (также называемом общим форматом журнала NCSA), который имеет заранее определенный синтаксис:

%h %I %u %t "%r" %>s %b

Отдельные компоненты означают следующую информацию

%h IP-адрес клиента
%I Идентификатор клиента, который не определяется по умолчанию, поэтому в этом месте часто встречается минус (-), который указывает на отсутствие записи в файле журнала.
%u Идентификатор пользователя клиента, связанный, например, при защите каталога с HTTP-аутентификацией; обычно не назначается
%t Временная метка времени доступа
%r Информация о HTTP-запросе (метод, запрашиваемый ресурс и версия протокола)
%>s Код состояния, с которым сервер ответил на запрос
%b Переданные данные (в байтах)

Полная запись в журнале access.log выглядит следующим образом:

203.0.113.195 - user [07/Oct/2016:10:43:00 +0200] "GET /index.html HTTP/2.0" 200 2326

В данном случае клиент с IP-адресом 203.0.113.195 и идентификатором пользователя user обратился к файлу index.html в 10:43 7 октября 2016 года с использованием HTTP/2.0. Сервер ответил кодом состояния 200 (Запрос успешен, результат передан) и передал 2326 байт.

В файле httpd.conf вы также можете расширить записи в журнале, добавив в формат журнала два дополнительных компонента: «%{Referer}i» и «%{User-agent}i». Таким образом, вы можете узнать, по какой ссылке или с какой страницы посетители перешли на ваш сайт, а также какая клиентская программа и какая операционная система были использованы. Благодаря последним деталям, комбинированный формат журнала позволяет проверить внешние приложения, получающие данные с вашего веб-сервера, такие как почтовые программы и встроенная графика, а также поисковые машины и спам-боты. Более подробную информацию о свойствах файлов журнала см. в нашей вводной статье по этой теме.

Инструменты, позволяющие анализировать записи журнала

При условии, что у вас есть необходимые права доступа к журналу регистрации вашего веб-сервера, теоретически возможно проверить отдельные обращения клиентов к вашему проекту вручную, без использования дополнительных инструментов. Предположим, однако, что ваш сайт посещают около 1 000 посетителей в день, которые заходят в среднем на десять страниц — каждый день будет создаваться 10 000 новых записей в журнале, и это без учета встроенного контента. Такое количество невозможно оценить вручную. Для анализа журнальных файлов необходимы инструменты, с помощью которых можно экспортировать и сегментировать данные.

Если объем файлов журнала поддается обработке, то для преобразования файла журнала в формат CSV и его импорта можно использовать обычные инструменты обработки данных, например Microsoft Excel, как описано в следующих инструкциях Microsoft. В Excel можно упорядочить информацию о собранных запросах и отсортировать их, например, по IP-адресу, коду состояния или рефереру. Но поскольку существуют ограничения на размер импортированного журнала, результаты анализа журнала в Excel могут дать только моментальный снимок.

Для более долгосрочных исследований вашего трафика на основе журнальных файлов рекомендуется использовать анализатор журнальных файлов. В отличие от программ расчета, эти инструменты были специально разработаны для графического отображения и оценки файлов журналов. В инструментальных панелях, доступ к которым можно получить через обычный браузер, визуально обрабатываются ранее упомянутые цифры кода, взятые из лог-файла — часть из них происходит почти в режиме реального времени, например, с помощью инструмента с открытым исходным кодом GoAccess, о котором мы уже рассказывали.

Анализ лог-файлов и вопрос безопасности данных

Анализ лог-файлов, содержащих информацию о посетителях сайта, всегда затрагивает аспекты защиты данных, причем два аспекта в данном контексте особенно важны. Одним из важных моментов для методов анализа является возможность сохранения всех полученных данных на собственном сервере. Если вы размещаете свой веб-сервер — и связанные с ним файлы журналов — у внешнего провайдера, то вам следует точно знать, какие услуги предоставляются для надежной защиты данных. При использовании таких инструментов отслеживания, как Google Analytics, местоположение сервера для посетителей и данных за пределами США является постоянной проблемой, поскольку вся информация о пользователях хранится на серверах Google, которые в основном расположены в США.

Второй важный момент — это вопрос персонализации в отношении собранных данных анализа журнальных файлов. Если такая информация, как время доступа, посещаемые сайты или используемый браузер, вряд ли предоставляет конкретную персональную информацию о пользователе, то с записью IP-адресов дело обстоит иначе. Особенно в случае статически присвоенных IP-адресов возможность установления прямой персональной ссылки подвергается критике со стороны экспертов по безопасности данных. Определение местоположения по IP-адресу является незаконным в некоторых странах, и веб-мастерам обычно рекомендуют сохранять адреса в анонимной форме и удалять их не более чем через неделю, если только нет какого-либо обязательства сохранять их как форму публичной записи.

Однако если вы хотите изучить файлы журналов, вариант анонимизации невозможен, поскольку вы не сможете объединить для анализа различные действия одного пользователя. Чтобы обезопасить себя, операторы сайтов должны информировать пользователей о записи IP-адресов для целей анализа, поскольку в США в настоящее время нет законов о хранении данных, но суды ЕС подтвердили, что IP-адреса в некоторых случаях действительно могут представлять собой персональные данные.

Анализ лог-файлов сервера: Надежная основа для веб-анализа

Учет данных о пользователях является одним из важнейших способов оценки успешности веб-проекта. Только наблюдая за развитием трафика и регулярным поведением посетителей, вы можете соотнести свои предложения и контент с целевой аудиторией. В отличие от отслеживания с помощью таких инструментов, как Piwik и Google Analytics, анализ лог-файлов основан на стандартных данных, получаемых сервером без помощи JavaScript. Данные могут быть записаны, даже если пользователь блокирует язык сценариев. Но у этого преимущества есть свои небольшие ограничения: Хотя отнесение отдельных обращений к конкретным пользовательским сессиям возможно, это гораздо сложнее, чем при отслеживании cookie, и в журнале анализа будут отсутствовать некоторые показатели, такие как процент отказов или точная продолжительность визита пользователей.

Кэширование клиентских программ также является сложной задачей. Оно позволяет выполнять пользовательские запросы без контакта с сервером, которые лишь в ограниченном виде появляются в журнале веб-сервера, а также динамические IP-адреса, которые не позволяют конкретно отнести различные обращения к отдельным пользователям. Результаты анализа журнала следует понимать прежде всего как просто снимок и, в зависимости от размера вашего веб-проекта, использовать в дополнение к другим методам анализа. Если вы самостоятельно позаботитесь о размещении и оценке лог-файлов и проинформируете своих посетителей о записи IP-адресов и других данных, то у вас будет надежная и соответствующая требованиям данных основа для анализа поведения пользователей. Анализ журналов особенно полезен при попытке увидеть разницу между мобильным и настольным трафиком, а также для обнаружения ботов, таких как Google crawler.

Оцените статью
cdelat.ru
Добавить комментарий