Анализ проблем в приложениях с использованием журналов 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-запроса. Типичная строка выглядит так:

2013-08-28 00:01:12 128.128.128.20 GET /default.asp - 443 - 200.200.200.17 Mozilla/4.0+(compatible;
+MSIE+8.0; +Windows+NT+6.1; +WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;
+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+InfoPath.3;+MS-RTC+LM+8; +.NET4.0C;+.NET4.0E;
+.NET+CLR+1.1.4322) 200 0 0 15

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

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

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

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

128.128.128.20 GET /default.asp

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

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

443 - 200.200.200.17

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

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

+MSIE+8.0; +Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2; +.NET+CLR+2.0.50727;
+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729; +InfoPath.3;+MS-RTC+LM+8; +.NET4.0C

Например, вы видите разрядность выполняемого браузера (32- или 64-разрядный), версии CLR (для тех, кто столь глубоко ныряет во вселенную .NET) и версию .NET, установленную на сервере (в данном случае, .NET 4C).

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

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

;+rv:17.0)+Gecko/20100101+Firefox/17.0 404 0 2 109
+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/­28.0.1500.95+Safari/537.36 200 0 0 125

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

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

200 0 0 15

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

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

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

<add name="CacheProfile1" duration="30" />

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

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

200 0 0 15

Такой 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 и устранять многие проблемы.