Логи iis где лежат

IIS — О ведении журналов узлов

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

Процесс ведения журнала

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

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

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

Форматы файлов журнала

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

Файлы в расширенном формате журнала W3C, в формате журнала Microsoft IIS и в формате журнала NCSA являются текстовыми файлами в кодах ASCII. Расширенный формат W3C и формат NCSA записывают данные в журнал с использованием четырехзначного года. Формат Microsoft IIS использует две цифры для записи года, что обеспечивает обратную совместимость с предыдущими версиями IIS. Можно также создать специальный формат записей журнала, содержащий требуемые поля.

Расширенный формат файла журнала W3C

Расширенный формат W3C представляет собой настраиваемый формат в кодах ASCII, включающий множество различных полей. Можно включить в журнал важные поля и опустить нежелательные, ограничивая размер файла журнала. Поля разделяются пробелами. Времена записываются с использованием времени по Гринвичу (GMT). Сведения о настройке этого формата см. в разделе Настройка расширенного формата журнала W3C. Дополнительные сведения о спецификации расширенного формата W3C см. на узле компании W3C http://www.w3.org.

В следующем примере демонстрируются строки из файла с отобранными полями: «Время», «IP-адрес клиента», «Метод», «Ресурс URI», «Состояние HTTP» и «Версия HTTP».

Предшествующая запись сообщает, что 2 мая 1998 г. в 17:42 по Гринвичу пользователь с установленной версией HTTP 1.0 и IP-адресом 172.16.255.255 выдал команду GET (загрузка) для файла Default.htm. Запрос был возвращен без ошибки. Поле #Date: показывает время, когда было сделано первое подключение; оно совпадает со временем создания журнала. Поле #Version: показывает какой формат журнала W3C используется.

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

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

Формат Microsoft IIS является фиксированным (не настраиваемым) форматом в кодах ASCII. В этом формате записывается больше данных, чем в общем формате NCSA. Формат Microsoft IIS содержит основные элементы, например, IP-адрес пользователя, имя пользователя, дату и время запроса, код состояния HTTP и число полученных байт. Кроме этого он включает дополнительные сведения, такие как затраченное время, количество отправленных байт, действие (например, загрузка с помощью команды GET) и файл назначения. Разделителем элементов служит запятая, что делает этот формат более удобным для обработки, чем другие текстовые форматы, в которых в качестве разделителя используется пробел. Время регистрируется по местному часовому поясу.

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

Интерпретация этих записей приводится в следующих таблицах. Верхняя строка в обеих таблицах относится к веб-узлу (который представлен в столбце «Служба» как W3SVC), нижняя строка относится к узлу FTP (который представлен в столбце «Служба» как MSFTPSVC). Пример анализируется в двух таблицах из-за ограничений по ширине страницы.

IP-адрес пользователя	Имя пользователя	Дата	Время	Служба и образец	Имя компьютера	IP-адрес сервера
—

Заняло времени	Получено байт	Отправлено байт	Код состояния службы	Код состояния Windows 2000	Тип запроса	Объект операции

В предыдущем примере первая запись означает, что анонимный пользователь с IP-адресом 192.168.114.201 выдал команду GET (загрузка) для файла изображения DeptLogo.gif в 7:55 20 марта 1998 г. с сервера с именем SALES1 и IP-адресом 172.21.13.45. Для выполнения запроса HTTP с размером 163 байт потребовалось 4502 миллисекунды (4,5 секунды). Анонимному пользователю возвращено 3223 байт данных без ошибки.

В файле журнала значения всех полей заканчиваются запятой (,). Дефис печатается как прототип для полей, не имеющих допустимого значения.

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

Общий формат файла журнала NCSA представляет фиксированный (не настраиваемый) формат ASCII, поддерживаемый веб-узлами и не поддерживаемый узлами FTP. В этом формате записываются основные сведения о запросах пользователей, такие как имя удаленного обслуживающего компьютера, имя пользователя, дата, время, тип запроса, код состояния HTTP и количество байт, полученных сервером. Разделителем элементов служит пробел; время регистрируется по местному часовому поясу.

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

Примечание. В предыдущей записи второе поле (соответствующее имени пользователя, который вошел через удаленный доступ) является пустым и представляется дефисом после IP-адреса 172.21.13.45.

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

