Iis о ведении журналов узлов


Содержание

Где я могу найти журналы IIS?

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

Итак, мой вопрос: где IIS7 хранит журналы по умолчанию?

Я думаю, что место для журналов доступа по умолчанию —

В противном случае установите флажок в диспетчере IIS, выберите компьютер на левой панели и в средней панели, перейдите в раздел «Регистрация» в области IIS. Там вы найдете местоположение по умолчанию для всех сайтов (это, однако, возможно на всех сайтах)

Вы также можете посмотреть

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

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

Перейдите на ваш сайт IIS, например. Default, щелкните по нему, и вы увидите «Logging» вправо, если включено ведение журнала:

Откройте его, и вы увидите папку прямо там:

Я добавляю этот ответ, потому что после изучения Интернета я оказался в этом ответе, но до сих пор не знал, какую вложенную папку в папке журналов IIS можно посмотреть.

Если ваш сервер имеет несколько веб-сайтов, вам необходимо знать идентификатор IIS для сайта. Простой способ получить это в IIS — это просто щелкнуть папку «Сайты» на левой панели. Идентификатор для каждого сайта отображается на правой панели.

Как только вы узнаете идентификатор, позвоните ему н, соответствующие журналы находятся в подпапке W3SVCn в папке журналов IIS. Итак, если ваш идентификатор сайта равен 4, скажем, и журналы IIS находятся в местоположении по умолчанию, то журналы находятся в этой папке:

  • Ответ @jishi сообщает, где по умолчанию журналы.
  • Ответа на этот вопрос @Rafid объясняет, как найти фактическое местоположение (возможно, не по умолчанию).
  • Ответа на этот вопрос @Bergius дает программный способ найти местоположение папки журнала для определенного веб-сайта с учетом ID без использования IIS.

Iis о ведении журналов узлов

Работа с web-узлами.

Рассмотрим более подробно различные административные задачи уровня узла, которые можно выполнять в IIS. Мы уже кратко рассматривали диалоговое окно основных свойств для службы WWW, и вы уже знаете, что в нем имеется десять вкладок, содержащих разнообразные настройки, которые можно конфигурировать. Девять из этих десяти вкладок применяются также и на уровне узла (для администрирования отдельных web-узлов); в данном разделе мы подробно изучим эти разнообразные вкладки и их настройки. В качестве примера в данной главе мы будем конфигурировать Веб-узел по умолчанию.

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

Каждый web-узел, размещенный на компьютере IIS, должен иметь уникальную идентификацию, чтобы клиенты-браузеры могли соединяться с ним и скачивать с него содержимое. Web-узлы можно определять при помощи трех разных параметров: IP-адреса, номера порта TCP и имени заголовка хоста.
Идентификация web-узла задается в странице окна свойств этого web-узла с вкладкой Веб-узел. Чтобы web-узлы на одном компьютере имели уникальные идентификации, они должны отличаться друг от друга хотя бы одним из трех параметров идентификации. Рассмотрим разные способы задания идентификации web-узла и обсудим, как можно иметь несколько разных web-узлов на одном сервере.

Настройка нескольких IP-адресов для одной сетевой платы сервера

Вы можете сконфигурировать несколько IP-адресов для одной сетевой платы сервера или установить несколько сетевых плат, чтобы у каждой платы был свой IP-адрес. Выберите разные IP-адреса для каждого из web-узлов. Не меняйте у этих сайтов настройку порта TCP (80 — это стандартная для протокола HTTP настройка порта TCP) и не конфигурируйте имена заголовка хоста. Достоинством этого способа является то, что клиентам удобно соединяться с каждым из сайтов при помощи IP-адреса сайта в запрашиваемом ими URL (или при помощи полностью квалифицированного DNS-имени, если на сервере DNS было сконфигурировано уникальное имя хоста для каждого из IP-адресов компьютера IIS).
К недостаткам этого способа относится то, что если на компьютере содержать много web-узлов, то им придется назначать много IP-адресов. Это не проблема для приватных интрасетей, использующих один из блоков приватных IP-адресов, таких как 10.y.z.w, 172.16-31.z.z, 192.168.z.z. Но на серверах, непосредственно подключенных к Интернету, вам придется получать нужное количество IP-адресов у вашего провайдера. Тем не менее, данный способ задания идентификации web-узла является наиболее употребительным.

Настройка только одного IP-адреса для сетевой платы

Задайте разные порты TCP (с номерами, большими 1023) для каждого из web-узлов, с которыми надо соединяться. Главный недостаток этого способа — то, что клиенты должны знать номера портов web-узлов, с которыми им надо соединяться. Например, если DNS-имя сервера — Win2003s.test.fio.ru, а web-узлу на этом сервере присвоен номер порта 8023, то клиенту для доступа к этому сайту придется использовать URL http://Win2003s.test.fio.ru:8023.

Настройка одного IP-адреса с сохранением стандартного порта TCP

При этом способе конфигурируется только один IP-адрес для сетевой платы сервера, а порт TCP остается со стандартным значением (80) для всех сайтов. Сконфигурируйте уникальное имя заголовка хоста для каждого сайта при помощи кнопки Дополнительно. Имена заголовков хоста возможны в протоколе HTTP 1.1. Имя заголовка хоста, сопоставляемое каждому из узлов, является типичным полностью квалифицированным DNS-именем, присвоенным узлу в базе данных доступного сервера DNS (или в локальном файле Hosts на клиентах).

Когда вы открываете окно свойств для Веб-узел по умолчанию и страницу с вкладкой Веб-сайт, то IP-адрес задан как Все неназначенные. Это означает, что web-узел будет отвечать на любой IP-адpec, не назначенный специально другим web-узлам изданном компьютере. Именно поэтому данный сайт является используемым по умолчанию и единственным web-узлом на компьютере IIS, для которого возможен такой способ задания IP-адреса.

Когда клиент запрашивает URL вроде http://vio.fio.ru , клиент передает имя заголовка хоста vio.fio.ru в заголовки запроса HTTP, передаваемые серверу. Сервер производит синтаксический разбор имени заголовка хоста, идентифицирует web-узел, с которым должен соединиться клиент, и возвращает файлы, соответствующие запросу. Недостатком этого способа является то, что клиент тоже должен поддерживать имена заголовков хоста, то есть должен уметь передавать DNS сайта в своих заголовках запроса HTTP. Имена заголовков хостов поддерживаются браузерами Microsoft Internet Explorer версий, начиная от 3 и выше. Другим недостатком использования имен заголовков хостов является то, что данный способ не работает в сочетании с соединениями SSL, потому что в этом случае сеансы HTTP подвергаются шифрованию.

Если вы работаете со старыми браузерами, не поддерживающими имена заголовков хоста, то можете реализовать механизм, основанный на cookie-файлах, позволяющий браузерам различать web-узлы, имеющие одинаковые IP-адреса и номера порта TCP. Дополнительную информацию об этом можно найти в онлайновой документации.

При изменении номера порта для web-узла не требуется перезагрузка сервера, чтобы изменения вступили в силу.

Страница с вкладкой Веб-узел позволяет конфигурировать для сеансов HTTP ограничение на максимальное количество действующих одновременно соединений TCP с сервером. Вы также можете включить или отключить настройку сохранения соединений (HTTP Keep-Alives) и задать значения предельного срока сохранения для соединений (connection timeout value). Настройка HTTP Keep-Alives является средством HTTP 1.1, при помощи которого клиент может сохранять открытым соединение TCP с сервером и после скачивания файла, если с этого сервера требуется скачать еще какие-либо другие файлы. Если же клиенты начнут страдать из-за замедления работы сервера или станут часто получать сообщение об ошибке «загруженности»

