Как посмотреть ошибки iis - Не ошибается лишь тот, кто ничего не делает!

Обновлено 18.12.2022

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами рассматривали, как можно установить Internet Information Services. Сегодня я хочу продолжить данную тему и показать вам где хранятся файлы журналов IIS, так как файлы журналов Internet Information Services (IIS) содержат ценную информацию об использовании и состоянии Web приложений. Однако не всегда легко найти, где они находятся, чтобы определить важные аспекты использования приложения, например, когда были сделаны запросы к серверу, кем и другие проблемы пользовательского трафика. Давайте разбираться.

Что такое журнал IIS?

Ведение журнала IIS — это ведение журнала на стороне сервера, которое включено для группы URL-адресов. Журналы IIS имеют фиксированный текстовый формат ASCII и не могут быть настроены. Там можно получить много ценной информации, когда вы ищите источник проблем на вашем веб-сервере. Очень частая ситуация, веб-приложение получает ошибку 5хх, не всегда по коду понятно, в чем причина, что делать, куда смотреть. Лично я такие обращения получаю от разработчиков раз в месяц стабильно.

🗒Расположение журналов IIS

По умолчанию логи IIS после установки располагаются по пути:

%SystemDrive%inetpublogsLogFiles

Данную папку вы можете посмотреть в проводнике Windows. В папке LogFiles вы найдете папки с именами в формате:

✅ W3SVC1
✅ W3SVC2
✅ W3SVC3

Число в конце имени папки соответствует идентификатору сайта. Таким образом, W3SVC2 соответствует идентификатору сайта 2.

Чтобы узнать ID у сайта вам нужно перейти в его дополнительные свойства.

Размер журналов будет зависеть от интенсивности записи в них и можете спокойно достигать по 500 МБ.

Так же вы можете посмотреть ошибки по пути:

%SystemDrive%WindowsSystem32LogFilesHTTPERR

📌Что делать, если вы не можете найти файлы логов IIS?

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

Чтобы их найти, вы должны запустить оснастку Internet Information Services. Для этого запустите окно «Выполнить» и введите:

Найдите интересующий вас сайт, после чего кликните по иконке «Logging«.

В разделе «Directory» вы увидите, где у вас лежат логи Internet Information Services. При желании вы можете это поменять. Обратите внимание на формат ведения журнала, по умолчанию будет W3C.

W3C используется для централизованного формата файла журнала W3C, для регистрации информации обо всех сайтах на сервере. Этот формат обрабатывается HTTP.sys и представляет собой настраиваемый текстовый формат ASCII, что означает, что вы указываете регистрируемые поля. Укажите поля, которые регистрируются в диалоговом окне «W3C Logging Fields«, щелкнув «Select Fields« на странице Ведение журнала. Поля разделены пробелами, а время записывается в формате всемирного координированного времени (UTC).

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

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

✅ IIS-CentralCertificateProvider
✅ IIS-Configuration
✅ IIS-Logging

⚙️Как найти файлы журналов IIS в Azure

Облако Azure:

Файлы журналов IIS автоматически сохраняются в облачных службах Azure .
Доступ к файлам журнала с помощью удаленного рабочего стола для подключения к определенному серверу. Там файлы хранятся по пути, похожему на этот: C:Resourcesdirectory{какой-то случайный guid}.{имя приложения}.DiagnosticStoreLogFilesWebW3SVC{случайный номер}

Службы приложений Azure :

Убедитесь, что ведение журнала веб-сервера включено.
Настройте ведение журнала веб-сервера для сохранения в файловой системе.
Файлы расположены в папке: D:homeLogFileshttpRawLogs через консоль KUDU.

📡Как узнать расположение логов IIS с помощью PowerShell

В оболочке PowerShell введите:

Get-Website yoursite | % { Join-Path ($_.logFile.Directory -replace ‘%SystemDrive%’, $env:SystemDrive) «W3SVC$($_.id)» }

или

Get-Website yoursite | % { $_.logFile.Directory, $_.id }

или для всех сайтов