Имя удаленного узла	Имя пользователя	Дата	Время и смещение относительно GMT

Тип запроса	Код состояния службы	Отправлено байт

Запись означает, что пользователь Fred в домене REDMOND с IP-адресом 172.21.13.45 выдал команду GET (загрузка файла) в 17:39 8 апреля 1998 г. В результате запроса пользователю Fred возвращено 3401 байт данных без ошибки.

Журнал ODBC

Формат журнала ODBC представляет собой запись из фиксированного набора полей в ODBC-совместимой базе данных, например Microsoft Access или Microsoft SQL Server. Записываются, в частности, IP-адрес пользователя, имя пользователя, дата и время запроса, код состояния HTTP и количество полученных байт; количество отправленных байт, выполненное действие (например, загрузка с помощью команды GET) и получатель (например, загружаемый файл). Время регистрируется по местному часовому поясу. Чтобы использовать эту возможность, необходимо указать базу данных, в которой будет вестись журнал, и настроить базу данных для получения данных.

Чтобы использовать журнал ODBC необходимо выполнить следующие действия:

1. Создать базу данных, содержащую таблицу с соответствующими полями для регистрации данных. IIS включает файл шаблона SQL, который может быть запущен в базе данных SQL для создания таблицы, получающей записи от IIS. Файл называется Logtemp.sql и находится в каталоге \IISRoot. Если были приняты значения по умолчанию, предлагаемые программой установки, каталог \IISRoot находится в каталоге \WindowsNT\System32. Необходимы следующие поля:
   

   Имя поля	Тип поля
   ClientHost	varchar(255)
   Username	varchar(255)
   LogTime	datetime
   Service	varchar(255)
   Machine	varchar(255)
   ServerIP	varchar(50)
   ProcessingTime	int
   BytesRecvd	int
   BytesSent	int
   ServiceStatus	int
   Win32Status	int
   Operation	varchar(255)
   Target	varchar(255)
   Parameters	varchar(255)

2. Введите имя системного источника данных для базы данных, которое программное обеспечение ODBC использует для поиска базы данных. Дополнительные сведения см. в документации по Windows 2000.
3. Сообщите IIS имя базы данных и таблицы. Если для доступа к базе данных требуется имя пользователя и пароль, их также следует указать в IIS.

Учет использования ресурсов

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

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

Собранные сведения могут быть использованы для принятия решения о включении регулирования процесса на веб-узле. Регулирование процесса ограничивает процессорное время, используемое веб-узлом. Дополнительные сведения см. в разделе О загрузке процессора.

Размер файла журнала и создание новых файлов журнала

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

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

Файлы журнала представляют собой текстовые файлы (в кодах ASCII). Если было создано много файлов небольшого размера, а предпочтительно иметь один большой файл, их можно объединить, как и любые текстовые файлы. Для получения сведений об объединении файлов с помощью команды copy введите в командную строку copy ?

Если при попытке добавить запись в журнал IIS на сервере кончается свободное место на диске, ведение журнала IIS отключается. Одновременно записывается событие в журнал приложений окна просмотра событий Windows. При освобождении пространства на диске ведение журнала IIS возобновляется. Это вызывает фиксацию еще одного события в журнале приложений окна просмотра событий Windows.

Имена файлов журнала

Первые буквы в именах файлов журналов представляют формат журнала, а следующие за ними цифры период ведения или порядковый номер журнала. Подробные сведения собраны в таблице, приведенной ниже. Записанные курсивом буквы представляют следующие значения: nn — последовательные числа, yy — год, mm — месяц, ww — неделя месяца, dd — день, hh — час в 24-часовом формате.

How to Configure Logging in IIS Windows Server 2012

In this How-To, we will walk you through to Configure Logging in IIS Windows Server 2012.

This feature is set up to store data HTTP request and errors from your website(s) and of your Web Server. Configuring this feature will make your site troubleshooting much easier because you will have logs that serve as a starting point.

Prerequisites

– A Server with Windows Server 2012. If you do not have a server already, why not spin up a virtual private server from Atlantic.Net in under 30 seconds.

– Internet Information Services(IIS) installed on your server. If you need to install IIS, follow our guide Install IIS On Windows Server 2012 R2.

Configure Logging in IIS

Initially, you want to access the IIS Manager to configure “Logging” on Windows Server 2012 following the following path:

