Работаем с журналами IIS 5.0

Перенос журнала событий Web-сайта на SQL-сервер упрощает анализ данных

По умолчанию файлы журнала событий Web-сервера хранятся на сервере с Microsoft Internet Information Services 5.0. Конечно, функцию накопления данных можно отключить, но, как правило, администратор заинтересован в наиболее полной и подробной информации о работе пользователей своего Web-сайта. Как и IIS 4.0, версия IIS 5.0 позволяет выбрать формат накапливаемых данных и записать их напрямую в базу. Лично я предпочитаю накапливать журнальные данные в файлах в формате World Wide Web Consortium (W3C) Extended Log File Format, после чего импортировать содержимое файлов в базу данных Microsoft SQL Server. Далее я покажу, как задать такой алгоритм накопления данных, и расскажу о небольших отличиях в реализации сбора данных в версиях IIS 4.0 и IIS 5.0.

Регистрация данных в формате W3C

По умолчанию функция сбора данных о событиях Web-сервера включена. Для более тонкой настройки этого процесса используется Internet Ser-vices Manager (ISM) 5.0, во многом подобный Internet Services Manager 4.0. Сам процесс накопления данных изменился мало, к тому же он поддерживает те же он самые форматы файлов данных, что и IIS 4.0:

• W3C Extended Log File Format (exyymmdd.log);
• Microsoft IIS Log File Format (inyymmdd.log);
• National Center for Supercomputing;
• Applications (NCSA) Common Log;
• File Format (ncyymmdd.log);
• ODBC Logging format.