(Get-Website * | % { $_.logFile.Directory});ls $GetIISLogsW3SVC1*

Чтобы получить бонусные баллы, добавьте | iiк первой команде, которую нужно открыть в Проводнике, или | gciк просмотру содержимого папки.

Как удобно изучать логи IIS

Если использовать обычный блокнот для поиска информации в журналах Internet Information Services, то вы увидите, что это неудобно. Для более продуктивной работы я вам советую использовать бесплатную утилиту Log Parser. Я ее использовал уже для удобной работы с файлами формата log.

Где хранятся трассировки IIS

Если вы включите трассировки на сайте, то посмотреть соответствующие журналы можно по пути указанному в дополнительных свойствах сайта. Вам потребуется раздел «Failed Request Tracing«. В моем случае это:

%SystemDrive%inetpublogsFailedReqLogFiles

Как настроить расписание создания логов IIS

Если вы хотите настроить по какому расписанию должны создаваться журналы логов IIS, то вам это нужно сделать через диспетчер. Данная настройка делается, как на уровне всех сайтов, так и на уровне отдельного сайта. Найдите значок «Logging«.

В разделе «Log File Rollover» выберите один из следующих вариантов. Расписание: для создания нового файла журнала на основе одного из следующих значений:

Ежечасно (Hourly): новый файл журнала создается каждый час.
Ежедневно (Daily): каждый день создается новый файл журнала.
Еженедельно (Weekly): каждую неделю создается новый файл журнала.
Ежемесячно (Monthly): каждый месяц создается новый файл журнала.

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

Выберите «Использовать местное время для именования и смены (Use local time for file naming and rollover)» файлов журнала, чтобы указать, что для именования файлов журнала и времени смены файлов журнала используется время локального сервера. Если этот параметр не выбран, используется всемирное координированное время (UTC).

Как выбрать поля W3C для регистрации

Для того, чтобы сделать для себя нужный список полей, которые должны появляться в логах Internet Information Services. Вы должны на уровне сервера или сайта нажать кнопку «Select Fiels» в разделе «Format«

Дата (дата): дата, когда произошел запрос.
Время (время): время по всемирному координированному времени (UTC), когда был получен запрос.
IP-адрес клиента (c-ip): IP-адрес клиента, отправившего запрос.
Имя пользователя (cs-username): имя аутентифицированного пользователя, который получил доступ к вашему серверу. Анонимные пользователи обозначаются дефисом.
Имя службы (s-sitename): номер экземпляра сайта, выполнившего запрос.
Имя сервера (s-computername): имя сервера, на котором была создана запись в файле журнала.
IP-адрес сервера (s-ip): IP-адрес сервера, на котором была создана запись в файле журнала.
Порт сервера (s-port): номер порта сервера, настроенный для службы.
Метод (cs-метод): запрошенное действие, например, метод GET.
Основа URI (cs-uri-stem): универсальный идентификатор ресурса или цель действия.
Запрос URI (cs-uri-query): запрос, если таковой имеется, который пытался выполнить клиент. Запрос универсального идентификатора ресурса (URI) необходим только для динамических страниц.
Состояние протокола (sc-status): код состояния HTTP или FTP.
Подстатус протокола (sc-substatus): код подстатуса HTTP или FTP.
Состояние Win32 (sc-win32-status): код состояния Windows.
Отправлено байтов (sc-bytes): количество байтов, отправленных сервером.
Получено байтов (cs-bytes): количество байтов, полученных сервером.
Затраченное время (time-taken): продолжительность действия в миллисекундах.
Версия протокола (cs-версия): версия протокола, которую использовал клиент.
Хост (cs-host): имя хоста, если есть.
Пользовательский агент (cs(UserAgent)): тип браузера, который использовал клиент.
Cookie (cs(Cookie)): содержимое отправленного или полученного файла cookie, если таковой имеется.
Referrer (cs(Referrer)): сайт, который последний раз посещал пользователь. Этот сайт предоставил ссылку на текущий сайт.

Как очищать старые логи IIS

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

Дополнительные ссылки

