Стратегия управления сервером Web

Чем сложнее становится узел Web, тем более совершенные возможности управления вам требуются.

Ни у кого не вызывает сомнения тот факт, что World Wide Web будет расширяться и дальше. Следовательно, число его пользователей, как и количество узлов, и число критически важных функций будет увеличиваться. По данным International Data Corp., к 2006 году потребность в пропускной способности возрастет на три порядка, а к 2001 году число пользователей WWW удвоится.

Узлы Web становятся все сложнее по мере того, как в стремлении получить свою долю прибыли от роста числа пользователей WWW производители начинают предлагать дополнительные возможности, связанные с электронной коммерцией, доступом к унаследованным данным и с интерактивными библиотеками документов. Ожидания пользователей также продолжают расти, так что посетители вашего узла будут, вполне естественно, рассчитывать на все более высокую производительность и качество. Несколько ошибок типа "Файл не найден" или слишком медленная загрузка страниц, к чему раньше пользователи относились с терпением и пониманием, теперь могут заставить их прервать соединение и больше никогда не возвращаться на ваш узел.

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

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

Управляющий инструментарий для Web по его назначению можно разделить на шесть категорий: создание узла, контроль качества, анализ трафика, контроль производительности, управление пропускной способностью, а также управление документооборотом и контроль версий. Кроме того, целый блок продуктов старшего класса может служить в качестве полноценной платформы для разработки и управления динамическими, коллективно пополняемыми данными и узлами Web (более подробное описание можно найти во врезке "Инструментарий управления Web").

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

СПИСОК ПРИГЛАШЕННЫХ

При создании собственного узла Web вам не обойтись без базовой информации о структуре трафика вашего узла, в частности о том, какие страницы пользуются наибольшим вниманием; сколько человек посещает узел, когда объем трафика максимален и когда минимален; при обращении к каким страницам возникают те или иные ошибки. Если ваш узел используется для организации продаж или маркетинга, то такая информация абсолютно необходима, если вы хотите определить эффективность узла с точки зрения отдачи от инвестиций. Разработчики и менеджеры узла могут также воспользоваться полученными данными, чтобы представить себе структуру трафика и тенденции роста для последующего внесения изменений с учетом развития узла.

Сервер может вести один или несколько журнальных файлов с информацией о транзакциях, которые он выполняет. Наиболее важная с точки зрения управления информация содержится в журналах регистрации доступа и ошибок. Если вы хотите знать, что происходит на вашем узле, то такую информацию можно найти в журнале регистрации доступа, где содержатся записи о каждой завершенной транзакции HTTP (см. врезку "Что такое транзакция HTTP?").

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

Извлечь полезную информацию из файла регистрации доступа позволяет программное обеспечение для анализа содержащихся в нем данных. Большинство коммерческих серверов Web, таких, как Site Server компании Microsoft или Enterprise Server компании Netscape Communications, имеют средства анализа журнальных файлов.

Кроме того, существует несколько десятков относительно недорогих коммерческих инструментальных средств анализа журналов регистрации доступа, в частности WebTrends компании WebTrends (299 долларов) и NetIntellect компании WebManage Technologies (199 долларов). В то же время многочисленные бесплатно распространяемые программы позволяют создавать не менее подробные отчеты, хотя они и не предлагают такой документации и технической поддержки, как их коммерческие аналоги. Один из этих продуктов — wwwstat — создан Роем Филдингом из Калифорнийского университета. Написанный на языке Perl и предназначенный для систем с ОС UNIX, wwwstat генерирует детальные табличные отчеты о состоянии трафика в формате HTML и интегрируется для графического представления трафика узла с еще одной бесплатно распространяемой программой — gwstat.

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

Большинство анализаторов могут сообщать эти данные за указанный день и даже за более короткий промежуток времени. Столь подробная информация позволяет получить представление об общей картине трафика, о периодах пиковой нагрузки, о скорости передачи данных и о файлах, обращение к которым приводит к ошибкам. Таблица 1, созданная программой WebTrends, показывает средний ежедневный трафик, периоды пиковой и минимальной нагрузки.

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

ВАЖНЫЕ ВОПРОСЫ

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

Задайте себе следующие вопросы, касающиеся анализатора журнальных файлов.

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

Может ли он объединить журналы нескольких серверов? При распределении нагрузки между несколькими серверами или при необходимости объединения информации о трафике с нескольких узлов эта возможность позволит измерить трафик всех серверов вашего узла.

Какие методы для обращения к файлам регистрации доступа он поддерживает? К примеру, поддерживает ли он прямое обращение к файлу, HTTP, ftp или комбинацию их трех? Кроме того, может ли он выполнять идентификацию по имени и паролю при удаленном доступе или при доступе через посредника?

Имеет ли он функцию планировщика для предварительного назначения времени генерации отчетов? Если вам необходимо периодически получать отчеты по одному или нескольким узлам, планирование освободит вас от обременительной работы.

Поддерживает ли он генерацию отчетов в реальном времени? Если вам обязательно необходима оперативная информация о трафике узла, эта возможность должна присутствовать.

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