HTTP 500: Busy errors

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

Время ожидания, задаваемое на вкладке Веб-узел, применяется к активным сеансам TCP. В TCP имеются свои собственные настройки для завершения наполовину открытых соединений TCP, вроде тех, что создаются во время DoS-атак (Denial of Service, отказ в обслуживании), когда злоумышленники пытаются «завалить» web-сервер, переполнив его сетевое соединение пакетами TCP SYN.

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

  • Общий формат файла журнала NCSA. Создает файл в кодировке ASCII с разделителями-пробелами с предопределенным набором полей.
  • Ведение журнала ODBC. Фиксированный формат ведения журнала в базе данных.
  • Расширенный формат файла журнала W3C. Это настраиваемый формат журнала используется по умолчанию; создается ASCII-файл с разделителями-пробелами, причем набор полей определяется администратором.
  • Формат файла журнала Microsoft IIS. Создается файл фиксированного формата в кодировке ASCII.

Новые регистрационные файлы IIS могут создаваться ежечасно, ежедневно, раз в неделю или раз в месяц, либо когда существующий регистрационный файл дорастает до некоторого заданного размера. По умолчанию файлы журнала хранятся в папке \%systemroot%\System32\LogFiles, но вы можете изменить эту настройку при помощи кнопки Обзор.

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

Вкладка Дополнительно позволяет настроить расширенные параметры журнала.

Настройка производительности отдельных web-узлов выполняется на странице с вкладкой Быстродействие окна свойств сайта.

В этой странице вы можете конфигурировать следующие настройки:

  • Ограничение пропускной способности. Вы можете включить и задать предел пропускной способности данного сайта в разделе Регулировка полосы пропускания. Это позволит установить приоритет доступа к определенным сайтам, расположенным на одном сервере.
  • Количество соединений с веб-сайтами. Вы можете ограничить общее количество одновременных подключений к веб-сайту. Для этого установите переключатель в положение не более и задайте значение, соответствующее количеству соединений.

Вкладка Фильтры ISAPI.

Фильтры ISAPI (Internet Server Application Programming Interface) являются дополнительными динамическими DLL-библиотеками, выполняющими специфические действия при обработке клиентских запросов HTTP службой IIS. При этой вкладки вы можете задать набор фильтров ISAPI и последовательность их обработки службой IIS. Фильтры, установленные на уровне web-узла, применяются только для выбранного web-узла. Фильтры, установленные на уровне сервера, применяются ко всем web-узлам сервера.

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

Вкладка Домашний каталог.

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

Домашний каталог сайта задает местоположение содержимого, доступ к которому происходит при помощи URL вида

где Имя_сайта является именем NetBIOS, IP-адресом или DNS-именем сайта, а Имя_файла — именем какой-либо страницы HTML, или файла с рисунком, или скрипта, или какого-нибудь другого файла из домашнего каталога сайта.

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

  • Как имя каталога, находящегося на локальном диске компьютера (положение Каталог данного компьютера).
  • Как UNC-путь к сетевому разделяемому ресурсу на файловом сервере (положение Общая папка другого компьютера).
  • Как перенаправление к URL, предлагающее клиенту, желающему получить доступ к содержимому, сопоставленному домашнему каталогу, соединиться с другим web-сервером, не обязательно сервером IIS (положение Постоянный адрес URL). Перенаправление может быть как временным, так и постоянным.

Возможность перенаправлять доступ для домашнего каталога (или для любого виртуального каталога) к URL полезна, когда web-узел находится в процессе создания или когда он выключен из-за технического обслуживания или из-за обновления. IIS позволяет перенаправлять запрос к любому из файлов в домашнем каталоге к одному и тому же URL (например, к странице с объявлением «Идет техническое обслуживание. Сайт будет доступен через 15 минут») или к такому же файлу в сетевом каталоге (так можно перенаправлять клиентов к временному сайту-зеркалу). Можно также перенаправлять доступ к подкаталогу текущего домашнего каталога, если страница с объявлением о техобслуживании или зеркальное содержимое находятся на том же самом сервере.

Постоянное перенаправление задавайте, только когда вы действительно планируете переместить содержимое сайта на другой сервер, т.к. некоторые браузеры, получив сообщение «Постоянное перенаправление»

HTTP 301 Permanent Redirect

могут действительно поменять ссылки в «Избранном» или в «Закладках». В результате, когда вы выключите перенаправление, клиенты все равно будут обращаться не к первоначальному, а к альтернативному сайту.

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

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

  • Доступ к тексту сценария. При установленном флажке пользователи могут получить доступ к исходному тексту скриптов (например, к ASP-файлам). Обратите внимание, что если вы не включите настройку Чтение или Запись, то данная настройка не будет иметь никакого действия. (При включении настройки Чтение пользователи смогут читать исходные тексты скриптов, а при включении настройки Запись — изменять скрипты.) Настройка Доступ к тексту сценария включается обычно при проектировании серверов, в которых создается содержимое. По умолчанию она выключена.
  • Чтение. Если установить этот флажок, пользователи смогут видеть содержимое каталога или файла и его свойства, такие как время создания и размер файла. По умолчанию настройка включена.
  • Запись. Если установить этот флажок, пользователи смогут изменять содержимое каталога или файла. Запись на сервер могут производить лишь те браузеры, которые поддерживают команду PUT (Поместить) протокола HTTP 1.1 (к ним относится Internet Explorer начиная с версии 4). По умолчанию настройка выключена.
  • Обзор каталогов. Если установить этот флажок, пользователи смогут видеть содержимое домашнего каталога в случаях, когда в ней нет принятой по умолчанию домашней страницы. Обычно эту настройку следует выключать (по умолчанию она выключена), чтобы скрыть структуру каталогов с содержимым от случайного просмотра пользователями, желающими войти туда, куда вы их пускать не желаете.
  • Запись в журнал. Если установить этот флажок, то, при каждом доступе клиента к любому из файлов в домашнем каталоге, в регистрационный файл будет добавляться запись. Заметьте, что, прежде чем эта настройка начнет работать, нужно установить флажок Вести журнал на странице с вкладкой Веб-узел. По умолчанию регистрация посещений домашнего каталога включена.
  • Индексация каталога. При установленном флажке Служба индексирования добавляет содержимое домашнего каталога к главному индексу. По умолчанию Служба индексирования устанавливается во время установки Windows Server 2003.

Хотя полномочие Чтение и устанавливается для Веб-узла по умолчанию, но возможность доступа к содержимому конкретного web-узла зависит от множества условий.

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

В качестве примера web-приложения можно привести набор ASP, работающих совместно и предоставляющих алгоритмические возможности для посетителей сайта. Настройки, которые вы можете pзадавать в области Параметры приложения:

  • Поле ввода Имя приложения. В поле задается уникальное имя приложения.
  • Исходная папка. Приложение может состоять из дерева каталогов и их содержимого. Вершина этого дерева и есть начальная точка приложения.
  • Разрешен запуск. При помощи этой настройки вы можете задать типы приложений, которые можно запускать в домашнем каталоге. Можно выбрать Ничего, Только сценарии или Сценарии и исполняемые файлы.
  • Группа приложений. Эта настройка позволяет вам выбрать группу приложений, связанных с данной домашней папкой.
  • Кнопка Настройка. Если нажать на эту кнопку, то откроется диалоговое окно Настройка приложения, в котором можно сконфигурировать опции для сопоставления приложения интерпретирующим его машинам скриптов или программам, для копирования приложений ISAPI (с целью повышения производительности); для задания сроков сеансов; для задания используемого по умолчанию языка скриптов ASP, для настроек отладки.

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

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

