Файлы журналов iis что это

Возможности журналирования и анализа логов в IIS 8.5

В новой версии Internet Information Services 8.5, представленной в качестве роли веб сервера в Microsoft Windows Server 2012 R2, появилась новая возможность логирования. IIS теперь может писать HTTP-логи в особый журнал трассировки через службу трассировки событий Windows (Event Tracing for Windows — ETW). Благодаря механизму Event Tracing for Windows в IIS 8.5 появилась возможность отслеживать события на веб сервере в реальном времени, что крайне полезно при отладке веб-приложений и поиске неисправностей.

В предыдущих версиях IIS логи веб-сервера записывались в отдельные лог-файлы. Основной недостаток данного механизма – кэширования логов в оперативной памяти. Логи из кэша записываются (сбрасываются) на диск каждую минуты или по достижению объема 64Кб. Это значительно усложняло онлайн-траблшутинг в IIS, т.к. высока вероятность того, что событие, появление которого вы ожидаете, произошло, но информация о нем пока просто не записалась в лог файл, и, соответственно, вы его не сразу не увидите.

В этой статье мы покажем, как в IIS 8.5 задействовать службу трассировки событий Windows (ETW) и как проанализировать полученные логи с помощью Microsoft Message Analyzer.

По умолчанию IIS 8.5 записывает логи в обычные тестовые файлы. Чтобы включить логирование через ETW, нужно в панели управления IIS (Internet Information Services Manager), выбрать имя сервера и в правой панели щелкнуть по значку Logging.

В окне настройки параметров журналирования в разделе Log Event Destination выберете метод ведения журнала, переключившись со стандартного Log file only на ETW event only. Обратите внимание, что можно включить ETW и стандартное журналирование IIS одновременно (Both log file and ETW event). Сохраним изменения. Сразу после этого логи веб сервера IIS начнут писаться через службу трассировки событий Windows.

Для просмотра и анализа логов IIS в журналах ETW воспользуемся бесплатным инструментом Microsoft Message Analyzer, который можно скачать с сайта Microsoft по этой ссылке: _http://www.microsoft.com/en-us/download/details.aspx?id=40308

Во время первого запуска Microsoft Message Analyzer спросит, хотите ли вы обновить элементы на стартовом экране. Выберите желаемое действие.

В открывшемся окне Message Analyzer настроим доступ к логам IIS ETW. Для этого щелкните по ссылке Capture/Trace в левой колонке и укажите имя трассировки.

В разделе Trace Scenario Configuration в поле Add Provider введите IIS и из появившегося выпадающего списка выберите Microsoft-Windows-IIS-Logging.

После того, как мы подключились к нужному провайдеру ETW, можно начать просмотр ( и сбор) событий, нажав кнопку Start With.

Собранные данные будут отображены в виде таблицы (если эта опция была указана при запуске).

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

Для этого в расширенном описании нужного события щелкнем по полю S_sitename и выберем Add Ssitename To Filter (добавить имя сайта в фильтр).

В окне фильтров появится сгенерированный текст кода фильтра. Если нажать кнопку Apply Filter, в окне журнала останутся только данные, которые относятся к указанному нами сайту.

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

Итак, в этом небольшом обзоре мы разобрались с новыми возможностями анализа и поиска неисправностей на веб сервере IIS, с помощью журналирования событий веб-сервера через систему ETW. Также мы показали как можно анализировать полученных данных с помощью Microsoft Message Analyzer.

Источник

Аудит и журналы безопасности

Отслеживание событий сайта

В Windows 2000 имеются журналы шести различных типов. Если вы имеете опыт системного администрирования Windows 2000, то уже знакомы с некоторыми из них. IIS ведет свой собственный отдельный журнал. Ниже приведен полный перечень журналов, работающих на сервере.

Информация журналов событий

Журналы Windows 2000 и IIS можно настроить на запись большого числа различных событий и действий. IIS по умолчанию сохраняет файлы журнала в текстовом формате, их можно просматривать в любом приложении, поддерживающем этот формат. Обычно файлы анализируются посредством их загрузки в программу генерации отчетов, которая осуществляет фильтрацию, сортировку и управление данными. На рисунке приведен пример содержимого файла журнала IIS.

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

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

Аудит

В Windows 2000 и IIS имеется специальная функция по отслеживанию безопасности – аудит, фиксирующая в журнале безопасности события, связанные с ресурсами IIS и Windows 2000 либо с объектами управления системой. Аудит является сложным процессом, использующим средства для анализа собранной информации и диагностики событий сайта, связанных с безопасностью.

Windows 2000 предоставляет три типа возможностей по аудиту объектов и ресурсов, свои функции имеются и в IIS (см. табл. 5.1).

Таблица 5.1. Типы аудита в Windows 2000 и IIS

Тип аудита	Системы, в которых применяется аудит
Система и реестр	Windows 2000 и IIS.
Файловая система	Windows 2000 и IIS.
Учетная запись пользователя	Windows 2000 и IIS.
Посетители домашней страницы	Только IIS.
Авторство	Только IIS.

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

Источник

