Централизованный сбор Windows Event Logs с помощью ELK (Elasticsearch — Logstash — Kibana)

Передо мной встала задача организовать сбор 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:

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

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

Установка Elasticsearch

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

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

Создаем source list apt:

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

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

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

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

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

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

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

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

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

Установка Kibana

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Установка Logstash

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

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

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

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

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

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

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

В разделе 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

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

Установка nxlog

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

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

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

У 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) или через командную строку:

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

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

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

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

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

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

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

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

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

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

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

NXLog & Windows Event Log

This guide will show you how to send your Windows Event Log to Loggly . It uses the free and open source Nxlog tool to send your logs. We will also automatically parse your logs so you can easily search them.

This guide was written for Windows Vista or later in 64-bit. It assumes you have the latest version of nxlog in the default installation directory, and can send TCP events out on port 514.

For alternatives, please see the Advanced Options Windows logging section, or visit our logging guide for Windows logging basics, troubleshooting with Windows logs, or centralizing Windows logs.

Make sure to replace the CUSTOMER_TOKEN in the config file with your specific token found under Source Setup > Customer Tokens.

1. Install Nxlog

Download the latest version of nxlog. It’s probably easiest to choose the Windows msi file which includes an installer.

2. Copy the Configuration

Open the Nxlog configuration file at:

C:\Program Files (x86)\nxlog\conf\nxlog.conf

Replace the entire configuration file by pasting the following, and replacing the variables below.

Replace the above variables:

• CUSTOMER_TOKEN : Replace with your own customer token
• ROOT and ROOT_STRING : If you are in 32-bit Windows, uncomment the top root path on lines 8 and 9 to use the 32-bit program files folder then comment the two below.

Note: The pm_buffer module supports disk based message buffering and helps in storing logs during network outage, it also send buffered logs when network connection is re-established. You can increase or decrease the MaxSize under the pm_buffer module according to your requirement of disk buffer.

3. Restart Nxlog

Open the Services tool in the Start menu, find nxlog in the list, and then restart the service.

4. Verify

Verify it shows up in Loggly by doing a search for the windows tag over the past hour. If it doesn’t work, see the troubleshooting section below.

Click on one of the logs to show a list of JSON fields (see screenshot below). If you don’t see them, please check that you are using one of our automatically parsed formats.

5. Next Steps

• Troubleshooting with Windows Logs – Use your logs to troubleshoot failed login attempts, application crashes, service failures, and more.
• IIS Logs
• SQL Server Error Logs
• Windows File Monitoring

Advanced NXLog & Logging From Windows Options

• Nxlog with TLS – for secure encrypted data transmission
• Syslog-NG for Windows – with commercial support from Balabit
• Event Forwarding – Windows 2008/Windows 7 and up include «Event Forwarding». Events can be forwarded to a central server which are then stored on the server under the «Forwarded Events» category in the event viewer. Nxlog can be installed on the central server which would then be able to forward events via Syslog to Loggly .
• Search or post your own NXLog documentation and logging from Windows question in the community forum.
• Nxlog supports buffer to store the logs during a temporary network outage and send those buffered logs to Loggly when network is back.
• The pm_buffer module in above nxlog.conf file supports buffer implementation.
• Configuration to monitor RDP logs in Windows:
• How to monitor a value in Windows logs and then add it as a tag:

This below config has:

1. A regex to extract a field, and store it.
2. Use the field to add a new tag.
3. Inject additional JSON keys in the event.
4. A local buffer of 100 MB.

Troubleshooting Windows Logging

If you don’t see any data show up in the verification step, then check for these common problems.

• Check our guide on Troubleshooting Nxlog
• Search or post your own question in the community forum.

When the APM Integrated Experience is enabled, Loggly shares a common navigation and enhanced feature set with the other integrated experiences’ products. How you navigate the product and access its features may vary from these instructions. For more information, go to the APM Integrated Experience documentation.

The scripts are not supported under any SolarWinds support program or service. The scripts are provided AS IS without warranty of any kind. SolarWinds further disclaims all warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The risk arising out of the use or performance of the scripts and documentation stays with you. In no event shall SolarWinds or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the scripts or documentation.

Developed by network and systems engineers who know what it takes to manage today’s dynamic IT environments, SolarWinds has a deep connection to the IT community.

The result? IT management products that are effective, accessible, and easy to use.