По умолчанию задаются четыре файла в следующем порядке: Default.htm, Default.asp, index.htm и iisstart.htm. Например, если браузер пытается соединиться с Веб-узлом по умолчанию на сервере Win2003s.test.fio.ru при помощи URL http://Win2003s.test.fio.ru, то сервер сначала проверит, имеется ли в домашнем каталоге файл Default.htm. Если там есть такой файл, то он будет возвращен клиенту. Если такого файла нет, то сервер будет искать файл Default.asp. Этот процесс будет продолжаться до тех пор, пока не найдется файл или пока не закончится список документов, используемых по умолчанию. Вы можете задать дополнительные стандартные документы (например, Index.html) или убрать документы, уже имеющиеся в списке. Можно и вовсе отменить обращения к стандартным документам, в этом случае клиенты должны знать и указывать фактическое имя файла, к которому они хотят получить доступ на сервере, задавая, например, такие URL: http://Win2003s.test.fio.ru/NoDefault.htm.

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

Что такое «Файлы журналов IIS» и можно ли их удалить?

Программа CCleaner предлагает это сделать.

Что будет, если удалить их?

Файлы журналов IIS — отчётность о деятельности службы веб-сервера IIS (Internet Information Service). В эти файлы служба пишет о своей активности, типа блога. Пишет о запрошенных файлах (картинках, страницах html), об ошибках, когда файлы отсутствуют и прочее. Эти журналы могут быть основой для сбора статистики об активности веб-сервера.

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

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

Посетителей: 1687 | Просмотров: 1948 (сегодня 0) Шрифт:

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

Я неоднократно сталкивался с обоими случаями, и было бы неплохо подготовиться к ним как к неизбежности. Методики, описываемые в этой статье, помогут анализировать проблемы в любом приложении или системе, выполняемой в 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-адрес — источник запроса, а также принимающий порт:

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

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

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

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

До этого момента я показывал сравнительно очевидные части записи в файле журнала. Самое важное, что вы можете видеть, какой браузер реагирует на 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 и устранять многие проблемы.

Iis о ведении журналов узлов

4181 просмотра

2 ответа

411 Репутация автора

Я унаследовал классический проект ASP и развернул его на IIS 7.5. Я могу получить доступ к сайту, однако в определенный момент я получаю общую страницу ошибок 500. Я хочу знать, что происходит, поэтому я считаю, что лучше всего посмотреть журналы

  • Не нашли ничего в c: \ WINDOWS \ system32 \ LogFiles \ nor c: \ inetpub \ logs \
  • Попробовал включить ведение журнала, как здесь: https://technet.microsoft.com/en-us/library/cc732826(v=ws.10).aspx Но у меня нет значка / кнопки ведения журнала (см. Снимок экрана).
  • Запрашивает пользовательскую ошибку 500, как здесь: http://www.iis.net/configreference/system.webserver/httperrors/error, но нет значка «Страницы ошибок» (см. Снимок экрана)
  • Пытался настроить пользовательскую страницу 500 с помощью web.config, как здесь: http://blogs.iis.net/rickbarber/archive/2013/02/18/working-past-500-internal-server-error.aspx, но кажется, что он получает игнорируются

Для записи я новичок с IIS / ASP, поэтому вопрос может звучать немного глупо. Спасибо за любое предложение!

Ответы (2)

1 плюс

1305 Репутация автора

Это приведет к записи информации об ошибке на экран. Измените раздел «If blnLogFailure», если вы хотите записать в файл.

Автор: Jen R Размещён: 12.03.2015 05:10

8 плюса

15097 Репутация автора

Вы должны установить функцию «Ошибки HTTP» в IIS . Этого достаточно, чтобы просмотреть сообщение об ошибке — вам не потребуется вести журнал.

Чтобы установить ошибки HTTP:

  1. Перейдите в панель управления «Программы и компоненты».
  2. Выберите «Включить или отключить функции Windows»
  3. Перейдите к Internet Information Services> Широкоформатные веб-службы Windows> Общие функции HTTP и выберите «Ошибки HTTP» (в то время как вы на нем, вы можете установить функцию ведения журнала путем сверления в Internet Information Services> Широкоформатные веб-службы> Диагностика и выбор «HTTP Logging».)
  4. Нажмите «ОК» для установки.

После установки настройте IIS для отображения подробных сообщений об ошибках:

  1. В настройках IIS для вашего сайта вы должны увидеть параметр «Страницы ошибок». Дважды щелкните по нему.
  2. Нажмите «Изменить настройки параметров».
  3. Выберите «Подробные ошибки» или «Подробные ошибки для локальных запросов . » в зависимости от того, выполняете ли вы локальную разработку или нет.
  4. В настройках IIS для вашего сайта дважды щелкните параметр ASP.
  5. Разверните «Отладка свойств» и установите «Отправить ошибки для браузера» в значение true.

Теперь вы должны увидеть подробные сообщения об ошибках.

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

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

IIS (Internet Information Services)

Internet Information Services
Разработчики: Microsoft
Постоянный выпуск: 10 / 29 July 2015 года ; 4 years ago ( 2015-07-29 )
Состояние разработки: Active
Написана на: C++ (язык программирования) [1]
Операционная система: Windows NT
Локализация: Same languages as Windows
Тип ПО: Web server
Лицензия: Part of Windows NT (same license)
Веб-сайт iis .net

IIS (англ. Internet Information Services ) является Visual Basic приложением, которое располагается на веб-сервере и отвечает на запросы браузера. Приложение IIS использует HTML для представления своего пользовательского интерфейса и использует скомпилированый код Visual Basic для обработки запросов и реагирования на события в браузере. Для пользователя приложение IIS представляется рядом страниц HTML. Для разработчика приложение IIS состоит из особого типа объекта, называемого WebClass, который в свою очередь, содержит ряд ресурсов, называемых webitems. WebClass выступает в качестве центрального функционального блока приложения, обрабатывающего данные из браузера и отправляющего информацию пользователям. Разработчик описывает ряд процедур, которые определяют, каким образом WebClass отвечает на эти запросы. webitems являются HTML-страницами и другими данными, которые WebClass может отправить в браузер в ответ на запрос.

Содержание

Архитектура

Internet Information Services (IIS) 7 и выше обеспечивает архитектуру обработки запросов, которая включает в себя:

  • Служба активации процесса Windows (WAS), который позволяет сайтам использовать отличающиеся от HTTP и HTTPS протоколы.
  • Веб-движок сервера, который может быть изменен путем добавления или удаления модулей.
  • Интегрированные конвейеры обработки запросов от IIS и ASP.NET.

Компоненты

IIS содержит несколько компонентов, которые выполняют важные функции для приложений и ролей веб-сервера в Windows Server® 2008 (IIS 7.0) и Windows Server 2008 R2 (IIS 7.5). Каждый компонент имеет функции, такие как прослушивание запросов к серверу, управление процессами и чтение файлов конфигурации. Эти компоненты включают в себя обработчики протокола, такие как HTTP.sys и службы, такие как World Wide Web Publishing (служба WWW) и службы активации процесса Windows (WAS).

