Программа для логирования файл сервера на windows 2018: Вертим логи как хотим ― анализ журналов в системах Windows / Хабр

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

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

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

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

findstr "Fail" *.log >> fail.txt

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

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

Get-Content -Path 'C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log' | Out-Host -Paging

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

>Get-Content -Path "C:\Windows\WindowsUpdate.log" -Tail 5 -Wait

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

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

Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall. log" -Pattern 'Drop' | Select-Object -Last 20 | Format-Table Line

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

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

Select-String 'C:\Windows\Cluster\Reports\Cluster.log' -Pattern ' err ' ‑Context 3

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

Get-Content 'C:\Windows\debug\netlogon.log' | Select-Object -First 30 -Skip 45

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

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

Get-WinEvent -ListLog *

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

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

Get-WinEvent -LogName 'System' -MaxEvents 20

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

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

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

Get-WinEvent -FilterHashTable @{LogName='System';ID='1','6013'}

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

  • 0 ― всегда записывать;

  • 1 ― критический;

  • 2 ― ошибка;

  • 3 ― предупреждение;

  • 4 ― информация;

  • 5 ― подробный (Verbose).

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

Get-WinEvent -FilterHashtable @{LogName='system'} | Where-Object -FilterScript {($_.Level -eq 2) -or ($_.Level -eq 3)}

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

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

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

  • Get-EventLog.

  • Get-WinEvent.

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

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

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

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

SELECT 
 extract_token(text, 0, ' ') as date, 
 extract_token(text, 1, ' ') as time,
 extract_token(text, 2, ' ') as action, 
 extract_token(text, 4, ' ') as src-ip,  
 extract_token(text, 7, ' ') as port 
FROM 'C:\Windows\System32\LogFiles\Firewall\pfirewall. log' 
WHERE action='DROP' AND port='3389'
ORDER BY date,time DESC

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

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

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

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

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

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

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

SELECT
 timegenerated as Date, 
 extract_token(strings, 0, '|') as user,
 extract_token(strings, 2, '|') as sourceip 
FROM '%temp%\test. evtx'
WHERE EventID = 21
ORDER BY Date DESC

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

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

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

