Где хранятся логи windows server

Настройка размера и параметров журнала событий Windows

25.11.2022
itpro
PowerShell, Windows 10, Windows Server 2019, Групповые политики
Комментариев пока нет

В журналах событий Windows хранится полезная информация, которая нужна при анализе состояния служб и приложений в Windows, отладки ошибок и аварийный ситуаций, аудите различных событий безопасности. По умолчанию для журналов Event Viewer в Windows заданы максимальные размеры, при достижении которых новые события начинают перезаписывать более старые. Если на вход Event Viewer попадает слишком большое количество событий, может случится, что в журнал помещаются события лишь за последние несколько часов, что может быть не достаточно.

Чтобы предотвратить перезапись старых событий и всегда иметь под рукой события за достаточно большой промежуток времени, вы можете увеличить максимальный размер журналов Event Viewer.

Получить информацию о журналах событий Windows с помощью PowerShell

Файлы журналы событий Windows хранятся в каталог %SystemRoot%\System32\Winevt\Logs\ в виде файлов с расширением .EVTX. Обратите внимание, что для каждого журнала используется собственный файл. Соответственно, вы можете управлять размерами только того лога Windows, который вам нужен и оставить остальные значения по-умолчанию.

Текущие лимиты на все включенные журналы событий в Windows можно вывести с помощью PowerShell:

Вы можно вывести размер определенного лога с помощью командлета Get-WinEvent. Например, получим текущий и максимальный размер журнала Security:

Get-WinEvent -ListLog Security| Select MaximumSizeInBytes, FileSize, IsLogFull, OldestRecordNumber, IsEnabled, LogMode

Чтобы увеличить максимальный размер лога, можно использовать утилиту wevtutul (новый размер задается в Кб):

wevtutil sl «Application» /ms:200000

Или с помощью PowerShell:

Limit-Eventlog -Logname Application -MaximumSize 200MB -OverflowAction OverwriteOlder

Изменить размер журнала событий из консоли Event Viewer

Проще всего увеличить максимальный размер журнала прямо из консоли Event Viewer.

1. Откройте eventvwr.msc ;
2. Найдите в консоли свойства нужного журнала и откройте его свойства (например, Security);
3. Задайте ограничение в разделе Maximum log size (KB) и сохраните изменения;
4. Здесь же можно изменить поведение при достижение максимального размера:
   Owerwrite events as needed (oldest events first) – этот режим исопльзуется по умолчанию. Новые события просто перезаписывают более старые.
   Archive the log when full, do not owerwrite events – текущий журнал событий при заполнении архивируется в папке \System32\Winevt\Logs\ и новые события записываются в новый evtx файл. Архивные файлы событий можно открыть через меню Open Saved Log в Event Viewer.
   Do not owerwrite events (Clear log manually) – события никогда не перезатираются. Для записи новых событий нужно очистить журнал.

Увеличить размер журнала событий Windows через GPO

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

1. Запустите консоль Group Policy Management ( gpmc.msc ), создайте новую GPO и назначьте на OU с компьютерами или серверами, для которых вы хотите изменить настройки Event Viewer (или назначьте GPO на корень домена);
2. Перейдите в раздел GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Event Log Service. Как вы видите, в этом ветке есть подразделы для управления базовыми журналами Windows:
3. Чтобы увеличить максимальный размер любого из журналов, откройте параметр Specify the maximum log file size (KB), включите его и задайте нужный вам размер; на клиентах и проверьте, что в свойствах журнала теперь указан новый размер, который вы не можете изменить. При попытке задать другой размер появится ошибка:
   Event Viewer
   The Maximum Log Size specified is not valid. It is too large or too small. The Maximum Log Size will be set to the following: 61440 KB

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

Обратите внимание, что в описанном выше разделе GPO отсутствуют настройки для других журналов из раздела Applications and Services Logs -> Microsoft.Если вам нужно увеличить размер любого другого журнала событий (кроме стандартного), это можно сделать через реестр. Настройки журналов событий Windows хранятся в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\<log_name>. Размер журнала задается с помощью параметра MaxSize (тип REG_DWORD). Вы можете распространить нужное вам значение параметра реестра MaxSize на компьютеры домена с помощью Group Policy Preferences.

В этом примере мы увеличим размер журнала Directory Service на контроллерах домена. Настройки этого лога хранятся в ветке HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Directory Service.

1. Откройте GPO и перейдите в раздел Computer Configuration -> Preferences -> Windows Settings -> Registry;
2. Выберите New -> Registry Item;
3. Создайте новый параметр со следующими настройками:

За счет увеличения размеров журналов событий Windows вы можете получить различную информацию за более длительный промежуток времени. Например, из журналов событий можно получить историю перезагрузок Windows, понять кто удалил файл в сетевой папке или кто изменил NTFS права доступа.

Предыдущая статья Следующая статья

RootUsers

Guides, tutorials, reviews and news for System Administrators.

Where Are Windows Server 2016 Log Files Stored?

This post will show you where the .evtx log files can be found in Windows Server 2016, as well as how they can be viewed with Event Viewer.

Viewing Log Files

The easiest way to view the log files in Windows Server 2016 is through the Event Viewer, here we can see logs for different areas of the system.

Event viewer can be opened through the MMC, or through the Start menu by selecting All apps, Windows Administrative Tools, followed by Event Viewer.

Through Event Viewer we have the ability to search the logs for a particular string, export the logs to a file, and even schedule a task to take place each time a specific event occurs.