Internet Information Server (IIS) имеет свой собственный ASP.NET Process Engine для обработки запроса ASP.NET. Способ настройки приложения ASP.NET зависит от того, какая версия IIS приложения используется.

Internet Information Server (IIS) включает в себя набор программ для создания и администрирования веб-приложений, поисковых систем, а также поддержку для написания веб-приложений, обеспечивающих доступ к базам данных, таким как SQL Server. IIS позволяет настроить компьютер в качестве веб-сервера и предоставляет функциональные возможности для разработки и развертывания веб-приложений ASP.NET на сервере. Кроме того, возможно установить параметры безопасности для конкретного веб-сайта для конкретных пользователей и компьютера для того, чтобы защитить его от несанкционированного доступа.

По заявлениям разработчиков, IIS повышает доступность веб-сайтов и приложений при одновременном снижении системного администрирования и стоимости развертывания. IIS 7.5 поддерживает HTTP, HTTPS, FTP, FTPS, SMTP и NNTP.

Ключевые особенности

  • Встроенные расширения
    • WebDAV и FTP
    • Фильтрация запросов
    • Модули администрирования
  • Усовершенствования управления
    • Анализатор соответствия рекомендациям
    • Windows PowerShell провайдер и cmdlets
    • Ведение журнала конфигурации и трассировки
  • Улучшения хостинга приложений
    • Управляемые учетные записи служб
    • Hostable веб-ядро
    • Трассировка неудачных запросов для FastCGI
  • Улучшения .NET поддержки для Server Core

Установка

  • Нажмите кнопку Пуск и выберите Панель управления.
  • На панели управления выберите Программы, а затем Включение и отключение компонентов Windows.
  • В диалоговом окне «Компоненты Windows» нажмите Службы IIS, а затем кнопку ОК.

Конфигурирование

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


  1. Войдите в систему на компьютере веб-сервера с правами администратора.
  2. Нажмите кнопку Пуск, выберите Настройка и щелкните Панель управления.
  3. Дважды щелкните значок Администрирование, а затем дважды щелкните значок Диспетчер служб Интернета.
  4. Щелкните правой кнопкой мыши веб-узел, который необходимо настроить, на левой панели и выберите команду Свойства.
  5. Перейдите на вкладку веб-узел .
  6. В поле Описание введите описание веб-узла.
  7. Введите адрес Internet Protocol (IP) для веб-узла или оставьте значение по умолчанию все (не назначено) .
  8. Измените порт протокола управления передачей (TCP), соответствующим образом.
  9. Перейдите на вкладку Домашний каталог.
  10. Чтобы использовать папку на локальном компьютере, выберите каталог на данном компьютере и нажмите кнопку Обзор, чтобы найти папку, которую требуется использовать.
  11. Чтобы использовать папку, общий ресурс с другого компьютера в сети, выберите параметр Общая папка другого компьютера и затем введите путь или нажмите кнопку Обзор, чтобы выбрать общую папку.
  12. Нажмите кнопку Чтение предоставить доступ на чтение к папке (обязательно).
  13. Нажмите кнопку ОК, чтобы принять свойства веб-сайта.

Создание нового веб-узла:

Чтобы создать новый веб-узел на сервере Apache, необходимо настроить виртуальный узел и настроить отдельные параметры для узла. Если используются службы IIS, можно создать новый веб-узел путем перевода следующих терминов в эквивалентные термины IIS:

Apache термин Термин IIS
Корень документа Каталог домашней страницы веб-узла IIS
Имя_сервера Заголовок узла IIS
Прослушивание IIS IP-адрес и TCP-порт

Чтобы создать новый веб-узел в IIS, выполните следующие действия:

  1. Войдите в систему на компьютере веб-сервера с правами администратора.
  2. Нажмите кнопку Пуск, выберите Настройка и щелкните Панель управления.
  3. Дважды щелкните значок Администрирование, а затем дважды щелкните значок Диспетчер служб Интернета.
  4. Щелкните Действие, выберите пункт Создать и выберите веб-узел.
  5. После запуска мастера создания веб-узла, нажмите кнопку Далее.
  6. Введите описание веб-узла. Это описание используется для идентификации веб-узла в диспетчере служб Интернета только для внутренних целей.
  7. Выберите IP-адрес для веб-узла. Если выбрать все (без значения), веб-узел будет доступен для всех интерфейсов и всех настроенных IP-адресов.
  8. Введите номер порта TCP, чтобы опубликовать на нем сайт.
  9. Введите имя заголовка узла (реальные имя, которое используется для доступа к этому узлу).
  10. Нажмите кнопку Далее.
  11. Введите путь к папке, которая содержит документы веб-узла, или нажмите кнопку Обзор, выберите папку и нажмите кнопку Далее.
  12. Укажите права доступа для веб-узла и нажмите кнопку Далее.
  13. Нажмите кнопку Готово.

Основы архитектуры IIS, или запросопровод для ASP.NET

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

1. Общий план
2. Крупный план
2.1. HTTP.SYS
2.2. World Wide Web Publishing Service (W3SVC)
2.3. Windows Process Activation Service (WAS)
2.4. Пул приложений
2.5. Домен приложения, приложение
3. Что дальше?
Источники

1. Общий план

Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально.
В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» — что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.

Рис. 1. HTTP request processing pipeline (IIS 7.x).

Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:

1. Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS.
2. HTTP.SYS стучится к WAS для получения информации из хранилища конфигурации.
3. Служба WAS запрашивает конфигурацию из хранилища — из файла в папке IIS (applicationHost.config).
4. Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC (она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта.
5. Служба W3SVC использует эту информацию для кофигурации HTTP.SYS.
6. Служба WAS запускает процесс W3WP.exe для пула приложений, если он ещё не был запущен.
7. В процессе W3WP.exe работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS.
8. HTTP.SYS отправляет ответ браузеру.

Илон Маск рекомендует:  На чем зарабатывают в сети Популярные способы заработка в интернете

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

2. Крупный план

2.1. HTTP.SYS

На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.

Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.

Драйвер принимает все входящие запросы и перенаправляет их в нужный пул приложений. Если по какой-то причине рабочий процесс, в коем хостится требуемый пул, остановлен (сбой, таймаут простоя, смена конфигурации и т.п.) или ещё запускается, то HTTP.sys сохраняет входящие запросы в специально отведённой для каждого пула очереди. Таким образом, запросы пользователей никуда не пропадают, и они вообще не замечают каких-то перебоев в работе сайтов под управлением IIS.

Ещё HTTP.sys умеет кешировать ответы (более подробно — Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда — Use of special characters like ‘%’ ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.

Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно — Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%\system32\drivers\http.sys.

Признаться, в процессе написания данной статьи я сам открыл для себя некоторые детали. Например, кэширование ответов на уровне драйвера HTTP.sys. Это помогло мне объяснить один случай странного, как мне тогда казалось, феномена в поведении IIS. Маркетологи выложили на сайт swf-открытку перед очередным праздником, но потом им что-то не понравилось в названии файла и они его переименовали. Однако сайт продолжал выдавать открытку по старому URL и даже очистка браузерного кэша не помогала. Тут уже подключился я, но ни перезапуск веб-сайта и всего пула приложений, ни обращение к сайту в обход корпоративного прокси-сервера не дали ожидаемого результата. Но теперь-то мы знаем, кто виноват.

2.2. World Wide Web Publishing Service (W3SVC)

Данная служба (сокращённо именуемя в спецификациях WWW service) была представлена в IIS 6 в качестве отдельного компонента для работы с протоколами HTTP/HTTPS и управления рабочими процессами приложений и выполняла следующие функции:

  • Администрирование драйвера HTTP.sys.
  • Управление рабочими процессами.
  • Мониторинг показателей производительности веб-сайтов.

Эта служба функционирует в Windows Server 2003 в контексте процесса Svchost.exe (настройки можно посмотреть в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc) в отличие от всех остальных служб IIS, которые исполняются в контексте процесса Inetinfo.exe, и реализована в Iisw3adm.dll.

В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).

Рис.2. Рабочий процесс со службами W3SVC и WAS.

Раз уж зашла речь об адаптерах к прослушивателям протоколов (protocol listener adpater), то давайте чуть задержимся и посмотрим, какие они бывают. В принципе IIS 7.x можно настроить для обработки запросов по любым протоколам помимо типовых HTTP и FTP, например, POP3, SMTP, Gopher. Вы даже вольны придумать свой протокол для своей веб- или WCF-службы и реализовать для него все нужные компоненты, если не жалко своего времени. Скорее всего, адаптеры и прослушиватели для наиболее распространённых протоколов доступны для свободного и коммерческого скачивания – этого я не проверял. Но прежде всего стоить обратить внимание на стандартные службы (рис. 3), поставляемые с .NET Framework и интегрированные с IIS:

  • NetTcpActivator для протокола TCP;
  • NetPipeActivator для Named Pipes;
  • NetMsmqActivator для Message Queuing (ака MSMQ).

Рис. 3. Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.

Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.

Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.

Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.

2.3. Windows Process Activation Service (WAS)

Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%\System32\inetsrv\Config\ApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.

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

  • Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
  • Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
  • Исполняемый файл w3wp.exe – шаблон рабочего процесса.
  • Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
  • Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler — PPH) и у домена приложения (AppDomain protocol handlers — ADPH).