SELECT
 TO_LOCALTIME(TO_TIMESTAMP(EXTRACT_PREFIX(TO_STRING([#Fields: date-time]),0,'T'), 'yyyy-MM-dd')) AS Date,
 COUNT(*) AS [Daily Email Traffic] 
FROM 'C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking\*.LOG'
WHERE (event-id='RECEIVE') GROUP BY Date ORDER BY Date ASC

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

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

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

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

$LogQuery = New-Object -ComObject "MSUtil.LogQuery"
$InputFormat = New-Object -ComObject "MSUtil.LogQuery.FileSystemInputFormat"
$InputFormat.Recurse = -1
$OutputFormat = New-Object -ComObject "MSUtil.LogQuery.CSVOutputFormat"
$SQLQuery = "SELECT Top 20 Path, Size INTO '%temp%\output.csv' FROM 'C:\*.*' ORDER BY Size DESC"
$LogQuery.ExecuteBatch($SQLQuery, $InputFormat, $OutputFormat)
$CSV = Import-Csv  $env:TEMP'\output.csv'
$CSV | fl 
Remove-Item $env:TEMP'\output.csv'
$LogQuery=$null
$InputFormat=$null
$OutputFormat=$null

Ознакомиться с документацией о работе компонента можно в материале 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.

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

Обзор диспетчера ресурсов файлового сервера (FSRM)





Twitter




LinkedIn




Facebook




Адрес электронной почты










  • Статья




Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2

Диспетчер ресурсов файлового сервера (FSRM) — это служба роли в Windows Server, которая позволяет классифицировать данные, хранящиеся на файловых серверах, и управлять этими данными. FSRM можно использовать для автоматической классификации файлов, выполнения задач на основе этих классификаций, установки квот на папки и создания отчетов, отслеживая использование хранилища. В Windows Server версии 1803 FSRM добавляет возможность предотвращения создания журналов изменений.

Примечание

Сведения о новых возможностях в более старых версиях Windows Server см. в статье Новые возможности Resource Manager файлового сервера.

Компоненты

FSRM включает следующие функции.

  • Управление квотами. Ограничьте пространство, разрешенное для тома или папки. Эти ограничения могут автоматически применяться к новым папкам, созданным на томе. Можно также определить шаблоны квот, которые могут применяться к новым томам или папкам.
  • Инфраструктура классификации файлов. Получите аналитические сведения о данных, автоматив процессы классификации, чтобы вы могли более эффективно управлять данными. На основании классификации файлов можно применять политики. Примерами политик могут служить динамический контроль доступа для ограничения доступа к файлам, шифрование файлов и установка срока действия файлов. Классификация файлов может производиться автоматически с помощью правил классификации или вручную — изменением свойств выбранного файла или папки.
  • Задачи управления файлами. Получите возможность применять условную политику или действие к файлам на основе их классификации. Условия задачи управления файлами включают расположение файла, свойства классификации, дату создания файла, дату последнего изменения файла или время последнего доступа к файлу. Действия, доступные в задаче управления файлами, включают прекращение срока действия файлов, их шифрование или выполнение пользовательской команды.
  • Управление проверкой файлов. Управление типами файлов, которые пользователь может хранить на файловом сервере. Можно ограничить расширения, допустимые при сохранении файлов с общим доступом. Например, можно создать экран файла, который не позволяет хранить файлы с расширением MP3 в личных общих папках на файловом сервере.
  • Отчеты хранилища. Используйте эти отчеты для выявления тенденций использования дисков и классификации данных. Можно также контролировать попытки сохранять запрещенные файлы пользователями выбранной группы.

Вы можете настраивать функции FSRM и управлять ими с помощью приложения FSRM или с помощью Windows PowerShell.

Важно!

FSRM поддерживает тома, отформатированные только в файловой системе NTFS. Файловая система Resilient File System не поддерживается.

Практическое применение

В следующем списке описаны некоторые практические приложения для FSRM:

  • Используйте инфраструктуру классификации файлов в сценарии динамического контроль доступа. Создайте политику, которая предоставляет доступ к файлам и папкам в зависимости от способа классификации файлов на файловом сервере.

  • Создайте правило классификации файлов, которое помещает любой файл, содержащий по крайней мере 10 номеров социального страхования, как имеющий содержимое клиента.

  • Срок действия всех файлов, которые не были изменены за последние 10 лет.

  • Создайте квоту в 200 МБ для домашнего каталога каждого пользователя и уведомите его об использовании 180 МБ.

  • Запретить хранение музыкальных файлов в личных общих папках.

  • Создание в расписании отчета, который будет выполняться в полночь по воскресеньям и создавать список файлов, открывавшихся за предыдущие два дня. Этот отчет поможет вам определить активность хранения в выходные дни и спланировать время простоя сервера соответствующим образом.

Новые возможности— запрет на создание журналов изменений в FSRM

Начиная с Windows Server версии 1803, теперь можно запретить службе FSRM создавать журнал изменений (также известный как журнал USN) на томах при запуске службы. Эта функция позволяет сэкономить место на каждом томе, но отключает классификацию файлов в режиме реального времени.

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

  1. Остановите службу SRMSVC. Откройте сеанс PowerShell от имени администратора и введите Stop-Service SrmSvc.

  2. Удалите журнал USN для томов, на которые вы хотите сэкономить место, с помощью fsutil команды :

    fsutil usn deletejournal /d <VolumeName>

    Пример: fsutil usn deletejournal /d c:

  3. Откройте редактор реестра, введя regedit в том же сеансе PowerShell.

  4. Перейдите к следующему разделу: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SrmSvc\Settings.

  5. Чтобы предотвратить создание журнала изменений для всего сервера, выполните следующие действия.

    Важно!

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

    1. Щелкните правой кнопкой мыши раздел Параметры и выберите Новое>значение DWORD (32-разрядная версия).
    2. Назовите значение SkipUSNCreationForSystem.
    3. Задайте значение 1 (в шестнадцатеричном формате).

  6. Чтобы предотвратить создание журнала изменений для определенных томов, выполните следующие действия.

    1. Определите пути к томам, которые нужно пропустить. Можно использовать fsutil volume list команду или следующую команду PowerShell:

      Get-Volume | Format-Table DriveLetter,FileSystemLabel,Path

      Ниже представлен пример результата.

      DriveLetter FileSystemLabel Path
----------- --------------- ----
             System Reserved \\?\Volume{8d3c9e8a-0000-0000-0000-100000000000}\
C                           \\?\Volume{8d3c9e8a-0000-0000-0000-501f00000000}\

    2. Вернитесь к сеансу редактора реестра. Щелкните ключ правой HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SrmSvc\Settings кнопкой мыши и выберите Создать>многостроковое значение.

    3. Назовите значение SkipUSNCreationForVolumes.

    4. Введите путь для каждого тома, который вы хотите пропустить. Поместите каждый путь на отдельную строку. Пример:

      \\?\Volume{8d3c9e8a-0000-0000-0000-100000000000}\
\\?\Volume{8d3c9e8a-0000-0000-0000-501f00000000}\

      Примечание

      Если редактор реестра отображает предупреждение об удаленных пустых строках, вы можете спокойно игнорировать это сообщение. Ниже приведен пример сообщения: Данные типа REG_MULTI_SZ не могут содержать пустые строки. Редактор реестра удалит все найденные пустые строки.

  7. Запустите службу SRMSVC. Например, в сеансе PowerShell введите Start-Service SrmSvc.

  • Обзор динамических контроль доступа









Включить ведение журнала установщика Windows — клиент Windows

Редактировать

Твиттер

LinkedIn

Фейсбук

Электронная почта

  • Статья

Windows включает активируемую реестром службу ведения журнала, помогающую диагностировать проблемы установщика Windows. В этой статье описывается, как включить эту службу ведения журнала.

Применяется к:   Windows 10 – все выпуски, Windows Server 2012 R2
Исходный номер базы знаний:   223300

Примечание

Запись реестра в этой статье действительна для всех операционных систем Windows.

Установщик Windows может использовать ведение журнала, чтобы помочь в устранении неполадок при установке пакетов программного обеспечения. Это ведение журнала включается путем добавления ключей и значений в реестр. После того, как записи будут добавлены и включены, вы можете повторить установку проблемы, и установщик Windows отследит ход выполнения и опубликует его в папке Temp. Имя файла нового журнала является случайным. Тем не менее, первые буквы Msi , а имя файла имеет расширение .log. Чтобы найти папку Temp, введите в командной строке следующую строку:

 cd %temp%

Чтобы включить ведение журнала установщика Windows вручную, см. следующий раздел.

Важно

В этом разделе, методе или задаче содержатся инструкции по изменению реестра. Однако при неправильном изменении реестра могут возникнуть серьезные проблемы. Поэтому убедитесь, что вы внимательно выполните следующие действия. Для дополнительной защиты создайте резервную копию реестра перед его изменением. Затем вы можете восстановить реестр, если возникнет проблема. Дополнительные сведения о резервном копировании и восстановлении реестра см. в разделе Резервное копирование и восстановление реестра в Windows.

Чтобы включить ведение журнала установщика Windows самостоятельно, откройте реестр с помощью Regedit.exe, а затем создайте следующие подразделы и ключи:

  • Путь: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
  • Тип: Reg_SZ
  • Значение: Регистрация
  • Данные: voicewarmupx

Буквы в поле значения могут быть в любом порядке. Каждая буква включает отдельный режим регистрации. Фактическая функция каждой буквы для MSI версии 1.1 следующая:

  • v — Подробный вывод
  • o — Сообщения о нехватке места на диске
  • i — Сообщения о состоянии
  • c — Начальные параметры пользовательского интерфейса
  • e — Все сообщения об ошибках
  • w — Нефатальные предупреждения
  • а — Запуск действий
  • r — Записи, относящиеся к действию
  • m — Недостаточно памяти или фатальная информация о выходе
  • u — Запросы пользователей
  • p — Свойства терминала
  • + — Добавить к существующему файлу
  • ! — Сбросить каждую строку в лог
  • x — Дополнительная отладочная информация. Флаг x доступен только в операционных системах Windows Server 2003 и более поздних версиях, а также в распространяемом MSI версии 3.0 и в более поздних версиях распространяемого MSI.
  • * — Подстановочный знак. Запишите всю информацию, кроме v и x. Чтобы включить параметры v и x, укажите /l*vx.

Примечание

Это изменение следует использовать только для устранения неполадок, и его не следует оставлять включенным, поскольку оно отрицательно скажется на производительности системы и дисковом пространстве. Каждый раз, когда вы используете Добавление и удаление программ элемент Панель управления создается новый файл Msi*.log. Чтобы отключить ведение журнала, удалите значение реестра Logging .

Вы можете включить ведение журнала с помощью групповых политик, отредактировав соответствующую групповую политику подразделения или каталога. В разделе Групповая политика разверните Конфигурация компьютера , разверните Административные шаблоны , разверните Компоненты Windows , а затем выберите Установщик Windows .

Дважды щелкните Ведение журнала , а затем щелкните Включено . В поле Ведение журнала введите параметры, которые вы хотите зарегистрировать. Файл журнала Msi.log появляется в папке Temp системного тома.

Дополнительные сведения о ведении журнала MSI см. в справке Windows. Для этого выполните поиск по фразе msi logging , а затем выберите Управление параметрами компьютеров с помощью групповой политики .

Примечание

Добавление флага x изначально доступно в Windows Server 2003 и более поздних операционных системах, в распространяемом MSI версии 3.0 и в более поздних версиях распространяемого MSI.

Файлы журналов и источники служб отчетов — службы отчетов SQL Server (SSRS)

Редактировать

Твиттер

LinkedIn

Фейсбук

Электронная почта

  • Статья

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

Применяется к: Службы Reporting Services в режиме SharePoint | Собственный режим служб Reporting Services

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

Журнал Описание
Журнал выполнения сервера отчетов и представление ExecutionLog3 Журнал выполнения — это представление SQL Server, хранящееся в базе данных сервера отчетов.

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

Журнал трассировки SharePoint Для серверов отчетов, работающих в SharePoint, журналы трассировки SharePoint содержат информацию о службах отчетов. Вы также можете настроить конкретную информацию SSRS для службы единого ведения журнала SharePoint. Дополнительные сведения см. в разделе Включение событий служб Reporting Services для журнала трассировки SharePoint (ULS) 9.0167
Журнал трассировки службы сервера отчетов Журнал трассировки службы содержит очень подробную информацию, которая полезна при отладке приложения или исследовании проблемы или события. Файлы журнала трассировки — ReportServerService_.log и расположены в следующей папке:

В SQL Server Reporting Services 2016 или более ранней версии: C:\Program Files\Microsoft SQL Server\MSRS13. MSSQLSERVER\Reporting Services\LogFiles

В службах отчетов SQL Server 2017: C:\Program Files\Microsoft SQL Server Reporting Services\SSRS\LogFiles

Журнал HTTP сервера отчетов Файл журнала HTTP содержит записи обо всех HTTP-запросах и ответах, обработанных веб-службой сервера отчетов.
Журнал приложений Windows Журнал приложений Microsoft Windows содержит информацию о событиях сервера отчетов.
Журналы производительности Windows Журналы производительности Windows содержат данные о производительности сервера отчетов. Вы можете создавать журналы производительности, а затем выбирать счетчики, определяющие, какие данные собирать. Дополнительные сведения см. в разделе Мониторинг производительности сервера отчетов.
Файлы журнала установки SQL Server Файлы журнала также создаются во время установки. Если программа установки завершилась неудачно или успешно с предупреждениями или другими сообщениями, вы можете просмотреть файлы журналов, чтобы устранить проблему.

Imacros | Все права защищены © 2021