Имена тех файлов, данные в которых накапливаются ежедневно (день за днем), заключены в круглые скобки после собственно данных. В статье Microsoft «W3SVC and IIS Log File Names Are Listed with NCSA Format in HTMLA» (http://support.microsoft.com/support/ kb/articles/q240/0/27.asp) отмечается, что в документации на IIS 5.0 приведен некорректный префикс для имен файлов. Однако в документации, которой пользовался я, все выглядит так, как и должно быть.

Одно из различий между IIS 5.0 и IIS 4.0 состоит в том, что IIS 5.0 поддерживает настройку регистрации ODBC-обращений только для продуктов линии Windows 2000 Server, но не для Windows 2000 Professional.

Я предпочитаю использовать формат W3C Extended Log File Format, поскольку он позволяет собирать больше данных, чем любой другой, а кроме того, я могу указать, какую именно информацию следует собирать. По умолчанию в IIS 5.0 W3C при регистрации событий используется время в формате Universal Time Coordinate (UTC). Термин новый, но «показания» UTC-часов соответствуют временной зоне Greenwich Mean Time (GMT), которая, в свою очередь, используется в IIS 4.0. Версия IIS 5.0 использует UTC-время (не локальное время) компьютера для определения момента создания нового файла, а все упоминания о времени в журнальном файле базируются на UTC. Если серверы компании разбросаны «по странам и континентам», применение UTC может оказаться просто обязательным условием при проведении процедуры синхронизации.

Экран 1. Дополнительные параметры регистрации событий. Вкладка General Properties.

Но если серверы расположены в одном месте, то можно ориентироваться на локальное время. IIS 5.0 предоставляет такую возможность, и процесс именования, и время создания новых файлов будут определяться на основе показаний локальных часов. Откройте ISM, укажите сервер, раскройте контекстное меню Web-сайта и выберите Properties. Затем нужно щелкнуть на вкладке Web Site, убедиться, что выбран формат данных W3C, и щелкнуть Properties. На вкладке General Properties (см. Экран 1) требуется установить флажок Use local time for file naming and rollover. Если используется версия IIS 4.0 Service Pack 4 (SP4) или более поздняя, локальное время тоже можно задействовать, но для этого придется редактировать реестр.

Экран 2. Дополнительные параметры регистрации событий. Вкладка Extended Properties.

На Экране 2 показано окно, используемое для настройки дополнительных параметров регистрации событий в формате W3C. Обратите внимание, что IIS 5.0 использует для этого представление параметров в виде дерева, а не списка, как это было в IIS 4.0. Кроме того, в IIS 5.0 в скобках в конце выбранного параметра регистрации указывается имя параметра в том виде, в каком оно будет записано в журнальном файле. Это на самом деле очень удобно, когда приходится сопоставлять содержимое файла и те параметры, которые хотелось бы регистрировать.

За редким исключением, дополнительные параметры регистрации IIS 5.0 и IIS 4.0 почти полностью совпадают. Характеристика HTTP Status в IIS 4.0 в версии IIS 5.0 названа Protocol Status, хотя в документации на IIS 5.0 она именуется по-старому - HTTP Status. Host property - новый параметр, появившийся в IIS 5.0; он содержит имя сервера. Если активизировать Process Accounting для IIS 5.0, то Web-сервер станет регистрировать дополнительный набор записей W3C.

Кто обращался к разделу Logging Properties Reference, тот, наверное, заметил, что оперативная документация по IIS 5.0 может ввести в заблуждение. Я воспроизвожу часть этой документации, взяв на себя смелость исправить некоторые ошибки и изменить заголовки колонок, чтобы таблицы стали более понятными. В Таблице 1 описаны префиксы для имен W3C-параметров так, как они выглядят в журнальных файлах. Каждый префикс сопровождается описанием действия, с которым он непосредственно связан. В Таблице 2 даны параметры W3C и информация, относящаяся к Protocol Status. В Таблице 3 показаны новые W3C-параметры при активизированном процессе Process Accoun-ting, и, наконец, в Таблице 4 описываются значения параметра Process Event для Process Accounting.

Экран 3. Заголовок W3C-файла.

Всякий раз, когда IIS 5.0 создает журнальный файл W3C, в начало файла помещается заголовок наподобие того, что изображен на Экране 3. Первая строка заголовка указывает на тип сервера, вторая - на версию журнального файла, третья - на дату и время создания самого файла, и, наконец, последняя строка представляет собой разделитель из пробелов, отделяющий заголовок от собственно данных, представленных в файле в виде таблицы. Причем если поле в журнальном файле изменить, IIS 5.0 «поставит» новый «штамп» в его заголовок, после чего накопление данных продолжится с учетом внесенных изменений. Если впоследствии журнальный файл импортируется в базу данных, следует убедиться, что все новые поля успешно в ней размещены.

Импорт файла в SQL-сервер

Если требуется организовать анализ журнальных данных, нужно импортировать содержимое файла событий в базу данных и написать соответствующие запросы. Для работы непосредственно с журнальными данными в том виде, в каком они создаются сервером IIS 5.0, также имеется несколько конфигурационных параметров. Вместо W3C, можно выбрать ODBC-формат представления событий и записать данные непосредственно в базу SQL или другую базу, поддерживающую ODBC. Однако такой подход, когда запись выполняется всякий раз при возникновении того или иного события, приводит к очень интенсивному использованию ресурсов системы, поэтому я предпочитаю для загрузки в базу файлов W3C применять службу Data Transformation Services (DTS). DTS читает данные из текстового файла, созданного IIS 5.0, и затем импортирует их в SQL-сервер. Поскольку DTS запускается только после того, как IIS 5.0 закроет журнальный файл, обновление базы можно выполнять в пакетном режиме. В этом случае нагрузка на серверы SQL и IIS 5.0 меньше, чем при записи обновлений в оперативном режиме.

Как обычно при использовании DTS, для импорта данных из W3C в базу данных SQL следует создать задачу (task) на SQL-сервере, которая будет выполнять несколько работ (job). Можно составить расписание для IIS 5.0 таким образом, чтобы закрывать журнальный файл в определенное время суток и запускать DTS-задачу сразу после того, как файл будет закрыт. Первым делом нужно будет скопировать закрытый журнальный файл во входной набор для импорта или просто переименовать журнальный файл.

Экран 4. Первые две строчки входного файла.

Далее, созданная задача должна выделить заголовок из входного файла, удалив целиком первые три строки заголовка, а также подстроку «#Fields:» из четвертой строки заголовка. Теперь файл содержит только одну строку в заголовочной части, и в ней указано имя каждого поля. На Экране 4 показаны первые две строки - строка заголовка и одна строка данных для журнального файла, содержащего шесть полей. Последнее, что должна сделать DTS-задача, - запустить DTS-процедуру (DTS package) загрузки данных из входного файла в базу данных.

Но прежде следует создать саму базу и DTS-процедуру. Можно поручить самой DTS-процедуре позаботиться об этом, однако я рекомендую создать базу самостоятельно. Это позволит указать колонки, корректно описав тип соответствующих данных и тем самым упростив запросы на обработку самих данных. Кроме того, можно будет именовать колонки по своему усмотрению и, используя DTS, установить отображение пространства имен полей во входном файле и колонок в базе данных. В моем случае была создана база данных SQL Server 2000 с именем Iislogs. В Листинге 1 приведена спецификация Data Defi-nition Language (DDL), в соответствии с которой в базе была сформирована таблица Inlogdata.

Чтобы создать DTS-процедуру, я запустил SQL Server 2000 Enterprise Manager, раскрыл Data Transformation Services, обратился в контекстное меню Local Packages и выбрал New Package. Открылся DTS Designer. Затем, щелкнув Connection в верхней части панели инструментов, я выбрал тип соединения Text File и с помощью стандартного окна проводника указал входной файл с журнальными данными. Далее я щелкнул кнопку Proper-ties - открылось окно с описанием свойств соединения. На первой странице с помощью кнопки Delimited я установил флажок First row has column names, а остальные параметры оставил без изменений.

Кнопка Next позволяет перейти на вторую страницу свойств соединения, на которой я выбрал переключатель Other и ввел символ пробела в качестве разделителя колонок для DTS-процедуры. В этот момент в нижней части окна свойств можно увидеть правильное описание колонок будущей таблицы. Теперь нужно щелкнуть Finish и OK, чтобы закрыть окно Properties.

Затем я добавил второе соединение. В качестве Data Source я указал Microsoft OLE DB Provider for SQL Server и выбрал из предложенного списка свой сервер SQL, после чего ввел имя и пароль для доступа к базе данных. Была выбрана база Iislogs.

В заключение я «перетащил» задачу Transform Data из панели инструментов (в левой части окна) и выбрал первое из созданных соединений в качестве источника данных, а второе - назначения данных. Сохраняем процедуру. Щелчок по кнопке Execute инициирует немедленное ее выполнение. На Экране 5 показан Enterprise Manager с перенесенными в базу данных данными из журнала.

Рисунок 5. Enterprise Manager с перенесенными в БД данными.

Анализ данных

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

select * from inlogdata

Можно выбрать журнальные данные, относящиеся к конкретному серверу:

select * from inlogdata
	order by `s-computername`

Не нужно быть экспертом в области SQL или баз данных, чтобы воспользоваться данными SQL-сервера. Для формирования запросов и последующего анализа данных можно воспользоваться такими программами, как Microsoft Excel, Microsoft Access или Seagate Crystal Reports.

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

net helpmsg 5

и видим на экране текст сообщения об ошибке: «Access is denied.»

В статье Microsoft «IIS `Bytes Sent` (Sc-bytes) Logging Property Is 0 for ASP Files» http://support.microsoft.com/support/ kb/articles/q254/7/18.asp) отмечается, что поле Bytes Sent (W3C-формат) может вернуть 0, когда для приложения Active Server Pages (ASP) включена буферизация данных. Эту функцию рекомендуется отключить, тогда В Bytes Sent будет возвращать корректные данные, правда, за счет заметного снижения производительности самого приложения.

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

Можно также воспользоваться такими программами, как Commerce Server 2000 Business Analytics. Другой вариант - приобрести программный пакет для анализа данных журналов регистрации. Например, в составе WebTrends Log Analyzer уже имеются отчеты, которыми можно воспользоваться для анализа происходящих на сайте событий.

И наконец, можно совсем отключить сбор журнальных данных и написать Internet Server API (ISAPI) - фильтры для перехвата данных из заголовков пакетов HTTP. Другими словами, имеется большой выбор возможностей для сбора и анализа информации о работе Web-сайта.

КЕН СПЕНСЕР работает в учебном центре 32X Tech, который проводит семинары по предлагаемым корпорацией Microsoft технологиям разработки и SQL Server. C ним можно связаться по адресу: kenspencer@32x.com.

назад

назад

назад

назад

Листинг 1. Cпецификация DDL для таблицы Inlogdata.

CREATE TABLE [dbo].[InLogdata]
	[time] [varchar] (255) ,
	[c-ip] [varchar] (255) ,
	[cs-username] [varchar] (255) ,
	[s-sitename] [varchar] (255) ,
	[s-computername] [varchar] (255) ,
	[s-ip] [varchar] (255) ,
	[s-port] [varchar] (255) ,
	[cs-method] [varchar] (255) ,
	[cs-uri-stem] [varchar] (255) ,
	[cs-uri-query] [varchar] (255) ,
	[sc-status] [varchar] (255) ,
	[sc-win32-status] [varchar] (255) ,
	[sc-bytes] [varchar] (255) ,
	[cs-bytes] [varchar] (255) ,
	[time-taken] [varchar] (255) ,
	[cs-version] [varchar] (255) ,
	[cs-host] [varchar] (255) ,
	[cs(User-Agent)] [varchar] (255) ,
	[cs(Cookie)] [varchar] (255) ,
	[cs(Referer)] [varchar] (255) ,
	[Col021] [varchar] (255)
) ON [PRIMARY]
GO