Ниже на рисунке представлен пример схемы компонентов внутри некоего экземпляра рабочего процесса приложения. Когда служба WAS запускает рабочий процесс, она загружает в него согласно конфигурации приложения требуемые обработчики протоколов процессов (PPH) и посредством менеджера приложений создаёт внутри рабочего процесса домен приложения, в котором будет хоститься приложение. Менеджер приложений загружает код приложения в домен приложения и требуемые обработчики протоколов уровня приложения (ADPH) для обработки сообщений по соответствующим сетевым протоколам.

Рис. 4. Компоненты w3wp.exe для взаимодействия с внешними компонентами.

Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:

А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:

В конфигурационном файле веб-сервера ApplicationHost.config вместе с настройками приложений хранятся связки (bindings), определяющие параметры входящих запросов, которые будут направляться данному приложению. Такими параметрами являются название сетевого протокола, IP-адрес сервера, доменное имя и порт сайта. Эти параметры должны быть уникальными среди работающих приложений для однозначной идентификации целевого приложения. Служба WAS отслеживает это ограничение и не даст вам запустить сайт, у которого это условие не соблюдено, либо предложит остановить сайт с такой же связкой.

Обратите внимание, что в стандартном режиме эксплуатации IIS служба WAS, служба-адаптер для каждого прослушивателя протокола (в т.ч. W3SVC) и сами драйверы/прослушиватели каждого из протоколов (в т.ч. HTTP.sys) запущены в ОС в единственном экземпляре. Но отдельные запросы могут направляться разным приложениям в разных рабочих процессах. С другой стороны, отдельно взятому приложению могут направляться запросы по разным протоколам через соответствующие адаптеры. Видимо, для корректной реализации такого поведения и была придумана архитектурная связка драйвер протокола – адаптер драйвера протокола – служба активации (своеобразный регулировщик, точнее — маршрутизатор) – рабочий процесс.

2.4. Пул приложений

При конфигурации веб-приложения помимо привязок (binding) к параметрам запросов и прочих настроек указывается принадлежность к пулу приложений. Пул приложений стал нововведением в IIS 6 и был призван обеспечить изоляцию веб-приложений друг от друго и тем самым повысить стабильность работы веб-сервера в целом. Суть заключается в том, что код приложения выполняется внутри специального процесса Windows – w3wp.exe. Поэтому исключение внутри веб-приложения приведёт к краху только этого процесса и никак не повлияет на доступность веб-приложений в других пулах и работу служб IIS. Более того, служба WAS попытается заново запустить упавший сайт, и внешние клиенты могут даже не заметить проблем в работе сервера.

Для управления некоторыми параметрами отдельно взятого рабочего процесса w3wp.exe в IIS используется пул приложений. Наиболее часто используемыми из них являются учётная запись, под которой будет запущен процесс, ограничения для очереди запросов, различные таймеры и счетчики для автоматического перезапуска процесса, архитектура x86/x64 (в IIS 7.x) и некоторые другие (рис. 5), о чём любопытный читатель может с лёгкостью прочесть в MSDN и любимом поисковике. Т.о. можно говорить (с определёнными оговорками, см. тж. последний абзац в 2.5) о тождественности процесса w3wp.exe и пула приложений.

Рис. 5 Дополнительные настройки пула приложений

Ключевым нововведением в концепции пулов приложений в IIS 7.x стал новый параметр – модель управления контейнером, который может принимать 2 значения: классическая (Classic mode) и встраиваемая модель (Integrated mode).
Чтобы объяснить разницу между этими режимами работы, потребуется знакомство с понятием «модуль» (Module) в IIS 6/7.x и событийной моделью обработки запросов в связке IIS + ASP.NET. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.

Итак, IIS при обработке запроса пропускает его внутри рабочего процесса через последовательность специальных компонент – модулей. Например фильтрация, перенаправление, кэширование, аутентификация, авторизация. Каждый такой модуль ассоциируется с определённым событием, а их последовательность составляют событийную модель обработки запросов. Модули делятся на нативные (Native) и управляемые (Managed). Нативные модули поставляются вместе с IIS, а управляемые – в составе .NET Framework (ASP.NET). В общем-то, вы можете управлять ими в определённой степени на уровне конфигурации веб-приложения, но взаимодействовать из кода своего ASP.NET-сайта вы можете только с управляемыми модулями.

Рис. 6. Идеология модулей в IIS.

Классическая модель управления контейнером обеспечивает обратную совместимость с режимом изоляции рабочих процессов в IIS 6 – запросы к ASP.NET-сайту сначала проходят через нативные модули, а затем передаются в Aspnet_isapi.dll для обработки модулями в управляемой среде. Такое разделение между IIS и ASP.NET приводит к дублированию некоторых функций, например, аутентификации и авторизации. И вы не имеете возможности управлять программно поведением нативных модулей (пример хоть и не самый животрепещущий, но всё же – раздел «Убираем заголовок Server» в этой статье).

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

На практике самое важное, что необходимо учитывать при разработке и развёртывании веб-приложений, – это частичная несовместимость этих двух режимов. Т.е. при переводе сайта (точнее пула приложений, в котором работает сайт) из классической модели во встраиваемую практически всегда потребуется корректировка кода (хоть, возможно, и не значительная), а также тщательное тестирование.

2.5. Домен приложения, приложение

Непосредственными контейнерами веб-приложения являются приложение и домен приложения (Application Domain, AppDomain). Зачастую эти два понятия отождествляются, но всё-таки это немного разные вещи. Приложение – это понятие IIS, а домен приложения – из ASP.NET. Причём в общем случае в приложении может быть несколько доменов. Приложением вы можете управлять из консоли IIS, а доменом приложения – в основном программно. Так, например, перезапускается приложение из консоли. А когда мы пересохраняем web.config, то перезагружается именно домен приложения, не трогая IIS-приложение.

Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс My >
Рис. 7. Рисунок для задачки.

Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.