Log File Location

While this allows us to read the logs, you may be after the full path to where the actual .evtx files are stored. These log files can be found in the C:\Windows\System32\winevt\logs folder, as shown below.

These files can be double clicked and they will automatically open with Event Viewer, and these are the files that are read when browsing through Event Viewer

Note that specific applications may have their own custom log locations, in which case you will need to check the vendors documentation regarding log file location.

Summary

We have seen that important application, security and system events that have been logged are stored in the C:\Windows\System32\winevt\logs directory as .evtx files, which can be viewed through Event Viewer.

Where Are the Windows Logs Stored?

Windows VPS server options include a comprehensive logging and management system for logs. These logs capture events initiated by a user or running process on your server. This information is quite beneficial while debugging your server's services or solving other problems. Also, logs are very useful when a security issue should be investigated.

Windows refers to them as Windows event logs or logs. Knowing how to use the Event Viewer to review your server’s activities and troubleshoot issues is helpful. This article will help you find where the Windows system logs are stored and how to access them using the Event Viewer application.

What Is a Windows Event Log?

Windows event logs are detailed records of system, security, and application-related events kept on a Windows operating system. Event logs help track the system and particular application problems and predict possible upcoming issues.

What Types of Information Are Stored in Windows Event Logs?

Hardware and software events on the Windows operating system are stored in Windows event logs. The information stored in the Windows event logs will help you locate the possible threats and help you improve your system's functionality.

The most important elements of the Windows event log are:

• Event time and date — Contains the time and date of the event.
• ID of the event — The unique identification number of a specific event.
• Log name — Name of the specific event, usually stored for security, system, and applications.
• Source — Contains the name of the software generating the event.
• User — The name of the user the event was created or run by.
• Level — Describes the seriousness of the recorded event.
• Computer — Represents the computer name.

How Can I Access Windows Event Logs?

The most asked questions regarding Windows event logs are: Where are they stored, and how can I access them?

The location of the Windows event log is C:\WINDOWS\system32\config\. Windows event logs can be accessed and reviewed using the Event Viewer application.

Accessing the Event Viewer

Accessing the Event Viewer is simple. Follow the next steps to open the Event Viewer:

1. Press the Windows key or access the search bar from the Taskbar.

2. Type Event Viewer in the search bar.

3. Click on Event Viewer to open the app.

Here is another way to open Event Viewer:

1. Hit Windows key + R to open the run window.

2. In the Open bar, type eventvwr and click OK.

Using the Event Viewer

The Event Viewer application is present on all Windows Server versions. Once the Event Viewer is opened, click on the Windows Logs folder to expand the menu.

You can now choose the log category you wish to open and review.

Event Viewer includes four main folders you will see once you launch the application for the first time:

• Custom Views.
• Windows Logs.
• Application and Services logs.
• Subscriptions.

Viewing Windows logs, the information they provide, and their location is valuable for audits and other helpful information. There are times, however, when application-specific logs are helpful for troubleshooting.

All logs have an event level assigned. The event level implies the severity or the level of the impact of any problems generated in the logs. The default view of the list below is alertness.

• Audit Success — (Security category only).
• Audit Failure — (Security category only).
• Critical — Points to a major problem in a system or an application that needs immediate action.
• Error — Indicates a problem with the system or some services that don’t need swift attention.
• Warning — Implies a potential uprising problem that should be monitored.
• Information — Points to the event that was successfully completed.
• Verbose — Implies a process or a successfully executed event.

Log Categories

There are five log categories reviewable in the Event Viewer:

• Security — Logs related to various authentication requests, failed and successful logins.
• Application — System components logs and other logs related to drivers.
• System — Logs created by the operating system, status change of the various services, and uptime.
• Setup — Logs regarding updates and installs on your Windows system.
• Forwarded events — Logs generated on a remote server that were forwarded to your server.

Searching for Particular Logs

If you want to find a specific log, follow these steps:

1. Open the Event Viewer app.

2. Click the Windows Logs folder to expand it.

3. Right-click on the log category you want to filter to investigate.

4. Click on the Filter tab (usually open by default).

5. Under the logged drop menu, select the desired period of the event occurrence.

6. Choose the event alertness level (Critical, Warning, Error, etc.).

7. You can optionally select the task category.

8. Optionally use a keyword to filter the end result additionally.

9. User and Computers selection leave at default.

10. Click OK, and you have successfully filtered out desired logs.

Wrapping Up

Do you need assistance interpreting your log files or the information in them? This article presents all of the basic information about Windows System logs. You know where they are stored and how to access them, giving you more troubleshooting and security tools.

Windows hosting is one of many options for our VPS Hosting, Cloud Dedicated Servers, and Dedicated Servers. Contact our sales team today if you’re looking for a managed hosting provider for your Windows Server project.

Related Articles:

About the Author: Neil Golden

Neil contributed to solving the complex puzzle of evolution for a long time by obtaining his Ph.D. in Archaeology. These days, he digs the Linux servers in his role within the Liquid Web Monitoring Department instead of Paleolithic stone tools in the caves on archaeological sites. Instead of mammoths, he is now hunting for bugs on Linux servers. He has written numerous scientific and technical articles because writing is one of his biggest passions. In his free time, Neil composes music, reads novels, and travels the world.

Join our mailing list to receive news, tips, strategies, and inspiration you need to grow your business

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

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