WebClub - Всероссийский Клуб Веб-разработчиков
WebClub.RU » Советы » **Сбор информации

**Сбор информации


Дата публикации: 25-04-2008

На каком участке взаимодействия пользователей и серверов собирать статистические данные? На сервере, на клиенте, на промежуточных участках сети?

Сбор информации на уровне сервера представляет собой отбор информации непосредственно из журналов Web-сервера. Этот способ используется наиболее часто, поскольку без излишних накладных расходов можно получить достаточно полную картину работы пользователей с сервером. Кроме того, это один из немногих методов, для которого уже существуют заранее накопленные данные. Действительно, все или почти все серверы автоматически ведут журнализацию; при этом журналы, как правило, хранятся годами. Рассмотрим детально, какую именно информацию предоставляет журнал сервера, отвечающий требованиям стандарта Common Log Format (CLF).

Большинство современных Web-серверов (в том числе, Apache или IIS) предоставляют возможность администратору выбирать, какие поля должны включаться в журнал, а какие — нет. Самые распространенные из дополнительных полей, которые при добавлении к Common Log Format образуют так называемый Combined Log Format, таковы: обратившееся приложение; URL документа, с которого осуществлено обращение; значения cookies.

У журналов сервера есть и недостатки. Основным из них является неполнота информации. Обращения к сохраненным на каком-либо уровне страницам, например, у пользователя в локальном кэше, не заносятся в журнал сервера, так же в журналы сервера не попадают данные, пересылаемые с помощью метода POST. Альтернативный метод сбора данных на самом сервере — анализ на уровне пакетов. Таким образом можно анализировать на уровне отдельных запросов TCP/IP, но для накопления таких данных, как правило, требуется написание дополнительных программ. На уровне сервера можно собирать данные запросов, полученных через формы на страницах или после выполнения различных сценариев. Достаточно интересным может быть анализ выданных различным пользователям cookie; информация об этом также хранится на сервере.

Заманчиво собирать информацию о посещениях на уровне клиента. Один из способов — использование Java-программ, подгружаемых через страницы интересующего нас сервера; однако функциональность подобных приложений ограничена, кроме того, сам пользователь с помощью настроек своего браузера способен исключить или ограничить возможность подобного сбора информации. Вторым способом могло бы стать внесение изменений в программы для просмотра Сети. Но следует понимать, что вносить в журнал придется все сразу, поскольку если в будущем понадобится собирать данные по какому-либо новому параметру, то внести соответствующие изменения в браузеры всех клиентов будет почти невозможно. Также при таком подходе возникают две неразрешимые проблемы: во-первых, как правило, никто не хочет, чтобы его шаги протоколировались, а затем собранные данные куда-либо отсылались, а во-вторых, мало кто станет обновлять свое программное обеспечение из-за нужд третьей стороны, осуществляющей сбор данных. Таким образом, сбор информации на стороне клиента более любых других методов затрагивает проблему сохранения неприкосновенности личной жизни, и пока такие методики мало применимы. Тем не менее, на данный момент существует несколько систем, использующих подобный подход [3].

Анализ данных прокси-сервера [4] может предоставить информацию о характере просмотра Сети анонимной группы пользователей использующих один прокси-сервер. В случае создания специализированного программного обеспечения для прокси-серверов можно добиться некоторых преимуществ по сравнению со сбором на стороне сервера или клиента. Решается проблема со снижением быстродействия сервера; кроме того, достаточно просто можно осуществить подключение нового сайта к сбору статистики или обновление системы для взаимодействия с новыми версиями браузеров (не требуется обновление приложений клиента).

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

Хорошим примером подобной системы служит Web Traffic Warehouse [5]. Создатели системы обнаружили, что расположение сборщика данных влияет на качество получаемых результатов. Вследствие асинхронного характера передачи данных по Сети входящий и исходящий трафики могут проходить по разным физическим каналам. Просматривая его в некоторой точке сети, можно увидеть только одну из сторон диалога. Чтобы этого избежать, система собирает данные непосредственно на уровне приложений. В будущем планируется использовать большее количество датчиков в сети. Тогда, получая, скажем, данные как от приложения, так и от клиента, можно получать дополнительные параметры (такие, как потеря и задержка пакетов). Кроме того, много коррелированных источников могут использовать для выявления точек потерь или задержек информации.

Коллекционирование всех пакетов позволяет получить подробные данные о сети — дополнительная информация извлекается из журналов приложений (межсетевые экраны, серверы и др.). Информация о состоянии сети может быть получена периодичным просмотром счетчиков непосредственно находящихся на сетевых элементах, имеющих SNMP-доступ к базе Management Information Base. Более детальные данные можно найти в полях данных, которые поддерживаются датчиками RMON, что расширяет возможности хранения данных большинства сетевых элементов. Совмещая множество источников данных, можно получать очень подробную картину.

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

 


Популярное

Не так давно в сети появился новый сервис, под названием Dead Man Zero. Этот сервис сделал...
Рынок социальных площадок уже давно стал стабильным. Несмотря на то, что время от времени...
Artisteer 4 – единственный в своем роде продукт, позволяющий автоматизировать работу над созданием...
Октябрь 2018 (14)
Февраль 2017 (3)
Январь 2017 (1)
Август 2016 (1)
Май 2016 (2)
Ноябрь 2015 (1)

Карта сайта: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41

Друзья сайта



Случайная цитата

Неизвестный автор:

"Решение всех жизненных проблем находится в интернете. Надо только уметь хорошо искать."

Опрос

Какими социальными сетями Вы пользуетесь?

Vkontakte.ru
Одноклассники
Мой Мир - mail.ru
Google Plus
Facebook
ЖЖ
Другие
Не пользуюсь