3. Что дальше?

Дальше нужно разбираться в работе модулей (в терминах IIS) и событийной модели, в которых уже происходит собственно обработка запроса, о чем упоминалось в разделе 2.4. Вообще говоря, эта тема заслуживает отдельной статьи, на которую, боюсь, меня уже не хватит. Но без этого нельзя сказать, что мы рассмотрели весь конвейер обработки запросов. Поэтому кратко пройдёмся здесь по основным моментам, которые любопытствующий читатель может проработать самостоятельно.

Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.

Начало работы с IIS 7.0

Written on 21 Января 2009 . Posted in Web-серверы

ОГЛАВЛЕНИЕ

Новая архитектура IIS 7.0

Основные изменения IIS 7.0 относятся к архитектуре, обработке запросов, поддержке платформы приложений PHP и хранилищу настроек. В IIS 6.0 функции по большей части носили характер «все или ничего». Необходимо было установить все функции, а настройка IIS осуществлялась только с помощью интерфейса ISAPI.

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

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

В данный момент в состав IIS входит 40 модулей по умолчанию — например, обычная, анонимная проверка подлинности и проверка подлинности Windows® теперь выделены в отдельные модули, которые могут добавляться к конвейеру обработки запросов независимо. Для упрощения классификации модули сгруппированы в восемь подкатегорий (см. рис. 1).

Рис. 1 Модули IIS 7.0 разделены на восемь функциональных областей

Это означает, что теперь возможно создание веб-сервера, точно настроенного в соответствии с вашей средой. Но если необходимы функциональные возможности, не предоставляемые 40 модулями по умолчанию, скажем, определенная настраиваемая проверка подлинности или модификатор содержимого? Нет проблем. Можно написать модуль для восполнения этой потребности на машинном или управляемом коде и подключить его непосредственно к конвейеру. Это также позволяет корпорации Майкрософт создавать и выпускать новые модули по отдельности, избавляя от необходимости ожидания следующего пакета обновления или основного выпуска. IIS 7.0 также позволяет переписывать любой из 40 стандартных модулей собственными пользовательскими модулями. Дополнительные сведения о создании собственных модулей приведены на веб-узле IIS.net.

Встроенный конвейер обработки запросов

Встроенный конвейер обработки запросов можно рассматривать как необходимый набор линейных действий, которые должны выполняться при каждом предоставлении страницы (как показано на рис. 2). Обычно этот набор состоит из определенной проверки подлинности и последующей авторизации для получения содержимого, определения и выполнения обработчика, необходимого для этого содержимого, выполнения необходимой регистрации, и, наконец, отправка запроса. Встроенный конвейер обработки запросов предоставляет IIS 7.0 гибкость одновременного выполнения различных платформ приложений. Например, можно выполнить проверку подлинности на основе форм на содержимом PHP с пользовательским модулем ведения журнала в одном конвейере.

Рис. 2 Интегрированный конвейер и модули IIS 7.0

Каждый веб-узел на сервере имеет встроенный конвейер обработки запросов и может быть запущен в одном из двух режимов – встроенном или классическом. Встроенный режим, режим по умолчанию, позволяет подключать к конвейеру определенные функциональные возможности, обеспечивая настраиваемый контроль над обработкой запроса. Для обеспечения совместимости классический режим воспроизводит функции IIS 6.0/ISAPI с помощью модуля ISAPI в конвейере. Это очень полезно при переносе приложений в IIS 7.0.

Установка по умолчанию

Рассмотрим настройку нового модульного веб-сервера. Если взглянуть на установку IIS 7.0 по умолчанию, можно заметить, что включены только 10 модулей (если включена служба активации процессов Windows). Настройка IIS 7.0 предоставляет базовую функциональность IIS при установке роли веб-сервера, в частности, только модули, необходимые для предоставления статического содержимого, например, обычного кода HTML или классических страниц ASP. Последующая установка дополнительных компонентов на сервере определяется только вами. Ниже приведены функциональные возможности, включенные в установку по умолчанию:

  • Основные функции HTTP, включая статическое содержимое, документ по умолчанию, обзор каталога и ошибки HTTP
  • Функции работоспособности и диагностики, такие как ведение журнала HTTP и монитор запросов
  • Функции безопасности, такие как фильтрация запросов
  • Функции повышения производительности, такие как сжатие статического содержимого
  • Средства управления, в том числе консоль управления IIS
  • Служба активации процессов Windows

Как видите, это сервер с минимально необходимым количеством компонентов, в состав включающий ASP.NET и другие новые функции IIS 7.0, такие как функции диагностики и устранения неисправностей. Добавление на сервер дополнительных функциональных возможностей, таких как возможность передачи динамического содержимого, например, ASP.NET и FastCGI (PHP), осуществляется очень просто. Выберите необходимый для установки набор модулей в разделе «Add Role Services» (Добавление служб роли) роли веб-сервера в диспетчере Windows Server® 2008 Server Manager.

Новое хранилище настроек

Другим ключевым изменением в IIS 7.0, упрощающим вашу работу, является новое хранилище настроек. Метабаза, теперь являющаяся дополнительным устанавливаемым компонентов для обеспечения обратной совместимости, заменена системой настроек на основе XML. Я уже слышу, как вы говорите: «Но метабаза была в формате XML!» Да, была. Но она была громоздкой и не простой для чтения (по крайней мере, человеческого). Она заменена более гибкой системой XML. Подобно ASP.NET, IIS 7.0 использует файлы .config — простые, ясные, переносимые и простые для чтения файлы.

Илон Маск рекомендует:  Что такое код ldap_mod_del

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

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

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

Включение настройки общего пользования осуществляется очень просто. На узле сервера диспетчера служб IIS выберите пункт «Shared Configuration» (Настройка общего пользования), который находится в разделе «Управление» на панели задач. Просто установите флажок «Enable shared configuration» (Включить настройки общего пользования), укажите физический путь к файлу настройки для совместного использования (обычно это общая папка UNC), введите учетные данные, необходимые для доступа к физическому пути, и нажмите кнопку «Применить». После нахождения файла .config появится запрос на ввод пароля шифрования. После завершения процесса перезапустите диспетчер служб IIS, чтобы он выбрал новый файл .config.

Поскольку структура новой системы настроек отличается от той, к которой вы привыкли, рассмотрим ее основы. Как показано на рис. 3, настройка IIS 7.0 разделена на две категории – параметры уровня сервера и параметры узла. Все параметры уровня сервера хранятся в файле applicationhost.config, который находится в папке %systemroot%\windows\system32\inetsrv\config. К ним относятся параметры всех установленных модулей, узлов на сервере и т.д. Параметры узла хранятся в отдельных файлах web.config.

Рис. 3 Существует один файл .config для параметров уровня сервера и отдельные файлы для каждого веб-узла на этом сервере

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

Файл web.config узла находится в физическом пути к узлу, например, %systemroot%\inetpub\wwwroot. Такая модель предоставляет такие же преимущества переносимости, которые были описаны ранее, но на уровне узла. Например, можно просто разработать узел на тестовом сервере, а затем перенести файл web.config и файлы приложения на рабочий сервер с помощью перетаскивания или функции xcopy.

