Сбор логов windows в файл

Время на прочтение6 мин

Количество просмотров48K

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

Соответственно для реализации такой системы перед администратором ставятся задачи: во-первых, каким образом эти логи собирать, во-вторых, каким образом с ними удобно и централизованно работать. Благодаря достаточно развитой связке ELK (Elasticsearch + Logstash + Kibana), уже не раз описанной на Хабре, у администратора имеются инструменты для удобного поиска и отображения всей присутствующей в логах информации. Поэтому ответ на вторую задачу имеется изначально, и остается лишь решить задачу по сбору логов.

Так как в моем случае требованием к системе было отсутствие клиента на серверах, и то, что логи требовалось вытаскивать с Windows-серверов, то в качестве инструмента сбора был выбран родной для Windows — powershell.
Исходя из этого была составлена следующая модель сбора и отображения информации из логов: логи удаленно собираются с серверов powershell-скриптом, после чего складываются в виде файлов на хранилище, далее средствами ELK (Elasticsearch + Logstash + Kibana) происходит их обработка и отображение.

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

Картинка с сайта: habr.com

Упреждая критику, опишу, что данная система не ставит задачи сбора логов в реалтайме, целью является лишь статистика, которая собирается за определенный промежуток времени, а затем отображается на dashboard-е. Применяется она с целью прийти с утра, посмотреть как себя вели сервера ночью, и сравнить с результатами, полученными, допустим, на прошлой неделе. В предлагаемой системе логи собираются раз в час, соответственно, отставание между текущими логами и тем, что выводятся (если быть точным, отображаются и выводятся по запросу) на dashboard-е может составлять порядка часа.

В настоящий момент в powershell имеется два способа получения логов с удаленного компьютера:

• родная команда powershell: Get-EventLog -ComputerName $computer –LogName System
• получение логов через WMI-запрос: Get-WmiObject -Class win32_NTLogEvent -filter «logfile = ‘System’» -ComputerName $computer

Но в первом случае происходит полное перекачивание файла с event-логами системы и лишь затем осуществляется их обработка на компьютере, где выполняется скрипт. Как следствие, такие запросы обрабатываются неоправданно долго. Возможность выборки логов (например, лишь за последние сутки) здесь не особо отрабатывает, так как изначально вытаскивается весь файл и лишь затем с ним ведется какая-то работа.

Во втором случае серверу отсылается WMI запрос, обработка происходит на стороне сервера и ключевой момент здесь в том, что появляется возможность ограничить промежуток интересующих нас логов уже на этапе запроса (в приведенном ниже примере промежуток выставлен в 1 час). Так как данная комманда отрабатывает намного быстрее первой, а время выполнения запроса напрямую зависит от запрашиваемого промежутка логов, то выбар пал на Get-WmiObject.

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

Clear-Host

# импортируем список серверов из Active Directory (для этого в powershell должен быть дополнительно установлен модуль для Active Directory)
import-module activedirectory
$computers = Get-ADComputer -SearchBase "OU=Servers,DC=domain,DC=ru" -Filter * | ForEach-Object {$_.Name} | Sort-Object

# определяем директорию для логирования 
$logdir = "\\storage\Logs\ServersLog\" + $(Get-Date -UFormat "%Y_%m")
# если директория отсутствует, то создаем 
if((Test-Path $logdir) -eq 0) {
	New-Item -ItemType directory $logdir -Force
}

# указываем данные пользователя под которым будут выполнятся команды
$domain = "domain"
$username = "username" 
$password = 'password'

$account = "$domain"+"\"+$($username)
$accountpwd = ConvertTo-SecureString $password -AsPlainText -Force
$credential = New-Object System.Management.Automation.PsCredential($account, $accountpwd)

# для того, чтобы делать выгрузку за предыдущий час, нужно ограничить время за которое лог был сформирован следующим образом: верхний предел - минус час, нижний предел - начало текущего часа.
# получается примерно следующее:
# BiginDate = 08/26/2014 12:00:00
# EndDate = 08/26/2014 13:00:00
# в результате будет выгружен лог созданый в пределах от BiginDate = 08/26/2014 12:00:00 до EndDate = 08/26/2014 13:00:00

$date = Get-Date
Write-Host "Date = $date"
$m = $date.Minute
$s = $date.Second
$begindate = (($date.AddSeconds(-$s)).AddMinutes(-$m)).addHours(-1)
Write-Host "BiginDate = $begindate"
$enddate = ($date.AddSeconds(-$s)).AddMinutes(-$m)
Write-Host "EndDate = $enddate"