https://learn.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/configure-logging-in-iis
https://learn.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/managing-iis-log-file-storage

Источник

I’m trying to set up an application from a third party, which requires a supporting website hosted in my local IIS. I’ve created a website exactly as explained in their install guide, but am having some problems, and would like to see what the IIS log has to say. Embarrassingly enough, the problem is I can’t find the log files!

So my question is: Where does IIS7 store logs by default?

asked Jun 21, 2011 at 13:49

I think the default place for access logs is

%SystemDrive%inetpublogsLogFiles

Otherwise, check under IIS Manager, select the computer on the left pane, and in the middle pane, go under «Logging» in the IIS area. There you will se the default location for all sites (this is however overridable on all sites)

You could also look into

%SystemDrive%WindowsSystem32LogFilesHTTPERR

Which will contain similar log files that only represents errors.

answered Jun 21, 2011 at 13:51

jishijishi

24k6 gold badges49 silver badges75 bronze badges

I believe this is an easier way of knowing where your IIS logs are, rather than just assuming a default location:

Go to your IIS site, e.g. Default, click on it, and you should see «Logging» to the right if logging is enabled:

Open it and you should see the folder right there:

You are welcome!

answered Jan 19, 2016 at 11:51

RafidRafid

18.8k23 gold badges72 silver badges107 bronze badges

I’m adding this answer because after researching the web, I ended up at this answer but still didn’t know which subfolder of the IIS logs folder to look in.

If your server has multiple websites, you will need to know the IIS ID for the site. An easy way to get this in IIS is to simply click on the Sites folder in the left panel. The ID for each site is shown in the right panel.

Once you know the ID, let’s call it n, the corresponding logs are in the W3SVCn subfolder of the IIS logs folder. So, if your website ID is 4, say, and the IIS logs are in the default location, then the logs are in this folder:

%SystemDrive%inetpublogsLogFilesW3SVC4

Acknowlegements:

Answer by @jishi tells where the logs are by default.
Answer by @Rafid explains how to find actual location (maybe not default).
Answer by @Bergius gives a programmatic way to find the log folder location for a specific website, taking ID into account, without using IIS.

answered Feb 26, 2016 at 19:08

Joel LeeJoel Lee

3,6361 gold badge18 silver badges21 bronze badges

The 100% correct answer for the default location of the log files is…

%SystemDrive%inetpublogsLogFiles

Yes you can enter this into the explorer address bar it’ll work.

To be 100% sure, you need to look at the logging for the web site in IIS.

https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-85/enhanced-logging-for-iis85

i.e.

Open IIS Manager.
Select the site or server in the Connections pane,
Double-click Logging.
The location of log files for the site can be found within the Directory field

EDIT: As pointed out by Andy in the comments below you need to ensure when installing IIS that you elected to enable HTTP logging, otherwise HTTP logging won’t be available.

answered Nov 5, 2014 at 7:15

MickMick

6,4374 gold badges51 silver badges67 bronze badges

A much easier way to do this is using PowerShell, like so:

Get-Website yoursite | % { Join-Path ($_.logFile.Directory -replace '%SystemDrive%', $env:SystemDrive) "W3SVC$($_.id)" }

or simply

Get-Website yoursite | % { $_.logFile.Directory, $_.id }

if you just need the info for yourself and don’t mind parsing the result in your brain :).

For bonus points, append | ii to the first command to open in Explorer, or | gci to list the contents of the folder.

answered Jul 3, 2015 at 14:45

BergiusBergius

9496 silver badges14 bronze badges

Try the Windows event log, there can be some useful information

answered Jun 21, 2011 at 13:51

Tomas WalekTomas Walek

2,5082 gold badges23 silver badges37 bronze badges

Enabling Tracing may be a better alternative to the Windows Event Log. This gave me the information I needed to fix my own WebService.

answered Aug 26, 2014 at 19:25

Preston SPreston S

2,74123 silver badges37 bronze badges

I think the Default place for IIS logging is: c:inetpubwwwrootlogw3svc

Kjartan

