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

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

Как получить файлы журнала Windows?

Для анализа и диагностики сложных проблем, связанных с работой AdGuard, службе поддержки могут понадобиться файлы журнала Windows. Журналы Windows содержат записи о системных событиях и ошибках за последнее время. Ниже представлена инструкция для получения и отправки этих файлов.

1. Откройте программу Просмотр событий (Event Viewer).

В Windows 10 нажмите на значок «Поиск» в панели задач, введите в поисковой строке eventvwr и запустите первую найденную программу (щелкнув на ней мышью или нажав Enter).

Если вы используете Windows 8 или 8.1, то проделайте следующие действия.

Перейдите в меню Поиск:

Введите в поисковой строке eventvwr и запустите первую найденную программу (щелкнув на ней мышью или нажав Enter).

Если вы используете Windows 7 или Vista, нажмите на Пуск, введите в строке поиска eventvwr, и нажмите Enter.

1. Сохраните журналы приложений и системы в отдельные файлы

Окно программы Просмотр событий выглядит как показано ниже на картинке.

Для сохранения необходимых нам файлов проделайте следующее.

2.1. Откройте журнал «Приложение» («Просмотр событий (Локальный)» -> «Журналы Windows» -> «Приложение»)

2.2. Щёлкните правой кнопкой мыши по пункту списка «Приложение» и в выпадающем меню выберите «Сохранить все события как . «

2.3. Выберите место сохранения, введите название, нажмите «Сохранить». Выберите «Отображать сведения для следующих языков:». Напротив пункта «Русский» должен быть установлен флажок. Нажмите «Ок».

2.4. Откройте журнал «Система» («Просмотр событий (Локальный)» -> «Журналы Windows» -> «Система»).

2.5. Щёлкните правой кнопкой мыши по пункту меню «Система» и в выпадающем меню выберите «Сохранить все события как . «

2.6. Выберите место сохранения, введите название, нажмите «Сохранить». Выберите «Отображать сведения для следующих языков:». Напротив пункта «Русский» должен быть установлен флажок. Нажмите «Ок».

Полученные два файла пришлите, пожалуйста, службе технической поддержки.

Создание собственных событий Windows в журнале

При работе с автоматизированными сценариями, заданиями но расписанию или собственными приложениями вам может по­требоваться, чтобы они записывали собственные события в журналы Windows. Например, при нормальном выполнении сценария вы хотите записать событие уведомления в журнал приложе­ния, чтобы в дальнейшем легко определить, выполнен сцена­рий и нормально ли он завершился. И наоборот, если сцена­рий не сработал и в результате его выполнения возникли ошибки, вам может понадобиться сохранить событие ошибки или предупреждения в журнале — тогда вы узнаете, что нуж­но проанализировать сценарий и выяснить, что случилось.

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

eventcreate /l ИмяЖурнала /so ИсточникСобытия /t ТипСобытия / id КодСобытия /d ОписаниеСобытия

1. ИмяЖурнала — название журнала для записи события; если оно содержит пробелы, заключите его в кавычки, на­пример «DNS Server».
2. ИсточникСобытия — указывает источник события и может быть любой строкой. Если строка содержит пробелы, зак­лючите ее в кавычки, например «Event Tracker*. В боль­шинстве случаев источник указывает на приложение, зада­ние или сценарий, вызвавший ошибку.
3. ТипСобытия — задает тип события. Может принимать зна­чения Information, Warning или Error. Типы событий «Success Audit» и «Failure Audit» неприменимы, так как исполь­зуются в журнале безопасности, в который записывать соб­ственные события нельзя.
4. КодСобытия — залает числовой код события. Может при­нимать любое значение от 1 до 1000. Чем случайно назна­чать идентификаторы, лучше составить список общих собы­тий, которые могут возникнуть, а затем разбить его на кате­гории. Тогда каждой категории можно присвоить свой диа­пазон кодов событий. Например, события из первой сотни могут быть общими, из второй — событиями состояния, из пятой — предупреждениями, а из девятой — ошибками.
5. ОписаниеСобытия — задает описание события и может быть любой строкой. Не забудьте заключить строку в кавычки.