# перевод времени в формат WMI
$wmibegindate=[System.Management.ManagementDateTimeConverter]::ToDMTFDateTime($begindate)
Write-Host "WMIBiginDate = $wmibegindate"
$wmienddate=[System.Management.ManagementDateTimeConverter]::ToDMTFDateTime($enddate)
Write-Host "WMIEndDate = $wmienddate"

$logjournals = "System", "Application", "Security"

foreach ($computer in $computers) {
	Write-Host "Processing computer: $computer"
	foreach ($logjournal in $logjournals) {
		Write-Host "Processing log: $logjournal"
		$systemlog = Get-WmiObject -Class win32_NTLogEvent -filter "logfile = '$logjournal' AND (TimeWritten>='$wmibegindate') AND (TimeWritten<'$wmienddate')" -computerName $computer -Credential $credential -ErrorAction SilentlyContinue
		
        foreach ($logstring in $systemlog) {
			$wmitime = $logstring.TimeGenerated
			$time = [System.Management.ManagementDateTimeconverter]::ToDateTime("$wmitime")
			#Write-Host $logtime
				
			$level = $logstring.Type
			#Write-Host "$level"
				
			$journal = $logstring.LogFile
			#Write-Host "$journal"
			
			$category = $logstring.CategoryString
			#Write-Host "$category"
			
			$source = $logstring.SourceName
			#Write-Host "$source"
			
			$message = $logstring.Message
			#Write-Host "$message"
			
			$code = $logstring.EventCode
			#Write-Host "$code"
			
            @{Server="$computer";Time="$time";Level="$level";Journal="$journal";Category="$category";Source="$source";Message="$message";Code="$code"} | ConvertTo-Json -depth 10 -Compress | Out-File "$logdir\$computer-$logjournal.json" -Encoding utf8 -Append
		}
	}
}

По завершении действия скрипта на выходе получаются файлы вида: ComputerName-JournalName.json.
Формат json несколько не соответствует стандарту (отсутствуют открывающие и закрывающие скобки), но парсер Logstash его нормально переваривает и обрабатывает. Для каждого из серверов создается по три файла: ComputerName-System.json ComputerName-Application.json ComputerName-Security.json Так как файлы имеют одинаковый формат, их обработка идеентична.

Ограничить сбор логов определенным журналом можно простым редактированием строчки: $logjournals = «System», «Application», «Security»

Далее в дело вступает Logstash со следующей конфигурацией:

input {

  file {
    type => "ServersLogs"
    discover_interval => 1800
    path => [ "//storage/Logs/ServersLog/*/*.json" ]
    codec => "json"
  }

}


filter {

  date {
    type => "ServersLogs"
    match => [ "Time", "MM/dd/YYYY HH:mm:ss" ]
    locale => "en"
    target => "Logtimestamp"
  }

  mutate {
    gsub => [ "Level", "[ -]", "_" ]
    gsub => [ "Source", "[ -]", "_" ]
    gsub => [ "Server", "[ -]", "_" ]
    remove_field => ["message"]
    remove_field => ["host"] 
  }

}


output {

  elasticsearch {
    embedded => false
    host => "logserver"
    protocol => "http"
    cluster => "windowseventlogs"
    codec => "plain"
    index => "windowseventlogs-%{+YYYY.MM.dd}"
  }

}

Данные заносятся в Elasticsearch, откуда в дальнейшем отображаются с помощью Kibana.

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

В предыдущей статье мы рассмотрели, как развернуть собственный централизованный сервер сбора лога с различных типов сетевых устройства на базе стека Graylog (
Graylog
+
OpenSearch
+
MongoDB
). В этой статье мы покажем, как настроить отправку журналов событий с серверов Windows (включая события Active Directory) в Graylog.

Настройка сборщика данных и индексов Graylog для устройств Windows

Сначала нужно настроить в Graylog отдельные сборщики данных и потоки для логов, которые будут отправлять хосты Windows Server (чтобы не смешивались события от разных классов устройств). Перейдите в раздел System -> Inputs и добавьте новый сборщик Windows Server Devices типа Beats, который слушает на порту
TCP:5044
.

Картинка с сайта: winitpro.ru

Затем создайте отдельный индекс для логов журналов событий Windows. На базе нового Input и индекса создайте новый поток для Windows в разделе Streams и запустите его.