18.5k15 gold badges71 silver badges94 bronze badges

answered Jun 17, 2014 at 8:35

honeyhoney

1998 bronze badges

I have found the IIS Log files at the following location.

C:inetpublogsLogFiles

which help to fix my issue.

answered Dec 2, 2017 at 4:47

Hiren ParghiHiren Parghi

1,7951 gold badge20 silver badges30 bronze badges

C:inetpublogsLogFiles

Check the identity of the site going to sites and advanced settings

answered May 28, 2019 at 15:20

chandrachandra

1111 gold badge1 silver badge8 bronze badges

The simplest answer is to query like this:

(Get-Website * | % { $_.logFile.Directory});ls $GetIISLogsW3SVC1*

If you have more than one site you will get more than one answer, so you need to query with a ‘foreach’ to get the website name with the directory…

answered Aug 5, 2022 at 16:03

Источник

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

Справка. Event Tracing for Windows (ETW) – высокопроизводительная система журналирования, представленная еще в Windows Vista. Системные компоненты и пользовательские приложения при помощи специального API могут отправлять этой системе сообщения о своем состоянии (логи). Система ETW генерирует сравнительно небольшую нагрузку, так, например запись информации о 10000 событий за секунду через службу трассировки займет всего порядка 3% процессорных ресурсов. Система ETW не заменяет обычный журнал событий и служит обычно для непродолжительной по времени диагностики работы приложений или системы.

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

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

