Возможности журналирования и анализа логов в IIS 8.5
В новой версии Internet Information Services 8.5, представленной в качестве роли веб сервера в Microsoft Windows Server 2012 R2, появилась новая возможность логирования. IIS теперь может писать HTTP-логи в особый журнал трассировки через службу трассировки событий Windows (Event Tracing for Windows — ETW). Благодаря механизму Event Tracing for Windows в IIS 8.5 появилась возможность отслеживать события на веб сервере в реальном времени, что крайне полезно при отладке веб-приложений и поиске неисправностей.
В предыдущих версиях IIS логи веб-сервера записывались в отдельные лог-файлы. Основной недостаток данного механизма – кэширования логов в оперативной памяти. Логи из кэша записываются (сбрасываются) на диск каждую минуты или по достижению объема 64Кб. Это значительно усложняло онлайн-траблшутинг в IIS, т.к. высока вероятность того, что событие, появление которого вы ожидаете, произошло, но информация о нем пока просто не записалась в лог файл, и, соответственно, вы его не сразу не увидите.
В этой статье мы покажем, как в IIS 8.5 задействовать службу трассировки событий Windows (ETW) и как проанализировать полученные логи с помощью Microsoft Message Analyzer.
По умолчанию IIS 8.5 записывает логи в обычные тестовые файлы. Чтобы включить логирование через ETW, нужно в панели управления IIS (Internet Information Services Manager), выбрать имя сервера и в правой панели щелкнуть по значку Logging.
В окне настройки параметров журналирования в разделе Log Event Destination выберете метод ведения журнала, переключившись со стандартного Log file only на ETW event only. Обратите внимание, что можно включить ETW и стандартное журналирование IIS одновременно (Both log file and ETW event). 
Сохраним изменения. Сразу после этого логи веб сервера IIS начнут писаться через службу трассировки событий Windows.
Для просмотра и анализа логов IIS в журналах ETW воспользуемся бесплатным инструментом Microsoft Message Analyzer, который можно скачать с сайта Microsoft по этой ссылке: _http://www.microsoft.com/en-us/download/details.aspx?id=40308
Во время первого запуска Microsoft Message Analyzer спросит, хотите ли вы обновить элементы на стартовом экране. Выберите желаемое действие.
В открывшемся окне Message Analyzer настроим доступ к логам IIS ETW. Для этого щелкните по ссылке Capture/Trace в левой колонке и укажите имя трассировки. 
В разделе Trace Scenario Configuration в поле Add Provider введите IIS и из появившегося выпадающего списка выберите Microsoft-Windows-IIS-Logging. 
После того, как мы подключились к нужному провайдеру ETW, можно начать просмотр ( и сбор) событий, нажав кнопку Start With. 
Собранные данные будут отображены в виде таблицы (если эта опция была указана при запуске).
Чтобы уменьшить количество отображаемой информации, можно применять различные фильтры. Допустим, нам нужно вывести данные, касающиеся только определенного сайта IIS. 
Для этого в расширенном описании нужного события щелкнем по полю S_sitename и выберем Add Ssitename To Filter (добавить имя сайта в фильтр). 
В окне фильтров появится сгенерированный текст кода фильтра. Если нажать кнопку Apply Filter, в окне журнала останутся только данные, которые относятся к указанному нами сайту. 
Аналогичным образом можно добавить фильтр, например, позволяющий оставить в журнале только события с ответом сервера 404 (поле Sc_status). 
Итак, в этом небольшом обзоре мы разобрались с новыми возможностями анализа и поиска неисправностей на веб сервере IIS, с помощью журналирования событий веб-сервера через систему ETW. Также мы показали как можно анализировать полученных данных с помощью Microsoft Message Analyzer.
Автоматическая очистка логов IIS с помощью PowerShell
Веб сервер IIS (Internet Information Services) в процессе работы генерирует довольно большое количество логов, которые пишутся в файлы журналов. Основная проблема в том, что по-умолчанию журналы IIS расположены на системном диске, и со временем файлы логов могут забить все доступное место на диске и работа сервера будет парализована. К примеру, в моем случае на Exchange Server 2013 с почти 1000 ящиков, IIS генерирует за день лог-файл порядком 200 Мб. Таким образом, за год, файлы логов IIS будут занимать 70 Гб дискового пространства. Можно ли как-то управлять эти процессом?
В IIS отсутствует какая-либо встроенная процедура ротации логов IIS, поэтому администраторам приходится выдумывать собственные схемы для автоматической ротации или удаления журналов IIS на веб серверах.
В первую очередь администратор должен в принципе решить, нужны ли вообще логи, которые генерирует IIS. Если вопрос отрицательный – ведение журналов логов можно отключить в настройках сайта в консоли Internet Information Services (IIS) Manager в разделе Logging. В некоторых случая также применим перенос файлов журналов с системного диска на диск с данными/выделенный диск. Для этого в том же разделе достаточно изменить путь к каталогу LogFiles.
Так по-умолчанию, в Windows Server 2003 логи IIS хранятся в папке %windir%\system32\LogFiles\ и в Windows Server 2008 / 2012 /R2 в папке %SystemDrive%\inetpub\logs\LogFiles\.
В случае исчерпания свободного места на системно диске, администратор судорожно пытается найти чем забит диск, и благополучным образом не обращает внимание на каталог inetpub, т.к. на первый взгляд его размер незначителен. Проблема в том, что по умолчанию у администратора нет прав на просмотр стандартных каталогов внутри папки inetpub, и таким образом проводник Windows не показывает реальный размер вложенных папок.
Если попытаться открыть каталог %SystemDrive%\inetpub\logs\LogFiles, подтверждая назначение необходимых разрешений (или запустить проводник с правами администратора), можно увидеть, что на самом деле размер папки с логами довольно велик.
Как правило, можно безопасно удалить все файлы логов старше 3-7 дней. Это можно сделать вручную (не самый лучший вариант), либо автоматически с помощью скрипт PowerShell который будет удалять старые лог файлы по расписанию.
Простой PowerShell скрипт, который будет рекурсивно удалять файлы с расширением *.log из каталога C:\inetpub\logs может быть таким:
gci ‘C:\inetpub\logs -Include ‘*.log’ -Recurse | ? LastWriteTime -LT (Get-Date).AddDays(-7) | Remove-Item
Для автоматического запуска скрипта можно создать такое задание в планировщике (Task Scheduler):
- Запустите Task Scheduler
- В правой панели Action щелкните по Create Basic Task
- Укажите имя задания: CleanIISLog
- Настроим задание на еженедельный запуск по субботам
- Запускаемая программа: powershell.exe
- Аргументы: —NoProfile -command «gci ‘C:\inetpub\logs’ -Include ‘*.log’ -Recurse | ? LastWriteTime -LT (Get-Date).AddDays(-7) | Remove-Item»
- Теперь откройте свойства созданного задания
- Укажите, что задание будет запускаться из-под Системы (NT AUTHORITY\System) и поставьте чекбокс Run with highest privileges
- Протестируйте задание, щелкнув по нему ПКМ и выбрав Run
- Убедитесь, что все лог файлы старше 7 дней автоматически удалены
Совет. Еще один способ «быстро» уменьшить размер логов, когда удалять их по каким-то причинам нельзя – включить NTFS сжатие на каталоге с логами. Т.к. логи представляют собой простые текстовые файлы, жмутся они довольно сильно (в 4 -5 раз). Чтобы включить NTFS компрессию, откройте свойства папки с логами и нажмите на кнопку Advanced. Отметьте галку Compress contents to save disk space и дважды нажмите OK.
Логи IIS — очистка
Веб-сервер IIS в процессе своей работы генерирует достаточно большие объемы log-файлов. Все бы ничего, но по умолчанию логи IIS располагаются на системном диске , которому обычно не предоставляют большой объем. Хорошо, если у вас виртуальная машина и вы можете просто не обращать внимание на нехватку диска C:\, увеличивая его объем по необходимости, благо функционал виртуальных машин Hyper-V второго поколения позволяет увеличивать размер даже системного диска без выключения сервера, прямо налету. А если у вас такой возможности нет? В таком случае разрастание логов может стать для вас серьезной проблемой.
В статье я расскажу как обращаться с log-файлами IIS и автоматизировать процесс удаления.
Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.
Логи IIS
По умолчанию логи IIS располагаются в каталоге %SystemDrive%\inetpub\logs\LogFiles. Сигналом для их очистки может служить истощающееся быстрыми темпами свободное место системного диска. В этом случае системные администраторы начинают искать что же занимает столько места и благополучно пропускают папку inetpub, поскольку по умолчанию она практически ничего не весит:
Но почему? Дело в том, что изначально вы не имеете разрешений на вложенные папки, следовательно не можете увидеть их реальный объем:
Попробуйте зайти в каждую подпапку каталога %SystemDrive%\inetpub\logs\LogFiles, соглашаясь с назначением необходимых разрешений и в итоге увидите, что реальный объем папок не так уж и мал:
Разумеется у меня приведены в пример скриншоты с тестового сервера. Объем логов серверов в продакшене может достигать десятков и сотен гигабайт совершенно спокойно.
Итак, проблема найдена, пора заняться очисткой. Теоретически её можно проводить и вручную, но в этом нет никакого смысла и проще все сделать скриптами, в некоторых случаях достаточно даже одной команды PowerShell. В одной из статей по Exchange 2013 (см. Очистка папки Logging Exchange 2013) я уже рассматривал вопрос автоматизации процесса очистки логов, но не помешает напомнить о нем и в этой статье.
Команда для очистки log-файлов в нашем случае будет выглядеть следующим образом: