Accessing the logs
Now that the logging is configured you can try to take a look at the log files after making sure you had some activity on the web site since the logging was enabled. In the Actions panel of the Logging configuration section you can click on View log files…
Well after doing that you may get the following error:
This is because by default only Administrators are allowed to access the IIS log folder and as with the UAC (User Account Control) you are really administrator only once the privilege elevation occurs you get this error. To work around that, you can go to the folder with the Windows Explorer and change the permissions.
The short way would be to just try to enter in the folder c:\intetpub\logs with the Windows Explorer and when you get the following message click Continue.
Then you need to repeat the operation on the child folder containing the log files c:\intetpub\logs\LogFiles\W3SVC1 because permissions are not inherited.
By doing that your account would automatically get read and write permissions on the log folder. If for security reasons you don’t want to have write permissions because you only need to read the logs, you can apply the following procedure:
- Right click on the c:\intetpub\logs folder
- Select the Security tab
- Click Advanced
- And then click the Continue button to trigger the privilege elevation
You see then the permissions on the logs folder and you are allowed to change them. Click on the Add button to add an entry for your own account or a group your account is member of.
In the permission entry keep only read permissions selected and click OK to add the entry to the list.
Then you can apply the permissions. But if you do that, you will see that you need to apply again the same procedure on the web site log sub folder (C:\inetpub\logs\LogFiles\WC3SVC1) because permissions are not inherited. To avoid that you can optionally select “Replace all child permissions…” before applying the permissions.
Independently of the method used to change the permissions you can now access the folder where the log files are located without privilege elevation needed and this is what you see in the log folder.
And if you open one of the log files, this is how the content looks like:
And if we scroll to the right we see our custom Content-Type field with the MIME type as expected.
OK!Now that we know how to enable and configure the http logging in IIS and that we can access these logs locally on the web server we will see in a next article how it’s possible to share these logs in order to retrieve them remotely.
Question 1: Is my IIS site providing a good quality of service?
I like to answer this question with a single, simple metric we at LeanSentry call “Satisfaction score”. It’s roughly equivalent to the Apdex standard used by many other APM tools.
I blogged about this score way back in 2013 when we first released LeanSentry, and 30K websites later, it’s still the main IIS metric we monitor today.
(Check out the blog post for the rationale as to why it beats “avg. response time” or “95th percentile latency” approaches when it comes to whole-site quality of service monitoring.)
The satisfaction score is a simple percentage. If your site has a 100% satisfaction score, that means that your workload is 100% successful and meets the target response time SLA. If you have slow or failed requests, they will penalize your score.
| Metric | Formula | Definitions |
| Satisfaction score | SAT Score = (FAST requests — FAILED requests — SLOW requests — (SLUGGISH requests / 2)) / TOTAL requests |
TOTAL: all requests
FAST: requests completed under response time SLA (e.g. under 2 seconds) SLUGGISH: requests completed between 1x-4x the SLA (e.g. 2-8 seconds) SLOW: requests completed >4x the SLA (e.g. 8+ seconds) FAILED: requests that fail with an error. |
A great property of this score is that it is both not skewed by outliers, AND it considers ALL requests unlike an average or statistical aggregate metric.
In other words:
-
A single request taking 2 hours to complete will not skew your score any more than a single request that takes 10s (if both are considered too long per your SLA).
- If 2% of your requests are taking too long, in the absence of other issues, you will roughly have a 98% score. These 2% of slow requests or failures will NOT be hidden from your view even if your avg. latency or 95% percentile response time is excellent.
So, I will first measure your satisfaction score to know (a) is your site providing a good service level overall and (b) did it have specific incidents where the service level dropped? We can then dig into service level drops to identify opportunities to improve your site.
Computing the satisfaction score for your IIS website
A comment on my original blog post noted that while this score seems appealing, it’s hard to implement because of lack of tools to report this metric.
Indeed, building this reporting was a big part of LeanSentry’s approach to monitoring IIS websites.
However, it turns out that it is very possible to compute a basic satisfaction score using your existing IIS logs!
(And with the enhancements we give further in this guide, it’s possible to get the score to a fully workable level!)
So with that in mind, let’s compute your website’s satisfaction score using your IIS logs:
-- Select components of satisfaction score select COUNT(*) AS TOTALREQUESTS, SUM(CASE DIV(sc-status,399) WHEN 0 THEN 0 ELSE 1 END) AS FAILEDREQUESTS, SUM(CASE DIV(time-taken,2000) WHEN 1 THEN 1 WHEN 2 THEN 1 WHEN 3 THEN 1 ELSE 0 END) AS SLUGGISHREQUESTS, SUM(CASE DIV(time-taken,8000) WHEN 0 THEN 0 ELSE 1 END) AS SLOWREQUESTS, -- SAT score: ROUND(DIV(TO_REAL(MUL(SUB(SUB(SUB(TOTALREQUESTS, FAILEDREQUESTS), SLOWREQUESTS), DIV(SLUGGISHREQUESTS,2)),100)), TO_REAL(TOTALREQUESTS))) AS SATSCORE FROM C:\inetpub\logs\LogFiles\W3SVC2\*.log
This uses the SLA time of 2 seconds. We’ll look at how to customize the SLA times for different URLs and requests at the end in enhance your IIS logs.
Example results:
Using this query, I can immediately tell that our site has a lower-than-desired SAT score of 82%, which means that roughly 18% of the traffic was not successful. That definitely needs work.
In particular, I know that the bulk of this problem comes from failed requests, so I can fix this by identifying the errors and fixing them (we’ll get into that shortly). I also see that we have some slow and sluggish requests, and we’ll look at breaking those down as well.
Configuration
First you need to launch the IIS manager from the Windows Administration tools. Then in the IIS manager select the root of your web site and check that you see the Logging item.
If you don’t see it, it probably means that the required Windows feature was not installed. So you need to install it with the Server manager. The name of the feature is HTTP Logging in the sub category Web server/Health and Diagnostics.
Once you entered the Logging section, verify that Disable appears in the Action panel, meaning that the logging is enabled. If Enable is displayed instead, you need to click on it to enable the logging.
Once this is OK you may also check that the setting is inherited in child web applications. Sometimes it is not.
Then you can check which fields are selected to be included in the log files by clicking on the Select fields button.
Most fields are selected by default but a few interesting fields may not be selected.
This is the case of the Cookie field. In this field you will see tracking numbers stored in cookies. For example you will see the ASP.NET session ID and the PHP session ID in this field. This will allow you to follow the web page access history from a single internet user even if several users are behind the same IP address.
The Referer field is very important and is only selected by default since Windows 2012 so make sure it is also selected if you want to know from where come your visitors.
The fields Bytes Sent and Bytes Received fields may also be interesting to determine which URLs of your web site consume much bandwidth.
The Host field is less important as you will have in most cases systematically the same host but it allows to construct the full accessed URL (“http//” +Host + URI Stem + URI query).
In any cases let all fields which are selected by default selected. They are essential to any analysis. You will find a description of all these fields in the article Select W3C Fields to Log of the Microsoft TechNet.
So we covered standard HTTP logging fields but since IIS 8.5 (Windows 2012 R2) there is also the ability to add custom fields. Most of the proposed custom fields are in generally not interesting because too advanced but let’s try to add an interesting one.
We click on the Add Field button below the custom fields list.
In the Add Custom Field dialog we can browse all proposed fields by changing the Source type and by taking a look at the proposed sources. With Response Header as source type we have a source named Content-Type. We can suppose that this is the MIME type of the content send back to the web browser. This could be interesting if we need to ignore in the logs all requests to a specific kind of content. So let’s add it. We specify Content-Type as field name and we click OK.
Our new custom field then appears in the list and we can click OK to apply our new field selection.
If you go down in the Logging section you will see that there is a section named Log file Rollover.
By default IIS stores the logs in a new file every day. I recommend keeping this default setting. The only exception I see is that the latest log file currently being written may not be retrievable remotely through ftp (We’ll cover this in a next article) because the file is opened by IIS. So if you need to get the data sooner than waiting the next day you can switch the schedule to Hourly.
OK, now that we looked at the most interesting logging settings in IIS you can click Apply in the Actions panel to save all changes.
Приоритет сообщений в логах
Как rsyslog так и joirnald имеют одну общую штуку, касающуюся ведения логов. Это приоритет сообщений. Логи в системе генерируются в зависимости от типа события, а это событие, в свою очередь, имеет определенную степень критичности. Вот в зависимости от этой критичности, событию присваивается определенный приоритет. Знать типы приоритетов, совсем не лишнее, будет немного проще разбирать логи Linux.
Типы приоритетов:
emerg — наивысший приоритет, что-то сломалось, повод паниковать;
alert — тревога, стоит волноваться;
crit — критическое событие, нужно насторожиться;
err — ошибка, надо напрячься;
warning — внимание, нужно не терять бдительность;
notice — уведомление, можно не заморачиваться;
info — информационное сообщение, принять к сведению и забыть;
debug — отладочная информация, вообще пофиг;
Мы можем использовать их для просмотра логов, фильтруя информацию по конкретному приоритету.
Например:
Или в случае с journalctl:
Ну, а на этом наше знакомство с логами можно считать оконченным. Мы конечно рассмотрели здесь только самые важные моменты, но на то оно и знакомство, что бы узнать азы, а глубже уже изучать самостоятельно. Если в этом есть необходимость, конечно. Потому что, описанного в этой статье, как по мне, вполне достаточно обычному пользователю, чтобы комфортно чувствовать себя при работе с логами. Ну и свой баф к линуксоидности ты сегодня получил. Потому не забывай возвращаться к нам, ведь есть ещё много тем которые стоит изучить.
Твой Pulse.
IRP-система штатными средствами Windows
Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.
Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант «При событии», а в открывшейся форме отображения установить radio-button «Настраиваемое». После этих действий появится кнопка «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.
Например, если мы хотим выполнять некоторую команду или скрипт при каждом интерактивном входе в систему пользователя Username, мы можем задать в качестве триггера задачи следующее поисковое выражение, уже знакомое нам по примеру выше:
Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:
Установка и запуск Web-сервера
Для того, чтобы запустить IIS на компьютере с установленной Windows, необходимо произвести следующую последовательность действий (на примере Windows 7):
Рис.3
Удостовериться в том, что веб-сервер заработал, можно забив в адресной строке любого браузера строку вида «http://localhost» и получив картинку, как на Рис.4.
Рис.4
Рис.6.
Выбрав конкретную, только что опубликованную базу в списке, необходимо активировать утилиту «Сопоставление обработчиков» (Рис.7). Рис.7
В нашем случае нам понадобится установить соответствие между ISAPI-dll и исполняемым файлом wsisapi.dll, находящимся в папке BIN, установленной версии платформы.
В принципе, на этом основную часть работы с сервером можно считать завершенной, переходим непосредственно к публикации базы.
Установка Web сервера IIS 10
Итак, давайте переходить к рассмотрению процесса установки, и для примера давайте просто установим основные компоненты, которые необходимы для функционирования веб сервера и его администрирования (средства управления), а также разместим на нем простую HTML страничку, т.е. по сути HTML сайт, для проверки работы web сервера. Если Вам необходимо размещать приложения, например на ASP.NET, то Вам необходимо также установить соответствующие службы роли из раздела «Разработка приложений».
Установка веб сервера IIS с помощью мастера
Сначала давайте разберем процесс установки web сервера IIS 10 с помощью «Диспетчера серверов», а конкретней «Мастера добавления ролей и компонентов».
Шаг 1
Открываем диспетчер серверов «Пуск ->Диспетчер серверов».
Затем запускаем «Мастер добавления ролей и компонентов», меню «Управление ->Добавить роли и компоненты».
Шаг 2
Затем жмем «Далее».
Шаг 3
Потом выбираем тип установки «Установка ролей или компонентов», жмем «Далее».
Шаг 4
Затем выбираем целевой сервер и жмем «Далее».
Шаг 5
На шаге выбора ролей отмечаем роль «Веб-сервер (IIS)». Автоматически Вам сразу предложат установить компонент «Консоль управления службами IIS», мы соглашаемся и жмем «Добавить компоненты».
И сразу жмем «Далее».
Шаг 6
Все необходимые компоненты мы уже отметили, поэтому на этом шаге также сразу жмем «Далее».
Шаг 7
Теперь нам необходимо настроить установку роли «Веб-сервер IIS», сначала жмем «Далее».
А потом выбираем необходимые службы роли, по умолчанию минимальное количество служб уже будет выбрано, но если Вам нужно что-то еще, то отмечаете их галочкой. Для нашей тестовой задачи, т.е. разместить простой статический HTML сайт, отмеченных по умолчанию служб будет достаточно, жмем «Далее».
Шаг 8
Проверяем выбранные роли, службы и компоненты и жмем «Установить».
Установка будет завершена, как появится соответствующее сообщение.
Установка web сервера IIS с помощью Windows PowerShell
Для того чтобы установить web сервер IIS с помощью PowerShell запускайте оболочку Windows PowerShell и вводите следующие команды (перечисленные ниже команды установят все те же службы, которые мы установили с помощью мастера чуть выше).
Документ по умолчанию
Install-WindowsFeature -Name "Web-Default-Doc"
Обзор каталога
Install-WindowsFeature -Name "Web-Dir-Browsing"
Ошибки http
Install-WindowsFeature -Name "Web-Http-Errors"
Статическое содержимое
Install-WindowsFeature -Name "Web-Static-Content"
Фильтрация запросов
Install-WindowsFeature -Name "Web-Filtering"
Ведение журнала http
Install-WindowsFeature -Name "Web-Http-Logging"
Сжатие статического содержимого
Install-WindowsFeature -Name "Web-Stat-Compression"
Консоль управления службами IIS
Install-WindowsFeature -Name "Web-Mgmt-Console"
Включение протоколирования в 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 Log File Format
IIS write log to the files. There is a fixed format in which the data is written to these log files. As discussed in the previous section the fields to be logged can be configured and also you can select the format for the log file. The W3C Extended format, IIS log format, and NCSA format are all ASCII text formats (unless UTF-8 is enabled for your Web sites).
The W3C IIS log file format allows you to select the fields you want to log for each request. The W3C file is a space-delimited file format and empty fields i.e. fields with no value will be displayed using the hyphen (-). Shown below is the sample of the IIS log file format for one request that is logged using the IIS Logs W3C format.
Both the IIS & NCSA log file formats cannot be customized and are fixed ASCII formats. In IIS log file format the items are comma-separated. In NSCA fields are separated by space and empty fields are represented by a hyphen (-). The IIS log file format records more information than the NCSA log file format.
There is a tool provided by Microsoft Log Parser using which you can read the data from the IIS log files. Using this tool you will be able to run SQL like queries against the log file and produce the desired report on screen or in a file.