Анализ проблем в приложениях с использованием журналов IIS

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

Я неоднократно сталкивался с обоими случаями, и было бы неплохо подготовиться к ним как к неизбежности. Методики, описываемые в этой статье, помогут анализировать проблемы в любом приложении или системе, выполняемой в IIS, независимо от платформы, на которой они кодировались. Эти методики помогали мне анализировать приложения и веб-сайты в самых разнообразных ситуациях, особенно на устройствах, отличных от ПК, — этот сценарий становится нормой в наши дни. В одном из последних случаев эти методики помогли мне обнаружить, почему видеоролики не отображались на устройствах Apple, хотя нормально показывались на устройствах с Windows.

Некоторые соображения

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

Ну а если этой информации не достаточно? Вот здесь-то и полезно знание нескольких дополнительных методик. Самая простая из них также является самой быстрой и общеизвестной: выполнение приложения непосредственно на сервере. Иногда серверы не сконфигурированы для такого варианта, но, если вы сможете это сделать, сервер предоставит больше полезной отладочной информации, чем внешний компьютер. Это поведение, очевидно, встроено Microsoft в целях безопасности. Чтобы получить еще больше данных в браузере на сервере, отключите параметр Show friendly HTTP error messages, который вы найдете в Internet Explorer в меню Internet Options | Advanced.

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

Включение протоколирования в IIS

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

Перечисление этих этапов или глубокое описание преимуществ и недостатков каждого из способов выходит за рамки этой статьи. Здесь я просто укажу: чтобы правильно использовать протоколирование для отладки своих приложений, вы должны включать его до возникновения ошибок. Массу полезной информации вы найдете в двух статьях MSDN по Windows Server 2003 и 2012: «How to configure Web site logging in Windows Server 2003» (bit.ly/cbS3xZ) и «Configure Logging in IIS» (bit.ly/18vvSgT). Если они не отвечают вашим потребностям, есть масса других онлайновых статей по включению протоколирования в IIS для других версий Windows Server.

Определение правильного идентификационного номера

Включив протоколирование, вам нужно найти в IIS идентификационный номер (ID number) анализируемого вами веб-сайта. Это крайне важно, поскольку на серверах обычно размещается более одного веб-сайта, и пытаться найти папку журналов вручную может оказаться устрашающей задачей. (Я как-то пытался сделать это на сервере, выполняющем 45 веб-сайтов, и эта задача оказалась практически невозможной.)

Откройте IIS Manager, чтобы отобразить все размещенные веб-сайты. В этом примере допустим, что я пытаюсь выяснить, почему WebSite2 вдруг перестал работать или работает лишь время от времени.

Как видно на рис. 1, ID для WebSite2 равен 3. Следующий шаг — открыть соответствующую папку log, которая обычно (но не всегда) находится в папке Inetpub. Windows, как правило, создает эту папку в корне сервера (C:), но в моем случае папка Inetpub располагается на диске D:. В руководствах рекомендуют разделять диски с операционной системой и кодом для упрощения их замены на случай аварии.

IIS обычно хранит множество файлов в зависимости от того, как вы сконфигурировали историю сервера или как долго идет протоколирование.

Рис. 1. Определение идентификационного номера веб-сайта

Windows именует все папки протоколирования в виде W3SVC#, где # — это ID конкретного веб-сайта. Поскольку ID отлаживаемого сайта в данном случае равен 3, файлы журналов будут размещаться в папке W3SVC3, как показано на рис. 2.

Рис. 2. Открытие папки с файлами журналов

Просмотр файлов

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

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

IIS и Windows пишут индивидуальную строку для каждого HTTP-запроса. Типичная строка выглядит так:

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

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

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

Затем вы увидите IP-адрес, по которому было обращение, тип HTTP-операции (GET) и файл, который запрашивался или к которому было обращение. В следующей строке примера код вызывает файл default.asp:

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

Следующая часть строки показывает IP-адрес — источник запроса, а также принимающий порт:

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

Как видите, указывается и реальный порт. Эта кажущаяся несущественной порция информации жизненно важна при поиске источника проблем. Например, брандмауэр может быть сконфигурирован неправильно. За этими данными идет масса информации, в основном относящаяся к версиям:

Добираемся до сути

До этого момента я показывал сравнительно очевидные части записи в файле журнала. Самое важное, что вы можете видеть, какой браузер реагирует на HTTP-запрос. Иногда этого достаточно, поскольку разные браузеры могут давать разные результаты. Вот фрагмент строк, иллюстрирующих, как в файле отражаются результаты браузеров Firefox и Chrome:

Понять, какой из нескольких HTTP-запросов следует отладить, может оказаться затруднительным, потому что все они выглядят похоже. И здесь может помочь смена браузера. Добавив запись для другого (и неожиданного) браузера, такого как Safari или Opera, вы можете упростить поиск и последующий анализ нужной записи.

Наконец, взгляните на последние четыре элемента в строке:

Последняя цифра, 15, является временем ответа (в миллисекундах) на HTTP-запрос. Это очень полезный фрагмент информации. Зная, сколько времени потребовалось на обработку запроса, вам будет проще решить, соответствует ли это время «нормальному» для данного фрагмента кода, веб-сервиса или процесса.

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

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

