How to create a log using System Monitor in Windows

Summary

This article describes how to create log files using System Monitor in Microsoft Windows 2000, Microsoft Windows XP or Microsoft Windows Server 2003.

Download and use the Performance Monitor Wizard (PerfWiz) to make the log configuration process easier to set up.

More Information

The System Monitor tool included with Windows 2000, Windows XP and Windows Server 2003 is the administrative tool that replaces the Performance Monitor tool included with Windows NT 4.0.

Here is a list of some improvements in the System Monitor tool:

You can log specific counters and instances of an object, which helps you reduce the size of log files.

The Print Queue object is a new Performance object that allows you to monitor aspects of a print queue.

You can start the log on an event using Performance Logs and Alerts.

Other Performance objects have also been added.

A sample log file is included in Windows 2000.

To create a new log:

Right-click Counter Logs, click New Log Settings, type a name for the log, and then click OK.

On the General tab in Windows 2000,click Add to add the counters you want. On the General tab in Windows XP or Windows Server 2003, click Add Counters.

On the Log Files tab, click the logging options you want.

On the Schedule tab, click the scheduling options you want.

You can set similar options in Alerts. For example, you can configure the alert to send a message, start a performance data log, or run a program, if a counter exceeds a certain value.

Using Performance Monitor Wizard

To obtain and download the Performance Monitor Wizard (PerfWiz). The Performance Monitor Wizard simplifies the gathering of performance monitor logs. It configures the correct counters to collect sample intervals and log file sizes. This wizard can create logs for troubleshooting operating system or Exchange server performance issues.

If you are troubleshooting a performance issue or an issue that looks like a memory leak, the objects that Performance Monitor should log include but are not limited to the following items. Memory resource issues:

Cache
Memory
Objects
Paging file
Process
Processor
System
Terminal Services (if a Terminal Server) For all other resource issues, add additional counters:

Logical disk
NBT Connections
Network interface
Physical disk
Redirector
Server
Server work queues
Thread (do NOT capture if a terminal server)
All Terminal Server counters (if a Terminal Server)
All Protocol counters bound to network adapters

Physical Disk counters are present by default on Windows 2000.

For additional information about how to view log files for memory leaks and performance bottlenecks, click the following article number to view the article in the Microsoft Knowledge Base:

150934 How to create a Performance Monitor log for NT troubleshooting
Also see Determining acceptable values for counters under Performance counters in Windows 2000 Help.

New-Event Log

Creates a new event log and a new event source on a local or remote computer.

Syntax

Description

This cmdlet creates a new classic event log on a local or remote computer. It can also register an event source that writes to the new log or to an existing log.

The cmdlets that contain the EventLog noun (the Event log cmdlets) work only on classic event logs. To get events from logs that use the Windows Event Log technology in Windows Vista and later versions of Windows, use Get-WinEvent .

Examples

Example 1 — create a new event log

This command creates the TestLog event log on the local computer and registers a new source for it.

Example 2 — add a new event source to an existing log

This command adds a new event source, NewTestApp, to the Application log on the Server01 remote computer.

The command requires that the NewTestApp.dll file is located on the Server01 computer.

Parameters

Specifies the path to the file that contains category strings for the source events. This file is also known as the Category Message File.

The file must be present on the computer on which the event log is being created. This parameter does not create or move files.

Type:	String
Aliases:	CRF
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False

Creates the new event logs on the specified computers. The default is the local computer.

The NetBIOS name, IP address, or fully qualified domain name of a remote computer. To specify the local computer, type the computer name, a dot (.), or «localhost».

This parameter does not rely on PowerShell remoting. You can use the ComputerName parameter of Get-EventLog even if your computer is not configured to run remote commands.

Type:	String [ ]
Aliases:	CN
Position:	3
Default value:	Local computer
Accept pipeline input:	False
Accept wildcard characters:	False

Specifies the name of the event log.

If the log does not exist, New-EventLog creates the log and uses this value for the Log and LogDisplayName properties of the new event log. If the log exists, New-EventLog registers a new source for the event log.

Type:	String
Aliases:	LN
Position:	1
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False

Specifies the path to the file that contains message formatting strings for the source events. This file is also known as the Event Message File.

The file must be present on the computer on which the event log is being created. This parameter does not create or move files.

Type:	String
Aliases:	MRF
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False

Specifies the path to the file that contains strings used for parameter substitutions in event descriptions. This file is also known as the Parameter Message File.

The file must be present on the computer on which the event log is being created. This parameter does not create or move files.

Type:	String
Aliases:	PRF
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False

Specifies the names of the event log sources, such as application programs that write to the event log. This parameter is required.

Type:	String [ ]
Aliases:	SRC
Position:	2
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False

Inputs

None

You cannot pipe input to this cmdlet.

Outputs

Notes

To use New-EventLog on Windows Vista and later versions of Windows, open PowerShell with the «Run as administrator» option.

To create an event source in Windows Vista, Windows XP Professional, or Windows Server 2003, you must be a member of the Administrators group on the computer.

When you create a new event log and a new event source, the system registers the new source for the new log, but the log is not created until the first entry is written to it.

The operating system stores event logs as files.

When you create a new event log, the associated file is stored in the $env:SystemRoot\System32\Config directory on the specified computer.

The file name is the first eight characters of the Log property with an .evt file name extension.

Вертим логи как хотим ― анализ журналов в системах Windows

Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

Журналы и командная строка

До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:

Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.

Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:

Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:

Смотрим за ходом обновления Windows.

Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:

Смотрим, кто пытается пролезть на наш дедик.

При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:

Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:

Журналы системы ведутся в формате .evtx, и для работы с ними существуют отдельные командлеты. Для работы с классическими журналами («Приложение», «Система», и т.д.) используется Get-Eventlog. Этот командлет удобен, но не позволяет работать с остальными журналами приложений и служб. Для работы с любыми журналами, включая классические, существует более универсальный вариант ― Get-WinEvent. Остановимся на нем подробнее.

Для получения списка доступных системных журналов можно выполнить следующую команду:

Вывод доступных журналов и информации о них.

Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:

Последние записи в журнале System.

Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.

Для примера получим все события из журнала System с кодом события 1 и 6013.

В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:

• 0 ― всегда записывать;
• 1 ― критический;
• 2 ― ошибка;
• 3 ― предупреждение;
• 4 ― информация;
• 5 ― подробный (Verbose).

Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:

Ошибки и предупреждения журнала System.

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

Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:

PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.

Работаем с журналами посредством запросов SQL

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:

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

Смотрим журнал Windows Firewall.

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

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManager\Operational.

Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%\test.evtx.

Данные будем получать таким запросом:

Смотрим, кто и когда подключался к нашему серверу терминалов.

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

В качестве примера посмотрим статистику количества писем по дням таким запросом:

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

Выполняем запрос и открываем получившуюся картинку…

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

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

Интерфейс Log Parser Studio.

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

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

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