Open the Server Manager / Select Local Server/Under “All Servers” select “IIS”/ Right Click on your server and select the “Internet Information Services (IIS) Manager” option.

Select IIS Manager in your Server Manager Dashboard

You will now be taken to the Internet Information Services (IIS) Manager” where you will see a Connections panel to the left side of your screen. There is a folder named “Sites” with a drop down arrow, and you can view all your sites that are available. Select your site and select the “Logging” option from the sites Home options.

Select Logging in the IIS Manager page

Logging Page

You will be taken to the-the Logging page to configure some settings. Under Log file/ Format. Select one of the following log formats:

• IIS – uses the Microsoft IIS log file format.
• NCSA – uses the National Center for Supercomputing Applications common log file format.
• W3C – uses the centralized W3C log file format.
• Custom – use a customer logging module/file format.

Directory Section

Specify the location where the log file will be stored in the Directory section. It should be set to the default path shown below.
%SystemDrive%\inetpub\logs\LogFiles

Note: It is recommended that all the log files that will be stored on your system be stored in any directory except the systemroot directory.

Log File Rollover Section

Additionally, there is a “Log File Rollover” section. This is where you can select a schedule and how the new files are created selecting one of the following options:

• Hourly
• Daily
• Weekly
• Monthly
• Maximum file size (in bytes)
• Do not create a new log file

Further more, its recommended that you select “Use local time for file naming and rollover” to achieve a more accurate log reading based on your current server’s time stamp. If you do not select the “Use local time for file naming and rollover” option, the system will use the Coordinated Universal Time (UTC) to archive the file. You will then have to convert the UTC format to your local format when its time to review the logs.

You will then finalize your configuration by saving all your information by clicking “Apply” in the “Actions panel.

Applying your settings in the Actions Panel

Congratulations! You have just Configured Logging in IIS Windows Server 2012. Thank you for reading! Be sure to check back for more updates, and to learn more about our VPS hosting solutions.

Free Tier Includes:
G3.2GB Cloud VPS Free to Use for One Year
50 GB of Block Storage Free to Use for One Year
50 GB of Snapshots Free to Use for One Year

Looking for a Hosting Solution?

We Provide Cloud, Dedicated, & Colocation.

• Seven Global Data Center Locations.
• Flexible Private, Public, & Hybrid Hosting.
• 24x7x365 Security, Support, & Monitoring.

Get started with 12 months of free cloud VPS hosting

Free Tier includes:
G3.2GB Cloud VPS Server Free to Use for One Year
50 GB of Block Storage Free to Use for One Year
50 GB of Snapshots Free to Use for One Year

Three ways to debug IIS web server failures using logs

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.

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!

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

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

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

задан 21 июн ’11, 10:06

10 ответы

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

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

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

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

ответ дан 07 окт ’15, 20:10

Спасибо, это кажется логичным, но каталог журналов пуст. Мне, вероятно, нужно как-то включить ведение журнала, но я ничего не могу найти о ведении журнала на средней панели в диспетчере IIS. — Кьяртан

Если вы его не найдете, значит, он не установлен. Вам нужно загореться Programs and Features затем нажмите Turn Windows features on or off слева, затем выберите Internet Information Services\World Wide Web Services\Health and Diagnostics\HTTP Logging — дзиси

Превосходно! По крайней мере, теперь у меня есть логи. Жаль, что они не дали мне ответов, на которые я надеялся, но, по крайней мере, я кое-что узнал. Спасибо еще раз! — Кьяртан

Я считаю, что последний путь (. \ HTTPERR) — это место, куда по умолчанию попадают файлы журнала, созданные http.sys, а не файлы журнала из самого IIS. Видеть: technet.microsoft.com/en-us/library/cc784703%28v=ws.10%29.aspx — Джон Шнайдер

Эти журналы бесполезны, если вы ищете сообщение об ошибке. — Васил Валчев

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

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

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

В IIS10 для функции «Ведение журнала» требуется, чтобы как минимум World Wide Web Services -> Health and Diagnostics -> HTTP Logging функция Windows установлена. В противном случае он не появится. — Паси Саволайнен

Что делать, если значок журнала не появляется? Я не могу найти свои файлы журналов локально — похоже, ни один из путей не существует на моем компьютере. — Энди

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

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

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