Значение этого параметра, вроде бы безобидно выставленное в 30 секунд, было просто слишком велико. Как только его уменьшили, приложение стало работать ожидаемым образом.

Теперь (повторяя одну из предыдущих строк) я сосредоточусь на одном из важнейших параметров из рассматриваемого мной набора. Первый элемент — 200 — это собственно HTTP-ответ от IIS:

Такой HTTP-код ответа, 200, свидетельствует об успехе. Зачастую вы будете встречать известный тип ошибки, например 404 (не найдено) или 500 (внутренняя ошибка сервера), и это может дать вам достаточно информации для выявления и устранения причины проблемы. За официальным списком HTTP-кодов состояния обращайтесь по ссылке bit.ly/17sGpwE.

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

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

Хотя в журналах сообщалось о том, что объект не найден, я отлично знал, что нужные файлы на месте. Это подтолкнуло меня к изучению различий в обработке и хранении файлов в iOS и Windows. Проанализировав исходный код, который загружал видео, я обнаружил, что путь к видеофайлам «зашит» в исходный код и что этот путь не существует для устройств iPad под управлением iOS. Это и было причиной ошибки 404.

Здесь важно отметить, что все симптомы указывали на что угодно, но только не на истинную причину. Например, такая проблема обычно решается проверкой наличия неподдерживаемых media-типов (или Multipurpose Internet Mail Extensions [MIME]) в IIS. Однако, если бы проблема заключалась в отсутствующем MIME-типе, код ошибки был бы HTTP 415 (неподдерживаемый media-тип) или аналогичным, а в журналах об этом не сообщалось. Отладка с применением журналов IIS стала решающим фактором в поиске источника проблемы. Я сэкономил массу времени, увидев истинный код ошибки и исследовав причины его появления; если бы я пошел на поводу того, о чем сообщалось, то потратил бы гораздо больше времени. Еще раз подчеркиваю: знание того, как читать журналы, позволяет успешно решить проблему.

Заключение

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

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

Источник

Ведение журналов

Формат журнала Microsoft IIS

Журнал Microsoft IIS представляет собой неизменяемый файл ASCII, включающий основную информацию о каждой транзакции. Этот формат использует разделители-запятые и поэтому прекрасно импортируется в Microsoft Excel. Поля в журнале являются предопределенными и неизменными, поэтому информация о заголовках не очень важна, в отличие от формата W3C. Для этого формата отсутствует окно расширенных параметров. Пустое поле обозначается дефисом («-«), время фиксируется в местном 24-часовом формате.

Поля журнала Microsoft IIS

Журнал Microsoft IIS включает следующие поля.

Поле	Описание
Client IP Address	IP-адрес компьютера клиента.
User Name	Имя пользователя, используемое клиентом для подключения к серверу; анонимные пользователи обозначаются дефисом («-«).
Date	Дата транзакции.
Time	Время транзакции.
Service and Instance	Номер службы и экземпляр определенного сайта (например, W3SVC1).
Computer Name	Имя NetBIOS сервера (примечательно, что это не DNS-имя).
Server IP-address	IP-адрес сервера.
Time Taken	Время, затраченное на выполнение транзакции.
Bytes Sent	Количество байт, отправленных сервером клиенту.
Bytes Received	Количество байт, отправленных клиентом серверу.
Service Status Code	Сообщение о состоянии протокола (например, «404: HTTP не найден»).
Windows Status Code	Состояние Windows от сервера клиенту (равно нулю при отсутствии ошибок).
Request Type	Метод, используемый клиентом для доступа к серверу (например, HTTP GET).
Target URL	Основная часть URI.
Parameters	Параметры, переданные сценарию.

На рисунке 11.5 показан фрагмент журнала в формате Microsoft IIS.

Общий формат журнала NCSA

Общий формат журнала NCSA представляет собой неизменяемый) ASCII-файл. Он был разработан для HTTP-сервера CERN – самого первого веб-сервера. Данный формат не совместим с FTP-сайтами, тем не менее, его можно использовать на SMTP- и NNTP-сайтах IIS. Журнал NCSA фиксирует основную информацию о транзакции. Поля в журнале разделяются пробелами, пустое поле обозначается дефисом («-«). Время фиксируется в местном 24-часовом формате.

Поля журнала общего формата NCSA

Журнал общего формата NCSA включает следующие поля.

Поле	Описание
Remote hostname or IP address	IP-адрес удаленного пользователя либо имя узла (при наличии DNS), посредством которого обработано имя.
User Name	Имя пользователя при удаленном входе.
Authenticated name	Имя пользователя при аутентификации на сервере.
Date	Дата, время и временной пояс запроса.
Request	Использованные в запросе метод, основная часть URI и протокол.
HTTP status code	Сообщение о состоянии протокола (например, «404: HTTP не найден»).
Bytes transferred	Количество байт, переданных клиентом серверу.

Преобразование журналов в формат NCSA

Утилита convlog поддерживает следующие параметры.

Источник