При переносе или совместном использовании файлов .config следите за сведениями, зависящими от компьютера, такими как IP-адрес и буквы дисков. Службы IIS 7.0 предоставляют решение для возможных ошибок в подобных параметрах, поддерживая переменные среды операционной системы (например, %systemroot%). Кроме того, убедитесь, что на тестовых и рабочих серверах установлен одинаковый набор модулей. Это поможет избежать появления непредвиденных ошибок приложений. Ошибки также могут возникать, если в файле web.config содержится ссылка на неустановленный модуль или в случае конфликта стандартного модуля с пользовательским.

Управление веб-сервером

Теперь в вашем распоряжении этот новый, замечательный, настраиваемый, гибкий и переносимый веб-сервер. Как вы собираетесь управлять им? Управление было важной частью планирования и создания служб IIS 7.0, и существует несколько способов администрирования.

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

В IIS 6.0 пользовательский интерфейс оснастки консоли управления Microsoft® (MMC) имеет два основных знакомых представления, представление в виде дерева и представление в виде вкладок. Для перехода к определенному параметру необходимо щелкнуть его правой кнопкой мыши и выбрать «Properties» (Свойства), после чего появится набор вкладок, не говоря уж о переключателях и флажках.

К счастью, пользовательский интерфейс в IIS 7.0 полностью переработан. Этот пользовательский интерфейс, называемый диспетчером служб IIS, задумывался для реализации подхода, ориентированного на задачи, как показано на рис. 4. Также существует диспетчер Remote Manager для клиентов нижнего уровня, таких как Windows XP и Windows Server 2003. Его можно загрузить с веб-узла IIS.net/downloads.

Рис. 4 Новый пользовательский интерфейс в IIS 7.0

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

В диспетчер служб IIS также интегрированы свойства ASP.NET, избавляя от необходимости использовать дополнительную оснастку MMC. Каждое настраиваемое свойство имеет собственный значок, что упрощает поиск свойств. А поскольку диспетчер служб IIS создавался как приложение Windows Forms, можно легко добавлять значки подключаемых модулей для любых созданных пользовательских модулей или функций.

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

Другие способы управления

Для тех, кто предпочитает командную строку, доступно новое многостороннее средство APPCMD.exe, позволяющее выполнять простые задачи, такие как остановка узла или резервное копирование текущего файла .config, а также более сложные задачи, например, поиск схемы настройки. Синтаксис очень простой:

APPCMD (command) (object-type)

Для получения списка всех объектов, доступных для APPCMD, введите:

Чтобы просмотреть все команды, доступные для определенного типа объекта, введите:

В IIS 7.0 добавлены новый интерфейс API управляемого кода под названием Microsoft.Web.Administration и новый поставщик WMI (инструментария управления Windows), которые будут полезны всем программистам. Эти два метода предоставляют массу возможностей для создания сценариев, автоматизации и написания средств для управления IIS 7.0. Оба метода могут использоваться при помощи Windows PowerShell®, а поставщик WMI – также при помощи VBScript и JScript®. Дополнительные сведения имеются в блоге blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx.

Удаленное управление и делегированное администрирование

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

Раньше существовало два способа удаленного управления сервером IIS: с помощью веб-узла удаленного управления или удаленного рабочего стола/служб терминалов для доступа к пользовательскому интерфейсу. Но при нахождении с внешней стороны брандмауэра или не на узле эти способы были не особо полезны. В службах IIS 7.0 эта проблема устраняется благодаря созданию способов удаленного управления непосредственно в пользовательском интерфейсе, работающем через совместимое с брандмауэром подключение HTTPS.

Удаленное управление в IIS 7.0 упрощает работу несколькими способами. Во-первых, работа осуществляется с таким же пользовательском интерфейсом, как и при локальном входе в систему. Во-вторых, не требуется открывать порты на брандмауэре, поскольку связь осуществляется через HTTPS. Наконец, теперь из одного пользовательского интерфейса можно управлять несколькими серверами. Не требуется, чтобы одновременно были открыты несколько окон подключения к удаленному рабочему столу или удаленному веб-узлу.

Служба удаленного управления в IIS 7.0 фактически представляет собой небольшое веб-приложение, работающее как отдельная служба под учетной записью локальной службы Windows NT® с именем NT Service\WMSVC. Такая модель обеспечивает сохранение возможности удаленного управления, даже если сам сервер IIS не отвечает.

Как и большинство функций IIS 7.0, удаленное управление в целях безопасности не установлено по умолчанию. Для установки функций удаленного управления добавьте службы ролей для роли веб-сервера в диспетчере сервера Windows Server 2008, который находится в разделе «Management Tools» (Средства управления). После установки функции необходимо включить удаленные подключения и запустить службу WMSVC, поскольку по умолчанию она остановлена.

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

sc config WMSVC start=auto

При включении удаленных подключений через службы управления появится список параметров, таких как «Удостоверяющие учетные данные», «Подключения» и «Ограничения для IPV4-адреса». В данный момент только одно решение является важным – определение набора удостоверяющих учетных данных для предоставления полномочия на подключение к IIS 7.0: только учетные данные Windows или учетные данные Windows и диспетчера IIS.

Первый вариант, указывающий на разрешение только учетных записей пользователей Windows, локальных или доменных, является довольно очевидным. По второму варианту проходят как пользователи Windows, так и тип учетной записи, являющийся совершенно новым в IIS 7.0 и не связанным с учетными записями пользователей Windows: пользователи диспетчера IIS. Учетные записи пользователей диспетчера IIS позволяют администраторам создавать учетные записи пользователей, известные только в контексте IIS 7.0 и не имеющие прав доступа к операционной системе. Наконец, службы IIS по умолчанию предоставляют самоподписанный сертификат, чтобы можно было начать работу, но рекомендуется добавить действительный подписанный сертификат SSL. Теперь необходимо просто применить параметры и запустить службу.

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

Делегированное администрирование в сущности является удаленным администрированием, но оно ограничивает область доступа отдельными узлами или веб-приложениями. Функция пользователей диспетчера IIS особенно полезна здесь. Можно создать пользователей IIS для этих разовых владельцев узлов и делегировать им полномочия на администрирование собственного узла или приложения. У них отсутствует доступ к параметрам уровня сервера, и они ограничены только параметрами определенного узла или веб-приложения.

Кроме того, можно указать функции и параметры, изменяемые пользователями или даже отображаемые в пользовательском интерфейсе. Например, если тип проверки подлинности, используемый для данного узла, не должен никем изменяться, можно указать, что эта функция только для чтения или не наследуется. Функция только для чтения доступна для пользователей, и они могут определять ее параметр, но не могут вносить изменения; значок ненаследуемой функции отсутствует в представлении диспетчера IIS делегированного пользователя. Такой вид делегирования функции позволяет предоставлять другим пользователям строго контролируемый доступ без предоставления административного управления веб-сервером.

Переход на IIS 7.0

При создании служб IIS 7.0 группа разработчиков стремилась к тому, чтобы переход на них осуществлялся как можно более плавно, позволяя использовать некоторые существующие вложения в средства управления и сценарии для IIS 6.0. Была тщательно продумана обратная совместимость служб IIS 7.0, чтобы они могли работать со сценариями IIS 6.0. На узле совместимости управления IIS 6.0 программы установки можно установить весь набор средств — от совместимости метабазы IIS 6.до самой консоли управления IIS 6.0.

