Анализ журналов Web-серверов. Преобразования

Удаление ошибочных записей и преобразование в универсальный формат решает некоторые проблемы при обработке серверных журналов. Однако написание анализирующих программ, которые оперируют строками URL, — весьма утомительное занятие. Для URL допустимо множество форматов, в результате чего один и тот же ресурс в Web может иметь множество представлений. Рассмотрим ресурс foo.html, размещенный на Web-сайте www.xyz.com. Записи в журнале для этого ресурса могут иметь множество различных URL, таких как http://www.xyz.com/foo.html, www.xyz.com/foo.html, foo.html или www.xyz.com///foo.html. Преобразование этого URL к канонической форме требует манипулирования строками для поиска и удаления символов. Такого рода операции обычно довольно утомителыю программировать на таких языках, как С, хотя на языках сценариев это сделать достаточно просто. Наличие отдельной библиотеки процедур для синтаксического анализа и работы со строками может избавить от хлопот, связанных с написанием программ для обработки журналов.

URL может быть приведен к сжатому, каноническому формату путем выполнения операций над строками, имитирующих преобразования, выполняемые Web- сервером при обработке запроса. Например:

•          Удаление "http://" и домениого имени компьютера, если оно присутствует. В противном случае анализирующая программа может не распознать, что http://www.xyz.com/foo.html и foo.html ссылаются на один и тот же ресурс. Имя сервера может иметь псевдоним, это означает, что http://www.xyz.com/ foo.html и http://xyz.com/foo.html относятся к одному и тому же ресурсу.

•          Двойные символы "/" могут быть удалены. Например, /bar//foo.html может быть преобразовано в /bar/foo.html.

•          Могут быть извлечены составные части URL. Например, суффикс URL часто идентифицирует тип содержимого ресурса (например, .html или .gif). Идентификация ресурсов, которые расположены но одному и тому же пути, предусматривает удаление имени ресурса в конце URL; например, /files/bar/foo.html имеет путь /files/bar.

Хотя многие URL могут быть преобразованы указанным образом, в некоторых случаях для этого требуется дополнительная информация о настройках сервера. Например, http://www.xyz.com/bar может ссылаться на ресурс bar или же соответствовать документу http://www.xyz.com/bar/index.htmI, если bar — каталог. Кроме того, сервер может быть настроен таким образом, что один URL трактуется как псевдоним другого URL. Распознать, что два URL соответствуют одному и тому же ресурсу, при отсутствии информации о настройках сервера будег затруднительно. Для обработки доменного имени обратившегося с запросом клиента также полезны операции со строками. Например, извлечение домепа верхнего уровня в доменном имени компьютера пригодится для идентификации запросов, поступивших от образовательных учреждений (например, .edu в users.berkIey.edu).

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

Хэш-таблица храпит целое число, ассоциированное с каждым преобразованным к каноническому виду URL. Для каждой повой записи программа проверяет, существует ли в хэш-таблице приведенный к каноническому виду URL, чтобы определить, какое целое число соответствует этому ресурсу. В противном случае программа ассоциирует новый URL со следующим по порядку целым числом и помещает запись в хэш-таблицу. Для обработки журналов с большим числом различных URL требуется эффективная реализация хэш-габлиц. Достаточно часто встречаются журналы Web-серверов с десятками гысяч уникальных URL, а количество уникальных клиентов может быть еще больше. Хэш-таблицы, созданные с помощью языков сценариев, таких как Perl и ему подобных, обычно требуют много оиера- тивпой памяти. Если потребность в памяти превышает доступный объем, операциоипая система периодически осуществляет свонинг части хэш-таблицы на диск или с диска. Это может привести к значительным задержкам при обработке журпала. Эффективные процедуры хэширования на таких языках, как С или Java, Обычно требуют гораздо меньше памяти, и преобразование данных осуществляется гораздо быстрее.

После преобразования клиентских имеп и URL в целые числа каждая запись состоит из небольшого числа целых чисел. Анализ журналов предполагает последовательный просмотр запросов для вычисления определенных показателей, моделирования определенной стратегии поведения или механизма. В некоторых случаях анализирующая процедура трактует каждого клиента или каждый ресурс независимо. Например, рассмотрим задачу определения интервала времени между последовательными обращениями клиента. Естественный подход заключается в последовательном просмотре журпала по одному запросу за раз и обновлении информации об обратившемся с запросом клиенте. Однако это требует выделения памяти для каждого клиента. Альтернатива состоит в переупорядочении журнала с целью груннировки запросов по клиентам. Переупорядоченный журнал будет содержать все запросы клиента 1, за которыми следуют все запросы клиента 2, и г.д. Сортировка журиала по идентификаторам клиентов намного упрощает задачу подсчета статистических показателей. В то же время, в ряде случаев более полезной может оказаться сортировка по идентификаторам ресурсов.

Сортировка может выполняться но нескольким полям журнала. Например, изучение поведения клиентов может потребовать сортировки заиисей по идентификаторам клиентов с разбивкой по времеии выдачй запроса. Это гарантирует, что полученный в результате журнал будет содержать запросы от каждого из клиентов в порядке поступления запросов. Однако в некоторых случаях несколько занисей могут иметь один и тот же идентификатор клиента и одну и ту же отметку времени. Например, клиент может выдать несколько запросов на загрузку HTML-файла и встроенных изображений. эти запросы поступают близко во времени, возможно, в одну и гу же секунду. Серверные журналы Обычно фиксируют время поступления запроса с точностью до секунды. В неупорядоченном журнале записи, ассоциированные с этими запросами, появляются в том порядке, в котором они были заии- сапы Web-сервером. После проведения сортировки журнал должен сохранять этот порядок. Обеспечить, чтобы процедура упорядочения выполняла такую «стабильную» сортировку, весьма важно для избежания изменений порядка расположения таких записей в журнале.

Предварительная сортировка заиисей позволяет значительно уменьшить сложность анализирующей программы и снизить требования к оперативной памяти. Кроме того, отсортированный журнал может быть использован для различных задач анализа, что позволяет разложить начальные затраты на сортировку на эти задачи. Поскольку сортировка является основной задачей для различных приложений, процедура сортировки должна быть оптимизирована. Во многих ситуациях сортировка ‘данных оказывается более эффективной, чем использование сложной анализирующей программы, написанной «с нуля». Самое важное, что предварительная сортировка данных может уменьшить время, необходимое для написания анализирующей программы, а также облегчить проведение многих экспериментов на ранних этапах анализа данных измерений.

Резюмируя, можно сказать, что анализ больших серверных журналов различных Web-серверов требует решения нескольких проблем, связанных с программным обеспечением. Предварительная обработка данных с целью удаления записей с ошибками, нежелательных нолей, а также преобразование строк в целые числа, существенно уменьшает сложность анализирующего программного обеспечения. Кроме того, сортировка записей журпала по одному или нескольким нолям может значительно облегчить выполнение задач анализа. Программа предварительной обработки и анализа данных может предусматривать эффективную поддержку чтения и записи файлов, работу с регулярными выражениями, преобразование форматов представления времени, хэширование и сортировку. Использование эффективных реализаций этих функций позволяет сэкономить усилия, связанные с разработкой, отладкой и оптимизацией программного обеспечения. Например, в нашей работе по анализу журналов Web-серверов главным образом использовались библиотеки sfio (safe/fast I/O) и libast [KV91, FKV95J, которые позволили написать эффективные и падежные программы на С для предварительной обработки и анализа измеренных данных .

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100