Кроме того, внимание следует обратить и на наличие таких возможностей, как автоматическое преобразование IP-адресов в имена доменов, доставка отчета по электронной почте и вывод отчетов в текстовых (не HTML) форматах, к примеру в виде электронных таблиц или документов текстового процессора.

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

Журнал регистрации ошибок следует периодически просматривать с целью обнаружения неполадок и изъянов в защите. Повторяющиеся неудачные попытки получить доступ к защищенным областям вашего узла могут свидетельствовать о том, что кто-то стремится найти брешь в защите. Кроме того, таким образом вы можете быстро выявить "висячие" ссылки, отсутствующие страницы и перепутанные файлы изображений.

Файлы журналов регистрации ошибок обычно не столь огромны, как журналы регистрации доступа, в силу чего их легко просмотреть в любом текстовом редакторе, не слишком страдая от отсутствия инструментальных средств для анализа.

ПРОВЕРКА ВАШЕЙ ИНФОРМАЦИИ

Любой, кому приходилось создавать или поддерживать информационное наполнение на узле Web, знает, насколько трудно контролировать целостность ресурсов узла. Такие проблемы, как "висячие ссылки", отсутствующие файлы или плохо написанный код HTML, возникают постоянно, если созданием наполнения занимаются несколько авторов, а внутренние и внешние ресурсы постоянно находятся в состоянии изменения.

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

Помочь в данном случае может использование инструментальных средств управления информационным наполнением Web, которые позволяют выявить и исправить некорректные файлы. Как и инструментальные средства анализа журнальных файлов, большинство этих продуктов стоят относительно недорого. К ним, в частности, относятся Linkbot компании Tetranet Software (249 долларов) и SiteSweeper Workstation компании Site Technologies (295 долларов).

Этот инструментарий, также известный как модуль проверки ссылок, обеспечивает контроль качества, поскольку выполняет поиск висячих ссылок, отсутствующих изображений, некачественных программ на HTML и других ошибок на узле Web. Многие из этих продуктов создают графическое представление карты узла, упрощая понимание структуры узла и облегчая поиск файлов и разделов.

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

Инструментальные средства управления информационным наполнением могут предлагать самые разнообразные функции, в том числе поиск висячих ссылок, создание визуального представления узла, обнаружение "осиротелых файлов" (неиспользуемых файлов, на которые нет ссылки ни с одной страницы узла Web), идентификацию медленно загружаемых страниц и, возможно, поиск и исправление некорректных кодов HTML.

Имеющиеся инструментальные средства можно разделить на две основные категории: продукты, предназначенные в первую очередь для составления карт и перемещения по узлу, и продукты, в большей степени ориентированные на генерацию отчетов и исправление ошибок.

НУЖНЫЙ ИНСТРУМЕНТАРИЙ

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

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

Может ли это ПО находить устаревшие файлы? Если ресурсы вашего узла часто изменяются или заменяются, то приобретаемый инструментарий должен уметь проверять и сообщать время последнего сохранения файлов.

Может ли оно выявлять медленно загружаемые страницы? Если вы заботитесь об интересах посетителей, для которых пропускная способность является существенным фактором, то это ПО поможет идентифицировать чрезмерно большие файлы, обращение к которым способно привести к незавершенным транзакциям. Некоторые инструментальные средства позволяют обнаружить проблемные файлы, исходя из заданного порога для минимальной пропускной способности, скажем для модемов это может быть 28,8 Кбит/с.

Какие ошибки оно может обнаружить в коде HTML? Эта возможность позволит изолировать и устранять несоответствия из-за плохо написанного кода. Если для вашего узла это типичная проблема, вы должны выяснить, на каком уровне этот инструментарий позволяет анализировать исходные тексты файлов HTML. Некоторые из наиболее распространенных ошибок — дублирование тегов-заголовков, неполные или отсутствующие заголовки, изображения с пропущенными тегами высоты и ширины.

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

Каким образом оно отображает структуру узла? Если основной интерес вызывает у вас инструментарий для получения графического представления структуры и организации всего узла, то он обязан обладать широкими и интуитивными возможностями отображения.

Каковы возможности масштабирования продукта с ростом узла Web? Если ваш узел уже достаточно велик или быстро растет, то приобретаемый продукт должен быть в состоянии справиться с тысячами документов. Хотя производители могут утверждать, что их продукты обладают достаточной масштабируемостью, несколько таких систем следует протестировать на своем узле прежде, чем решиться на покупку.

Может ли оно поддерживать создаваемое с помощью форм CGI информационное наполнение? Некоторые инструментальные средства позволяют вводить предварительно определенное множество переменных в формы CGI вашего узла, благодаря чему вы можете тестировать и составлять карту динамически генерируемых страниц.

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

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

ВРЕМЯ ПРИШЛО

Количество инструментальных средств управления Web на рынке значительно выросло за относительно короткий промежуток времени. Конкуренция усиливается по мере того, как производители изо всех сил пытаются расширить диапазон предлагаемых продуктов в целях увеличения разнообразия функций управления. Это не может не радовать потребителей, так как в результате они получают широкий выбор решений и инструментальных средств.

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