В инфраструктуре совместимости метабазы IIS 6.0 используется компонент с названием ADOMapper. Он позволяет выполнять сценарии метабазы объектов на основе администратора (ABO) и интерфейса ADSI IIS 6.0 в новой системе настроек, ограничивая ее только возможностями IIS 6.0. Поэтому чтение и запись новых свойств IIS 7.0, доступ к новым данным выполнения, чтение и запись свойств ASP.NET или файлов web.config невозможны.

Устранение неполадок и диагностика

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

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

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

Рис. 5 Использование отслеживания сбойных запросов для устранения неисправностей

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

Службы IIS 7.0 – большой шаг вперед для всех администраторов. Новая архитектура и возможности обеспечивают гибкость и динамичность, необходимые для адаптации к непрерывно меняющейся среде. Благодаря возможностям управления, средствам обратной совместимости и возможностям устранения неполадок службы IIS 7.0 готовы к развертыванию уже сегодня и работе с существующей средой.

Iis о ведении журналов узлов

4181 просмотра

2 ответа

411 Репутация автора

Я унаследовал классический проект ASP и развернул его на IIS 7.5. Я могу получить доступ к сайту, однако в определенный момент я получаю общую страницу ошибок 500. Я хочу знать, что происходит, поэтому я считаю, что лучше всего посмотреть журналы

  • Не нашли ничего в c: \ WINDOWS \ system32 \ LogFiles \ nor c: \ inetpub \ logs \
  • Попробовал включить ведение журнала, как здесь: https://technet.microsoft.com/en-us/library/cc732826(v=ws.10).aspx Но у меня нет значка / кнопки ведения журнала (см. Снимок экрана).
  • Запрашивает пользовательскую ошибку 500, как здесь: http://www.iis.net/configreference/system.webserver/httperrors/error, но нет значка «Страницы ошибок» (см. Снимок экрана)
  • Пытался настроить пользовательскую страницу 500 с помощью web.config, как здесь: http://blogs.iis.net/rickbarber/archive/2013/02/18/working-past-500-internal-server-error.aspx, но кажется, что он получает игнорируются

Для записи я новичок с IIS / ASP, поэтому вопрос может звучать немного глупо. Спасибо за любое предложение!

Ответы (2)

1 плюс

1305 Репутация автора

Это приведет к записи информации об ошибке на экран. Измените раздел «If blnLogFailure», если вы хотите записать в файл.

Автор: Jen R Размещён: 12.03.2015 05:10

8 плюса

15097 Репутация автора

Вы должны установить функцию «Ошибки HTTP» в IIS . Этого достаточно, чтобы просмотреть сообщение об ошибке — вам не потребуется вести журнал.

Чтобы установить ошибки HTTP:

  1. Перейдите в панель управления «Программы и компоненты».
  2. Выберите «Включить или отключить функции Windows»
  3. Перейдите к Internet Information Services> Широкоформатные веб-службы Windows> Общие функции HTTP и выберите «Ошибки HTTP» (в то время как вы на нем, вы можете установить функцию ведения журнала путем сверления в Internet Information Services> Широкоформатные веб-службы> Диагностика и выбор «HTTP Logging».)
  4. Нажмите «ОК» для установки.

После установки настройте IIS для отображения подробных сообщений об ошибках:

  1. В настройках IIS для вашего сайта вы должны увидеть параметр «Страницы ошибок». Дважды щелкните по нему.
  2. Нажмите «Изменить настройки параметров».
  3. Выберите «Подробные ошибки» или «Подробные ошибки для локальных запросов . » в зависимости от того, выполняете ли вы локальную разработку или нет.
  4. В настройках IIS для вашего сайта дважды щелкните параметр ASP.
  5. Разверните «Отладка свойств» и установите «Отправить ошибки для браузера» в значение true.

Теперь вы должны увидеть подробные сообщения об ошибках.

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

IIS 6.0 F1: Свойства веб-узла — вкладка «Веб-узел»

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

Чтобы веб-браузеры имели доступ к содержимому веб-сайта, необходимо определить IP-адрес и номер TCP-порта.

Введите понятное имя для веб-сайта. Это имя будет отображаться в дереве объектов консоли диспетчера IIS.

Выберите в списке или введите IP-адрес, который должен использоваться для доступа к данному сайту. Если не назначить конкретный IP-адрес, данный сайт будет отвечать на обращения по всем IP-адресам, назначенным этому компьютеру и не назначенным другим сайтам, т. е. сайт станет веб-сайтом, используемым по умолчанию. Для включения IP-адреса в список необходимо предварительно определить его с помощью панели управления компьютера. Дополнительные сведения см. в справке по Windows Server 2003. Описание сайта вводить не обязательно.

Назначьте порт TCP, используемый веб-службой; по умолчанию это порт 80. Можно задать любой другой номер TCP-порта, но при этом необходимо заранее известить клиентов об изменении номера порта: если в запросе будет указан старый номер, подключение к серверу не установится. Номер порта является обязательным параметром; нельзя оставлять это поле пустым.

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

Кнопка для дополнительной настройки IP-адреса, номера TCP-порта и значения заголовка узла — параметров, используемых для доступа к данному сайту.

В IIS можно задать промежуток времени в секундах, по истечении которого сервер отключает неактивного пользователя. Таким образом обеспечивается закрытие всех подключений, если протокол HTTP не может закрыть подключение. Большинство веб-браузеров требуют, чтобы сервер оставлял подключение открытым для многократной выдачи запросов. Этот режим открытых соединений (HTTP Keep-Alive) представляет собой спецификацию HTTP, позволяющую существенно повысить производительность сервера. Без ее использования веб-браузеру приходится выполнять несколько запросов на подключение для страницы, содержащей несколько элементов, например графических объектов. Для каждого элемента может потребоваться отдельное подключение. Такие дополнительные запросы и подключения требуют дополнительных операций и ресурсов сервера, что в результате существенно понижает быстродействие. Кроме того, сам браузер начинает работать медленнее, особенно в случае подключений с большой задержкой. Режим поддержки открытых соединений HTTP включается по умолчанию в процессе установки.

Время ожидания подключения

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

Разрешить поддержку открытых соединений HTTP

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

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

Эти сведения сохраняются в ASCII-файлах или в ODBC-совместимой базе данных. Данные, которые заносятся в журналы IIS, не входят в компетенцию средств регистрации событий или наблюдения за производительностью, имеющихся в Microsoft® Windows®. Журналы могут содержать сведения о том, кто посещал сайт и что именно он просматривал, а также когда последний раз было просмотрено содержимое. С помощью этих журналов можно оценивать популярность содержимого или выявлять узкие места.

Формат текущего журнала

Выберите один из следующих форматов файла журнала.

    Формат файла журнала Microsoft IIS: фиксированный формат ASCII.

Общий формат файла журнала NCSA: фиксированный формат ASCII.

Ведение журнала ODBC: фиксированный формат для записи в базу данных, совместимый с этой базой данных.

Расширенный формат файла журнала W3C: настраиваемый формат ASCII, выбранный по умолчанию. Для доступа к системе учета процессов необходимо выбрать расширенный формат файла журнала W3SVC.

Кнопка для настройки условий создания новых файлов журналов (например, еженедельно или после превышения размера файла), а также для настройки формата W3C или ODBC.

См. также

Дополнительные сведения об именовании веб-сайтов, шифровании данных по протоколу SSL, поддержке открытых соединений HTTP и ведении журнала работы сайта см. в документации по IIS 6.0 в Интернете в техническом центре Microsoft Windows Server.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL