Чтение журнала событий Windows

Журналы событий Windows содержат информацию о происходящих в компьютере событиях. Эта информация полезна для диагностики проблем, особенно на серверах.
Как скриптами WSH JScript/VBScript считать события и значения полей? Можно ли реагировать на события online, т.е. отправить смс администратору, автоматически перезапустить службу или сервер и пр.?

Чтение событий из журнала событий реализуется достаточно просто. Следующий скрипт считывает все события из системного журнала (System):

Скрипт выводит все события примерно в таком виде.

Аналогичный скрипт на VBScript реализуется так:

Чтобы прочитать другой журнал, например, журнал приложений (Application Log), необходимо исправить условие в строке запроса с Logfile = ‘System’ на Logfile = ‘Application’.

Возможность добавления условий фильтрации позволяет ограничить число выводимых событий:

• • По источнику события, например, запрос «SELECT * FROM Win32_NTLogEvent WHERE Logfile = ‘System’ AND SourceName = ‘SNMP’» отфильтрует события, относящиеся к SNMP.
  • По типу события, например, запрос «SELECT * FROM Win32_NTLogEvent WHERE Logfile = ‘System’ AND Type = ‘Ошибка’» выберет ошибки (для английской локализации …AND Type = ‘Error’).
  • Нумерация событий (поле RecordNumber) позволяет выполнять периодическую проверку на возникновение новых событий, добавляя к запросу условие AND RecordNumber > 13847

(подставляя номер последнего ранее считанного события).

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

Проверить, запущена ли программа

Получить список пользователей AD в bat файле

Чтение из реестра в скрипте WSH

Чтение журнала событий Windows : 3 комментария

На быстродействие оказывает влияние некоторые флаги, особенно результативен wbemFlagForwardOnly (cм. https://msdn.microsoft.com/ru-ru/library/aa393866(v=vs.85).aspx)

objWbemObjectSet = .ExecQuery (_
ByVal strQuery, _
[ ByVal strQueryLanguage], _
[ ByVal iFlags], _
[ ByVal objWbemNamedValueSet] _
)

iFlags [необязательно]
Integer, который определяет поведение запроса и определяет, немедленно ли этот вызов возвращается. Значением по умолчанию для этого параметра является wbemFlagReturnImmediately . Этот параметр может принимать следующие значения.
wbemFlagForwardOnly (32 (0x20))
Перечисление только в прямом направлении, как правило, намного быстрее и используют меньше памяти, чем обычные счетчики, но не разрешают вызовы SWbemObject.Clone_ .
wbemFlagBipirectional (0 (0x0))
Заставляет WMI сохранять указатели на объекты перечисления, пока клиент не освободит счетчик.
wbemFlagReturnImmediately (16 (0x10))
Заставляет вызов немедленно вернуться.
wbemFlagReturnWhenComplete (0 (0x0))
Заставляет этот вызов блокироваться, пока запрос не будет завершен. Этот флаг вызывает метод в синхронном режиме.
wbemQueryFlagPrototype (2 (0x2))
Используется для прототипирования (хз, что за тема — надо читать). Этот флаг останавливает выполнение запроса и возвращает объект, который похож на типичный объект результата.
wbemFlagUseAmendedQualifiers (131072 (0x20000))
Заставляет WMI возвращать данные о поправках класса с определением базового класса.

Последний пример, где фильтрация по «RecordNumber > 13847» работает очень медленно. Я использовал «TimeWritten > ‘….’» — принципиально лучше во всяком случае на Windows 7.

Как работать с журналом событий Windows

Что такое Журнал событий Windows и как с ним работать?

Журнал событий Windows – это специальные лог-файлы, в которые система и приложения записывают все значимые для вашего компьютера события: например, установка нового устройства; ошибки в работе приложений; вход пользователей в систему; незапустившиеся службы и т.д. Анализ данных из журнала событий поможет системному администратору (и даже обычному пользователю) устранить неисправности в работе операционной системы, программного обеспечения и оборудования.

Для того чтобы система регистрировала события в журнале – на компьютере должна быть запущена одноименная служба “Журнал событий Windows”. Данная служба запускается автоматически после включения компьютера. Не рекомендуется останавливать или выключать службу “Журнал событий Windows” – это может ухудшить стабильность и безопасность системы:

Для просмотра и управления журналами событий необходимо запустить в Windows стандартную программу “Просмотр событий”. Для этого перейдите в меню “Пуск”– “Панель управления” – “Администрирование” – “Просмотр событий”:Либо можно нажать на клавиатуре сочетание клавиш Win+R – в открывшемся окошке ввести eventvwr.msc и нажать ОК:

Запущенная утилита “Просмотр событий” имеет следующий вид:

В среднем столбце отображается список событий выбранной категории;

В правом столбце – список доступных действий с выбранным журналом;

Внизу находится панель подробных сведений о конкретной записи (область просмотра).

Внешний вид утилиты можно настроить по своему усмотрению. Например, с помощью кнопок под строкой меню можно скрыть или отобразить дерево консоли слева и панель действий справа:Область по центру снизу называется Областью просмотра. Здесь представлены общие и подробные сведения о выбранном событии. Ее можно скрыть, если снять соответствующую галку в меню “Вид”, или нажать на крестик в правом верхнем углу области просмотра:

Как же работать с утилитой “Просмотр событий” и решать с ее помощью возникающие проблемы?

Для нас наибольший интерес представляет раздел “Журналы Windows” – именно с ним чаще всего приходится работать, выясняя причины неполадок в работе системы и программ.

Данный раздел включает три основные и две дополнительные категории: основные – это Приложение, Система, Безопасность; дополнительные – Установка и Перенаправленные события.

Приложение – хранит важные события, связанные с конкретным приложением. Эти данные помогут системному администратору установить причину отказа той или иной программы.

Система – хранит события операционной системы или ее компонентов (например, неудачи при запусках служб или инициализации драйверов; общесистемные сообщения и прочие сообщения, относящиеся к системе в целом).

Безопасность – хранит события, связанные с безопасностью (такие как: вход/выход из системы, управление учётными записями, изменение разрешений и прав доступа к файлам и папкам).

В утилите “Просмотр событий” предусмотрена возможность поиска и фильтрации событий:

Например, была у меня такая ситуация: на компьютере некорректно работала одна программа – точнее не работала совсем: сразу после запуска она сама по себе отключалась. Как понять в чем именно проблема?

В этом случае я открыл утилиту “Просмотр событий” – зашел в “Журнал Windows” – “Приложение”. Там нашел ошибку со следующим описанием: Application Error 1000 (100) «Имя сбойного приложения: , Имя сбойного модуля: KERNELBASE.dll.

Была у меня и другая ситуация: сижу, работаю за компьютером – вдруг ни с того ни с сего он резко выключается. Тогда я включаю его снова – захожу в журнал Windows в подраздел “Система” и читаю описание критического события, которое только что произошло. А там написано: “Система перезагрузилась, завершив работу с ошибками. Возможные причины ошибки: система перестала отвечать на запросы, произошел критический сбой или неожиданно отключилось питание”.

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

Вертим логи как хотим ― анализ журналов в системах 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.

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