При условии, что вы понимаете, что в действительности предлагают эти инструментальные средства, в чем их ограничения и насколько хорошо они интегрируются в вашу среду, вы можете извлечь большую пользу уже сегодня.

Инструментарий управления Web

Создатели самых разных продуктов утверждают, что они предлагают инструментальные средства управления Web. Если вы планируете расширить возможности управления своим узлом Web, то прежде всего должны понять, чем инструмент каждого типа управляет и насколько его возможности соответствуют требованиям вашей среды.

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

Интегрированные средства создания информационного наполнения Web. К ним относятся, например, Haht Site компании Haht Software и Fusion компании NetObjects. Эти продукты не только предлагают самые разнообразные функции проектирования и разработки, но и помогают администраторам узлов Web управлять структурой узла благодаря возможностям создания карты узла и функциям визуализации.

Средства анализа трафика. Сюда входят такие продукты, как WebTrends компании WebTrends и net.Analysis Pro компании net.Genesis, задачей которых является детальный анализ журнальных файлов на сервере с целью подготовки развернутых отчетов о трафике и использовании узла.

Модули проверки ссылок и генерации карты узла. Среди продуктов этой категории такие системы, как Astra SiteManager компании Mercury Interactive и Site Sweeper компании Site Technologies. Эти инструментальные средства анализируют информационное наполнение сервера и составляют карту структуры узла, а также сообщают о структурных ошибках, таких, как висячие ссылки.

Мониторы производительности. В эту категорию попадают Webwatcher компании Avesta и WebSniffer компании Network Associates. Подобные утилиты контролируют доступность и производительность сетевых ресурсов. Помимо представления информации о производительности вашей сети они автоматически сообщают о превышении сетевыми службами допустимых параметров.

Менеджеры пропускной способности. Примерами таких продуктов могут служить аппаратная система Web Server Director компании RND Network и программная система Dispatch компании Resonate. Эти модули помогут тем, кто отвечает за сетевую инфраструктуру, управлять пропускной способностью и нагрузкой на сетевые ресурсы. Многие аппаратные, программные и аппаратно-программные решения позволяют распределять трафик Web между несколькими серверами в локальной или распределенной среде. Некоторые из продуктов помогают управлять серверами, а некоторые — информационными ресурсами в среде Web.

Инструментарий управления документооборотом и контроля версий. К этой категории можно отнести Web Integrity компании MKS и BuildIT компании Wallop Software. Они выполняют регистрацию поступления и подготовки файла, а также контроль версий для сложных узлов в групповой среде разработки.

Полнофункциональные системы корпоративной разработки. Примерами таких систем служат StoryServer компании Vignette и DynaBase компании Inso. Продукты этой категории обеспечивают полную базу для создания сложных узлов с соединениями с источниками данных на сервере, групповой средой разработки, электронной коммерцией и так далее.

Что такое транзакция HTTP?

Каждый раз, когда браузер Web обращается к странице на вашем узле, его клиентское программное обеспечение (например, Netscape Navigator) запрашивает все документы, такие, как файл HTML, изображение и мультимедиа, из которых страница, собственно, и состоит. Процесс запроса и доставки этих файлов регулируется протоколом передачи гипертекста (Hypertext Transport Protocol, HTTP). В том случае, если страница содержит дополнительные мультимедийные элементы, такие, как изображения или апплеты Java, каждый компонент передается в браузер в результате отдельного запроса HTTP. Сервер Web записывает информацию о каждой транзакции HTTP в файл регистрации доступа.

Что произойдет, если запрошенная страница не существует, перенесена в другое место или содержит изображения, удаленные с сервера? В этом случае сервер принимает запрос, пытается установить местонахождение ошибочных файлов и, не обнаружив их, посылает в ответ сообщение об ошибке. Невыполненный запрос считается тем не менее транзакцией HTTP, и информация о нем заносится в файл регистрации доступа.

Каждой транзакции HTTP присваивается кодовый номер, который соответствует статусу завершенной транзакции. Каждый, кому приходилось путешествовать по Web, хорошо знаком с гнусным сообщением "404 File Not Found", которое появляется, когда страница не найдена. Кроме кода 404 есть еще десятки других, соответствующих как успешным, так и неуспешным транзакциям HTTP.

Среди наиболее часто встречающихся — такие коды, как 200 (OK), 304 ("Изменений нет"), 401 ("Неавторизованный доступ"), 403 ("Доступ запрещен") и 500 ("Ошибка сервера").

Ресурсы Internet

На этом узле вы можете найти более подробную информацию о HTTP, в том числе спецификации HTTP 2.0, предложенные World Wide Web Consortium по адресу: www.w3.org/Protocols/HTTP/HTTP2.html.

Посетив этот узел, вы можете получить список бесплатно распространяемых, условно бесплатных и коммерческих анализаторов журнальных файлов для самых разных платформ. www.hypernews.org/HyperNews/get/www/log-analyzers.html

Это URL списка ресурсов для администраторов узлов Web, включая, в частности, инструментальные средства управления узлом. Данный список составляется в рамках проекта Федерации американских ученых (Federation of American Scientists, FAS) под названием CyberStrategy Project.
www.fas.org/cp/cybrtool.htm