Примечание. Опция Logging будет доступна только при установленном компоненте IIS: HTTP Logging (Web Server -> Health and Diagnostics -> HTTP 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.

Источник

Download Article

This wikiHow teaches you how to find a list of all the saved log files for IIS (Internet Information Services) events on your computer, and view an event’s recorded logs, using Windows.

1
Click the search button on your computer’s taskbar. This button looks like a white magnifier icon next to the Start menu in the lower-left corner of your screen.
- If you’re using Cortana, this button will look like a white circle.
2

Enter Event Viewer into the search. This will list all the matching results as you type.

Advertisement
3

Click Event Viewer in the search results. Your Windows system’s stock Event Viewer app should show up at the top of the results. Clicking will open it in a new window.
4

Click the

icon next to the Windows Logs folder. You can find this folder on the Event Viewer’s left sidebar. It will expand log categories below the folder name.
5

Click Application below Windows Logs on the sidebar. This will list all the application logs on the right-hand side of the Event Viewer window.
6
Click the Source heading at the top of the list. The Event Viewer is organized by columns like Level, Date and Time, Source, and Event ID at the top. Click Source here to put the list in alphabetical order according to log source.
- You will see «IIS» in the Source column for all IIS events.
7

Double-click an IIS event log on the list. When you find the event you want to check, double-click on it to see the recorded log.

Ask a Question

200 characters left

Include your email address to get a message when this question is answered.

Submit

Thanks for submitting a tip for review!

About This Article

Article SummaryX

1. Click the search or Cortana on the bottom-left.
2. Search and open Event Viewer.
3. Expand Windows Logs on the sidebar.
4. Click Application.
5. Click the Source tab.
6. Find and double-click an IIS event to view the log.

Did this summary help you?

Thanks to all authors for creating a page that has been read 52,876 times.

Is this article up to date?

Источник

Unresponsive and slow pages are both terrible for any website. Even with the best user interface (UI), unresponsive and slow pages negatively affect the customer experience and the brand’s reputation.

Research from the Nielsen Norman Group has determined that the average user will leave a site after about 10 seconds of waiting for a page to load. If your page takes longer than a few seconds to load, it’s time you check your IIS server logs. Let’s dive in to the what and why of IIS server logs so you can approach and debug your page loading issues easily.

Everything gets captured

As we all know, Internet Information Services (IIS) is the native webserver for hosting websites on Windows platforms and is comprised of several components to effectively handle requests. From a DevOps view, the most useful output comes from the logs that IIS generates. IIS access logs in particular capture all kinds of access to a web application including page visits, client IPs, browsers (both type and version), response times, error requests, and traffic.

1. IIS access logs

i. Is your page still loading?

High response time is the most common indication that there is a bottleneck throttling website performance. IIS handles a huge number of requests by queuing them in the respective application pools, and when some requests take too long, it will increase the wait time for other requests. If the request queue becomes full, then there is a high chance that the server itself will become unavailable.

This is why it’s vital to optimize the response time of the whole website in order to maintain high availability. In this case, IIS access logs are your go-to, as they keep track of the final response time, which is helpful when debugging URLs that are slow and need to be optimized.

ii. What went wrong with your site?

A small error in a webpage is capable of significantly degrading the end-user experience. When a URL fails, IIS on an average takes around 30 to 120 seconds to send a connection time-out message, during which time impatient users will leave and more patient users will keep retrying for the response.

A typical 4xx/5xx error can degrade customer trust quickly. IIS access logs provide a quick overview of URLs, allowing you to trace the sequence of the URLs accessed and the relevant browser information necessary to reproduce issues locally and fix them. For instance, when your page is not loaded and throws an error code of 400, you can find out from the IIS access logs that it is a bad request error and the page hasn’t been accessed.

Check this video to learn how to use AppLogs query language search to get insights from IIS access logs.

2. IIS error logs

Still no help?

Have all your attempts to debug issues from the IIS access logs ended in vain? Though IIS access logs work the best in identifying problematic URLs, deep diagnosis requires contextual information like request parameters, form data, cookies, modules loaded, and problematic modules.
HTTPERR, the IIS error log, stores all the information related to IIS errors such as the requests that weren’t made, idle IIS servers, disabled services, forbidden severs, and more. Considering the example of error 400 mentioned in the previous section, though it’s a client error response, the issue can be anywhere on the client-side or server-side.
IIS error logs can identify the exact point of an issue such as invalid data parsed, incorrect data parsed like a wrong URL, corrupted data, or duplicate cookies. You can also analyze error logs from different servers that run the application in production.

3. IIS-related Windows event logs

Crack the exact issue

Windows Event logs capture a lot of details about the error, and present a quick trace of the root cause, whether it’s a full memory, CPU, or stack-overflow error, or even a third-party module that crashed your application. IIS access logs enable you to identify the problematic URLs, and error logs provide the context of the error. With the timeline and context provided by these two types of logs, and after filtering out the event logs, you’ll be able to narrow down the root cause of the issue quickly. This means for the 400 error, you can identify the root cause using Windows Event logs.

You can also work the other way around. Start filtering out event logs, and build context by searching through the access and error logs in order to reproduce an issue and fix it. The former is effective in identifying the overall areas of improvement, while the latter is a remedial measure to provide quick fixes.

Simplify debugging

Manual debugging from different logs is time-consuming and tedious, but a comprehensive log management tool can make it easy.

Complimenting log management is an Application Performance Monitoring (APM) solution which can consolidate the available access log information like response time, throughput, etc., and correlate it well with the information available in the event logs like the stack trace, error codes, etc. APM solutions offer continuous monitoring and thus, issues and their root causes can be identified instantly. Having a log management tool that can integrate well with APM solution, i.e., one which allows querying traces of slow transactions and exceptions, will be a great boost to DevOps productivity.

A good log management tool should offer the following features:

Collection and consolidation: Collect logs from different applications, servers, and log frameworks, and consolidate them for easy analysis.
Indexing: Index the logs for a quicker search.
Simple search: Leverage easy-to-search methods like query language search.
Save the search: Save searches for future reference.
Alerts: Save search queries and configure alerts based on these searches.
Storage: Store the collected logs for future reference and analysis.
Holistic view: A consolidated, intuitive dashboard to view everything in one place.
Organized metrics: View top failed requests and errors for a quick overview.

Site24x7 AppLogs is a log management and analytics module that can help you manage your logs from different environments with all the above-mentioned features. Try our 30-day free trial, now!

You may also be interested in:

Everything you need to monitor a website
Application Performance Monitoring: Trends to Watch Out in 2020

Источник