Картинка с сайта: winitpro.ru

Отправка событий Windows в Graylog с помощью Winlogbeat

Для отправки логов из журналов событий EventViewer с хостов Windows на сервер Graylog можно воспользоваться службой сборщика логов Winlogbeat. Winlogbeat это один из свободно распространяемых компонентов стека ELK. Службу Winlogbeat нужно установить на каждом хосте Windows, события с которого вы хотите видеть на сервере Graylog.

1. Скачайте архив Winlogbeat со страницы загрузки (https://www.elastic.co/downloads/beats/winlogbeat)
2. Распакуйте архив в папку
   C:\Program Files\winlogbeat
3. Отредактируйте конфигурационный файл winlogbeat.yml

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

winlogbeat.event_logs:
  - name: Application
    ignore_older: 72h
  - name: Security
  - name: System
output.logstash:
  hosts: ["192.168.14.146:5044"]

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

winlogbeat.event_logs:
  - name: Security
    event_id: 4627, 4703, 4780-4782
    ignore_older: 24h
    level: critical, error
  - name: Microsoft-Windows-TerminalServicesRDPClient/Operational
    event_id: 1102

Примеры типовой универсальной конфигурации winlogbeat.yml для Windows Server можно посмотреть тут.

Сохраните файл winlogbeat.yml и проверьте корректность конфигурации Winlogbeat и доступность сервера сбора логов:

cd "C:\Program Files\winlogbeat"
./winlogbeat test config
./winlogbeat test output

Если все ОК, установите и запустите службу winlogbeat:

.\install-service-winlogbeat.ps1
Start-Service winlogbeat

Картинка с сайта: winitpro.ru

Перейдите в веб-интерфейсе GrayLog сервера и проверьте, что в соответствующем потоке стали появляться события с ваших серверов Windows.

Картинка с сайта: winitpro.ru

Сбор и анализ событий с контроллеров домена Active Directory с помощью Graylog

Рассмотрим, как использовать сервер Graylog для поиска и анализа событий Windows на примере контроллеров домена Active Directory.

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

Например, вам нужно найти компьютер, с которого была заблокирована учетная запись пользователя из-за неверного ввода пароля. Для этого откройте строку фильтра Graylog, выберите нужный Stream, или укажите его в запросе (
streams:xxxxxxxxxxxxx
) и выполните следующий запрос:

winlogbeat_event_code:(4740 OR 4625) AND winlogbeat_event_provider:Microsoft\-Windows\-Security\-Auditing

Картинка с сайта: winitpro.ru

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

Еще несколько примеров поиска различных событий в Active Directory:

• Event ID 4767 – позволяет определить кто разблокировал пользователя AD
• Event ID 4724 – кто и когда сбросил пароль пользователю домена
• Event ID 4720 – позволяет узнать, кто и когда создал нового пользователя в AD, 4722 – событие включения учетной записи, 4725 – отключение, 4726 – удаление.
• Отслеживание изменения в группах безопасности AD: 4727 (создана новая группа), 4728 (новый пользователь добавлен в группу), 4729 (пользователь удален из группы), 4730 (группа безопасности удалена)
• Event ID 5137 (создана новая групповая политика домена), 5136 (изменена GPO), 5141 (удалена GPO)
• Event ID 4624 — событие успешного входа пользователя в домен (позволяет быстро получить историю входа пользователя в AD)

Важно настроить отправку логов через Winlogbeat со всех контроллеров домена (список активных DC можно получить с помощью команды Get-ADDomainController. Сбор некоторых событий безопасности Active Directory нужно отдельно включить в настройках политик аудита в Default Domain Controller Policy.

Вы можете создать в Graylog сохранённые запросы и dashboardы для быстрого поиска интересующих вас событий. С помощью оповещений можно настроить рассылку алертов о критических событиях в AD.

Централизованное хранилище логов для хостов Windows

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

• Аудит доступа к файлам и папкам на файловом сервере
• Аудит удаления файлов в сетевой папке
• Аудит изменений NTFS разрешений объектов
• Анализ логов RDP подключений
• Обнаружение перебора паролей к RDP серверу
• Определить кто и когда перезагрузил или выключил сервер Windows:
  winlogbeat_event_code:1074
• Реагирование на очистку журналов событий Windows (возможная компрометация сервера)
• Оповещение об обнаружении вируса на одном из серверов Windows встроенным антивирусом Windows Defender (Event ID 1006, 1116)

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

Картинка с сайта: winitpro.ru

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

Передо мной встала задача организовать сбор Windows Event Logs в некое единое хранилище с удобным поиском/фильтрацией/возможно даже визуализацией. После некоторого поиска в интернете я натолкнулся на чудесный стек технологий от Elasticsearch.org — связка ELK (Elasticsearch — Logstash — Kibana). Все продукты являются freeware и распространяются как в виде архива с программой, так и в виде пакетов deb и rpm. 

Что такое ELK?

Elasticsearch

Elasticsearch — это поисковый сервер и хранилище документов основанное на Lucene, использующее RESTful интерфейс и JSON-схему для документов. 

Logstash

Logstash – это утилита для управления событиями и логами. Имеет богатый функционал для их получения, парсинга и перенаправления\хранения.

Kibana

Kibana – это веб-приложение для визуализации и поиска логов и прочих данных имеющих отметку времени.

В данной статье я постараюсь описать некий HOW TO для установки одного сервера на базе Ubuntu Server 14.04, настройки на нем стека ELK, а так же настройки клиента nxlog для трансляции логов на сервер. Хочу однако отметить что данный стек технологий можно использовать гораздо шире. Какие логи вы будете пересылать, парсить, хранить и в последствии пользоваться поиском\визуализацией по ним зависит только от вашей фантазии. По использованию данных технологий есть множество вебинаров на сайте http://www.elasticsearch.org/videos/.

Установка Ubuntu 14.04

Дабы не повторяться с установкой дистрибутива Ubuntu 14.04 приведу ссылку на статью моего коллеги по блогу, Алексея Максимова — Настройка прокси сервера Squid 3.3 на Ubuntu Server 14.04 LTS. Часть 1. Установка ОС на ВМ Hyper-V Gen2. Все действия по настройке можно проделать аналогичные, за исключением установки минимального UI и настройки второго сетевого интерфейса – его можно исключить на стадии создания виртуальной машины, ведь сервер будет находиться внутри периметра вашей сети. 

Установка JAVA 7

Так как два из трех используемых продуктов написаны на JAVA нам придется его установить. Устанавливать будем Oracle Java 7, так как Elasticsearch рекомендует устанавливать именно его.

Добавляем Oracle Java PPA в apt:

sudo add-apt-repository -y ppa:webupd8team/java

Обновляем репозиторий:

sudo apt-get update

И устанавливаем последнюю стабильную версию Oracle Java 7:

sudo apt-get -y install oracle-java7-installer

Проверить версию Java можно набрав команду

java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

Установка Elasticsearch

Хотя документация по Logstash рекомендует использовать Elasticsearch версии 1.1.1, он прекрасно работает и с последней стабильной версией 1.3.1. Именно ее мы и установим.

Добавляем публичный GPG ключ в apt:

wget -O - http://packages.elasticsearch.org/GPG-KEY-elasticsearch | sudo apt-key add -

Создаем source list apt:

echo 'deb http://packages.elasticsearch.org/elasticsearch/1.3/debian stable main' | sudo tee /etc/apt/sources.list.d/elasticsearch.list

Обновляем репозиторий:

sudo apt-get update

И устанавливаем Elasticsearch 1.3.1:

sudo apt-get -y install elasticsearch=1.3.1

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

Открываем elasticsearch.yml:

sudo nano /etc/elasticsearch/elasticsearch.yml

И раcкомментируем строки “cluster.name: elasticsearch” и “node.name: «Franz Kafka»”. Вместо значений по умолчанию можно указать свои.

Создаем скрипты автозапуска elasticsearch:

sudo update-rc.d elasticsearch defaults 95 10

Перед стартом сервера я рекомендую установить еще два плагина к elasticsearch – head и paramedic. Первый позволяет управлять сервером поиска и индексами документов, второй следит за “здоровьем” пациента, выводя графики с различной полезной информацией.

Плагины к elasticsearch устанавливаются с помощью команды plugin прямо из github:

sudo /usr/share/elasticsearch/bin/plugin --install mobz/elasticsearch-head
sudo /usr/share/elasticsearch/bin/plugin --install karmi/elasticsearch-paramedic

Доступ к результатам работы плагинов можно получить через url вида http://elasticsearch.server.name:9200/_plugin/head/ или http://elasticsearch.server.name:9200/_plugin/paramedic/

После чего можно запускать сам сервер:

sudo service elasticsearch start

Установка Kibana

Так как Kibana это веб-приложение, перед его установкой нужно установить веб-сервер. Я воспользовался простейшим nginx.

sudo apt-get install nginx

Создаем папку www для будущего приложения:

sudo mkdir /var/www

Даем nginx права на папку:

sudo chown -R www-data:www-data /var/www

Скачиваем последний архив с файлами Kibana (на настоящий момент это kibana-3.1.0.tar.gz):

wget https://download.elasticsearch.org/kibana/kibana/kibana-3.1.0.tar.gz

Распаковываем архив:

tar zxvf kibana-3.1.0.tar.gz

И копируем его содержимое в папку /var/www:

sudo cp -r kibana-3.1.0/* /var/www/

Скачиваем файл конфигурации для работы Kibana под nginx:

wget https://github.com/elasticsearch/kibana/raw/master/sample/nginx.conf

Открываем его в редакторе nano и указываем в какой папке лежат файлы Kibana:

Заменяем строку
root  /usr/share/kibana3;

на строку
root  /var/www;

Копируем данный файл как файл по умолчанию для nginx:

sudo cp nginx.conf /etc/nginx/sites-available/default

И перезапускаем nginx:

sudo service nginx restart

Теперь если перейти по адресу http://elasticsearch.server.name/ мы увидим стартовый дашборд Kibana. Если вы не планируете создавать других дашбордов, то можно сразу поставить по умолчанию дашборд Logstash.

Для этого нужно заменить файл дашборда по умолчанию на файл дашборда Logstash:

sudo cp /var/www/app/dashboards/logstash.json /var/www/app/dashboards/default.json

Основные настройки Kibana находятся в файле config.js по адресу /var/www/config.js, однако “из коробки” все работает замечательно.

Установка Logstash

Добавляем source list Logstash в apt:

echo 'deb http://packages.elasticsearch.org/logstash/1.4/debian stable main' | sudo tee /etc/apt/sources.list.d/logstash.list

Обновляем репозиторий:

sudo apt-get update

И устанавливаем Logstash:

sudo apt-get install logstash

Logstash установлен, однако конфигурации у него нет. Конфигурационный файл Logstash состоит из 3х частей – input, filter и output. В первой определяется источник событий или логов, во второй с ними производятся необходимые манипуляции, и в третей части описывается куда обработанные данные нужно подавать. Подробно все части описаны в документации http://logstash.net/docs/1.4.2/ и есть некоторые примеры.

Для текущей задачи, мною была написана следующая простая конфигурация:

Создадим файл в папке конфигураций Logstash

sudo nano /etc/logstash/conf.d/10-windowslog.conf

И поместим туда следующую конфигурацию

input {
    tcp {
        type   => "eventlog"
        port   => 3515
        format => 'json'
    }
} filter { 
} 
 
output {
    elasticsearch {
        cluster => "elasticsearch"
        node_name => "Franz Kafka"
    }
}

Разберем по порядку:

В разделе input

tcp {} — открывает tcp порт и слушает его

type => “eventlog” говорит Logstash что на входе будут данные типа eventlog (известный формат полей для Logstash)

port => 3515 – номер потра

format => ‘json’ – говорит Logstash о том, что данные придут “обернутые” в JSON

Никаких манипуляций с логами я не совершаю, потому раздел filter у меня пустой. Хотя если Вам будет необходимо, к примеру, привести дату к нужному формату, или убрать из лога одно или несколько полей, то в данном разделе можно эти манипуляции описать.

В разделе output

elasticsearch {} – оправляет данные в elasticsearch

cluster => “elasticsearch” – указывает на имя кластера, что мы указывали при конфигурировании Elasticsearch

node_name => “Franz Kafka” – указывает на имя ноды.

Сохраняем файл и запускаем Logstash

sudo service logstash start

Можно проверить что порт tcp 3515 слушается командой:

sudo netstat -a | grep 3515

Установка nxlog

Идем на сайт nxlog (http://nxlog.org/download) и скачиваем саму свежую версию для Windows.

Устанавливаем на нужной Windows машине данный клиент. Настройки он хранит в файле nxlog.conf по адресу по умолчанию “c:\Program Files (x86)\nxlog\conf\” (для 32-битной версии “c:\Program Files\nxlog\conf\”).

Для решения данной задачи я написал конфигурационный файл следующего содержания:

## This is a sample configuration file. See the nxlog reference manual about the
## configuration options. It should be installed locally and is also available
## online at http://nxlog.org/nxlog-docs/en/nxlog-reference-manual.html 
## Please set the ROOT to the folder your nxlog was installed into,
## otherwise it will not start.
 
#define ROOT C:\Program Files\nxlog
define ROOT C:\Program Files (x86)\nxlog
 
Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log
 
<Extension json>
    Module      xm_json
</Extension>
  # Windows Event Log
<Input eventlog>
# Uncomment im_msvistalog for Windows Vista/2008 and later 
   Module im_msvistalog
       Query <QueryList>                                                                         \
             <Query Id='1'>                                                                      \
              <Select Path="Application">*[System[(Level=1  or Level=2 or Level=3)]]</Select>    \
              <Select Path='Security'>*</Select>                                                 \
              <Select Path="System">*[System[(Level=1  or Level=2 or Level=3)]]</Select>         \
             </Query>                                                                            \
           </QueryList>
  # Uncomment im_mseventlog for Windows XP/2000/2003
#   Module im_mseventlog
    Exec to_json();
</Input>
 <Output out>
   Module om_tcp
   Host 10.0.2.8
   Port 3515
</Output>
 <Route 1>
   Path eventlog => out
</Route>

У nxlog конфигурационный файл так же состоит из нескольких частей – это Extension, Input, Output и Route. Об устройстве конфигурационного файла nxlog можно почитать в документации к nxlog (http://nxlog.org/nxlog-docs/en/nxlog-reference-manual.html).

Могу отметить следующие детали – в разделе Input используется модуль im_msvistalog (для операционных систем Vista/2008 +) для более старых ОС нужно раскомментировать строку с указанием на модуль im_mseventlog. Модуль im_msvistalog позволяет фильтровать логи через XPath запрос (подробнее тут — http://msdn.microsoft.com/en-us/library/aa385231.aspx). В приведенном конфигурационном файле выбираются логи из трех источников – это журналы Application, Security и System, причем из Application и System выбираются только Critical, Error и Warning логи, для Security выбираются все логи, так как они там другого типа – Info. Команда Exec to_json; “оборачивает” данные в JSON формат.

В разделе Output указывается модуль om_tcp для отправки данных по протоколу tcp, указывается хост и порт подключения.

Раздел Route служит для указания порядка выполнения действий, так как клиент nxlog умеет читать из множества источников и отсылать во множество приемников. Все это можно подчерпнуть из документации к продукту.

Настроив конфигурационный файл не забудьте его сохранить и можно запускать клиент через оснастку Службы (Services) или через командную строку:

net start nxlog

Использование

Открыв в браузере Kibana (и перейдя на дашборд Logstash, если он у Вас не по умолчанию) мы увидим после всего проделанного следующую картину.

Картинка с сайта: blog.it-kb.ru

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

Обратив свое внимание на таблицу данных мы увидим что данные показаны в “сыром” виде, однако слева от таблицы есть список полей. Щелкнув последовательно по чекбоксам с полями EventID, EventTime, EventType, Hostname, Sevirity, Message, Channel, мы получим уже более читабельный вид таблицы:

Картинка с сайта: blog.it-kb.ru

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

Картинка с сайта: blog.it-kb.ru

Если кликнуть по символу лупы рядом с именем процесса, то создастся фильтр по этому имени.

Картинка с сайта: blog.it-kb.ru

А данные в таблице отобразятся в соответствии с фильтрами.

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

Картинка с сайта: blog.it-kb.ru

Ну и наконец если я просто хочу поискать по всем полям словосочетание “System Center” в поле запроса я пишу “System Center”. В случае поиска по конкретному полю можно воспользоваться конструкцией FieldName:”SearchQuery”, например ProcessName:»System Center». Что бы исключить из выборки данные найденные с помощью конструкции можно воспользоваться оператором “-“, например -ProcessName:»System Center» или -“System Center”. Так же работают операторы OR и AND.

Более подробно о возможностях Kibana + Logstash + Elasticsearch можно узнать из документации и вебинаров на сайте elasticsearch.org. Здесь я показал лишь малую толику того что может эта замечательная связка инструментов.

При подготовке статьи я пользовался следующими источниками:

http://www.elasticsearch.org/

http://nxlog.org/

https://www.digitalocean.com/community/tutorials/how-to-use-logstash-and-kibana-to-centralize-and-visualize-logs-on-ubuntu-14-04

http://www.ragingcomputer.com/2014/02/logstash-elasticsearch-kibana-for-windows-event-logs