Передо мной встала задача организовать сбор 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 logstashLogstash установлен, однако конфигурации у него нет. Конфигурационный файл 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, если он у Вас не по умолчанию) мы увидим после всего проделанного следующую картину.
Центральный график на дашборде отражает количество записей в единицу времени. Сверху находится строка запроса и панель управления дашбордом. В нижней части таблица с данными.
Обратив свое внимание на таблицу данных мы увидим что данные показаны в “сыром” виде, однако слева от таблицы есть список полей. Щелкнув последовательно по чекбоксам с полями 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. Здесь я показал лишь малую толику того что может эта замечательная связка инструментов.
При подготовке статьи я пользовался следующими источниками:
http://www.ragingcomputer.com/2014/02/logstash-elasticsearch-kibana-for-windows-event-logs
RSS - Записи
Спасибо Александр за интересный материал. Сразу вопрос по теме - каким образом организовано хранение собираемых логов? Я так понимаю это какая-то БД? Подобные вопросы могут возникнуть в контексте рассуждения о том, можно ли описанную связку считать полноценным аналогом роли Audit Collector из SCOM. Какие у тебя мысли есть по этому поводу?
Это не совсем БД, хотя наверное и можно сравнить с NoSQL решениями. Elasticsearch это фронт-енд к индексу Lucene. То есть по сути движок собирает наши логи в индексы и позволяет производить по ним поиск. Кстити только сейчас понял что я не описал процесс ротации логов (нужно будет настроить cron на ежедневное выполнение команды по очистке индексов старше N дней - ну думаю допишу попозже).
Можно ли считать связку полноценным аналогом роли Audit Collector - безусловно да. Тем более что Audit Collector (следуя из названия) собирает только Audit (Security) логи, решение ELK может собирать любые логи, если говорить только об Windows Event Logs, то помимо стандартных Application/Security/System можно так же собирать логи приложений и служб, например Windows Powershell, Internet Explorer или Microsoft-Windows-Hyper-V-Hypervisor-Admin лог. Что посылать - описывается в конфиге клиента nxlog. Так что связка ELK на мой взгляд на много лучше, удобнее и более гибкая.
То есть система позиционируется как кратковременное хранилище логов, или она способна нормально себя вести со всеми накопленными App/Sys/Sec логами например с 50 серверов на базе Windows с хранением логов скажем в течение года?
Всё таки интересно было бы услышать какие-то реальные цифры по размеру накопленных данных с N-серверов за N-период времени :)
Такой информации дать пока не могу. Пока что размер суточного индекса с 4х серверов составляет около 1Б можно попробовать экстраполировать данную информацию на 50 серверов - ~12-15ГБ суточный индекс. ~450ГБ логов с 50 серверов за месяц. Не уверен что реально хранить годовой запас логов =) хотя возможно кому то не жалко 5-6ТБ под логи.
Я собираюсь собирать логи в одно хранилище примерно с 60-70 серверов - будем посмотреть сколько это будет на практике. Уверен что после начального периода эксплуатации мы исключим из выборки логов некоторые типы логов для экономии, руководствуясь необходимостью и целесообразностью.
На счет работы при высокой нагрузке - сам пока не видел как она работает при большом количестве информации, но судя по видео и статьям - основной use case ELK это сбор access логов с web-серверов apache2/nginx - сам понимаешь, если сайты на веб-серверах посещаемые, то количество логов исчисляется миллионами.
Ну что ж, решение безусловно интересное, но будем ждать от тебя рассказа о результатах использования хотя бы в двух-трёх месячном опыте. Интересно также будет услышать, как себя будет вести на практике nxlog-клиент на Windows системах с сильной активностью в логах, например тех же контроллерах домена Active Directory.
Александр, Вы хотели описать процесс ротации логов, есть наработки ? Очень интересует эта тема.
Александр, спасибо за статью.
Соглашусь с Алексеем, что очень хотелось бы услышать отзывы об эксплуатации под нагрузкой - ждемс.
И второй момент, как перевариваются(импорт/поиск) сообщений в кириллице? У нас часть серверов русская версия, часть английская.
С кодировкой проблем не заметил - все хранится в UTF-8, поле Message прекрасно отображается на русском.
Поделитесь пожалуйста кто-нибудь шаблонами для парсинга с eventlog :)
А что конкретно вы хотите парсить то?
Логи с контроллера домена
А проблема то в чем? Ставите nxlog на контроллер домена, прописываете запрос для фильтрации логов и вперед! =)
А как должен выглядеть такой запрос? Можно ли сформировать его средствами модуля im_msvistalog? В мане по nxlog перечислены поля, генерируемые im_msvistalog ($Message, $EventTime и т.д.) но не описан синтакс их применения. Можно сделать так, чтобы выборка нужных к отправке полей осуществлялась на этапе запроса?
Query \
\
*[System[(Level=1 or Level=2 or Level=3)]] \
* \
*[System[(Level=1 or Level=2 or Level=3)]] \
\
Я так понимаю, этот модуль можно использовать как фильтр, но только по совпадению значений полей, а не для выбора самих полей к отправке?
Вероятно вам нужен блок Processor в конфиге nxlog (см. документацию) там можно использовать модуль фильтрации pm_filter и модуль Pattern matcher (pm_pattern), с их помощью можно будет фильтровать записи логов. Про поля не уверен что их получится удалять на этапе обработки в nxlog, а вот поудалять ненужные поля на стадии прохождения записи лога через logstash можно (раздел конфига filter). Простой пример описан в документации:
filter {
drop {
remove_field => [ "foo_%{somefield}" ]
}
}
4.4.1.5 Processors
The ’Processors’ directive has been obsoleted and is no longer available.
Нашел еще в мануале по nxlog такую фичу:
\
Module im_msvistalog
Exec if ($TargetUserName == ’SYSTEM’) OR ($EventType == ’VERBOSE’) drop();
\
Воткнул её в свой конфиг под видом
Exec if ($EventID == ’4624’) drop();
Не работает :( в логе пишет 2014-08-14 16:39:23 ERROR Couldn't parse Exec block at C:\Program Files (x86)\nxlog\conf\nxlog.conf:36; couldn't parse statement at line 36, character 19 in C:\Program Files (x86)\nxlog\conf\nxlog.conf; syntax error, unexpected =
Походу фильтровать можно только логстэшем?
Почему-то не могу ответить на ваш нижний комент, отвечу сюда.
У вас не правильно написана строка для конфига.
Правильно будет так:
Exec if $EventID == 4624 drop();
Попробуйте. Кстати возьму это на вооружение, когда буду парсить логи контроллера домена.
А так работает! Благодарю! Странно что в мануале дан нерабочий пример со скобками.
Ну почему же не рабочий, там как раз рабочий - ведь там используется поле типа string и потому нужно обрамлять значения кавычками. А тут поле типа Int, его и нужно указывать. Скобки я думаю там ни причем, они для порядка операций.
Вложенность комментариев - 5 штук. Гораздо проще использовать функцию простой отправки коммента, тем более, что обсуждение здесь не такое уж и многолюдное :). Вообще Александр если нужно будет сделать отдельную ветку на форуме - говори. Там наверняка будет проще подобные обсуждения проводить.
Может подскажете, из-за чего некоторые сообщения от nxlog'a в json приходят с "забэкслешенными" кавычками? Из-за этого logstash не может их парсить. Например {\"EventTime\":\"2014-08-18 17:09:15\",\"Keywords\":-9223372036854775808,\"EventType\":\"WARNING\",\"SeverityValue\":3,\"Severity\":\"WARNING\",\"EventID\":1530, и т.д.?
Причем, если направить вывод nxloga помимо tcp в файл, там все пишется корректно, без бэкслешей.
Не запускается при старте системы конфиг-файл по пути /etc/logstash/conf.d/ Платформа ubuntu 14.04 Kibana не отображает процесс.. При ручном запуске через bin/logstash agent -f все работает! Помогите разобраться!
в /var/log/logstash.log чего пишется? Первым делом смотрите логи.
Постоянно пишет очень странную вещь: {:timestamp=>"2015-02-18T11:09:01.760000+0400", :message=>"failed to open /var/log/syslog: Permission denied - /var/log/syslog", :level=>:warn} Дело в том что я в качестве теста беру логи с файла syslog
Permission denied - ошибка доступа же, ну! Проверяйте доступ от учетной записи из под которой запускается logstash.
Есть лог:
{"message":"1353480: CORE-DSS: Mar 10 06:22:06.711: %SEC-6-IPACCESSLOGP: list inside_DSS denied udp 10.22.110.61(60980) -> 255.255.255.255(1947), 1 packet ","@version":"1","@timestamp":"2015-03-10T07:11:31.697Z","type":"all_log","host":"10.23.0.200"}
На выходе надо получить хотя бы:
denied udp 10.22.110.61(60980) -> 255.255.255.255(1947)
В идеале так:
2015-03-10T07:11:31 denied udp 10.22.110.61(60980) -> 255.255.255.255(1947) host 10.23.0.200
Пишу простой конфиг:
input {
udp {
type => "all_log"
port => 3000
}
}
filter {
grok {
type => "all_log"
pattern => "%{WORD} %{PROG} %{NOTSPACE} -> %{NOTSPACE}"
}
}
output {
elasticsearch {
embedded => "true"
host => localhost
}
file {
type => "all_log"
path => "/srv/LOG/LOG_all/all.oblast.log"
}
}
Лог Logstash ругается
message=>"Using milestone 2 output plugin 'file'. This plugin should be stable, but if you see strange behavior, please let us know!
Что не так? И как сделать второй вариант? Подскажите пожалуйста! Решение данной задачи будет мне хорошим примером! И ещё, какие надо подтянуть знания, чтобы писать фильтры и не задавать глупые вопросы :) Заранее спасибо за ответ!
По задаче не могу ничего сказать. Давно ничего не парсил логстэшем.
По ошибке могу лишь предположить что проблема в строке "type" => "all_logs" для раздела output -> file. Согласно документации (http://logstash.net/docs/1.4.2/outputs/file) у типа file (milestone 2) нет поля type (возможно оно было в milestone 1 или 0). На это и указывает логстэш.
Что бы писать фильтры читайте документацию. Еще есть книга (Logstash Book http://www.logstashbook.com/) но она стоит денег. Вообще попробуйте понять логику работы логстэша, по шагам. Вот он получает что то (по tcp/udp/file...), вот фильтрует, вот пишет в output... когда поймете как ваши правила работают, будет проще.
После установки ELK заметил ещё такую проблему: если в браузере набрать IP-адрес сервера и порт 9200 то вместо графического интерфейса elasticsearch отображает лишь строки по типу этих.
{
"status" : 200,
"name" : "Franz Kafka",
"version" : {
"number" : "1.3.1",
"build_hash" : "2de6dc5268c32fb49b205233c138d93aaf772015",
"build_timestamp" : "2014-07-28T14:45:15Z",
"build_snapshot" : false,
"lucene_version" : "4.9"
},
"tagline" : "You Know, for Search"
}
Установил также фильтры по вашей инструкции, но при их вызове в окне браузера ничего не отображается- пустой экран. Возможно проблема в конфигурационном файле для Apache т.к. я писал свой, очень упрощенный, указав в нём работу веб приложений по 80 и 9200 порту. Если вам известна данная ошибка или может быть вы знаете где взять "полноценный" конфиг для Apache буду очень признателен!
У ELK нет никакого графического интерфейса. ELK это аббревиатура из продуктов Elasticsearch (REST API которого живет как раз на порту 9200), Logstash (у которого вообще нет никакой веб-морды) и Kibana (которая как раз является веб-приложением и живет под nginx).
О каких фильтрах речь - не понятно.
Конфиг для Кибаны под nginx указан в статье (продублирую https://github.com/elasticsearch/kibana/raw/master/sample/nginx.conf). Конфига под Апач у меня нет, но думаю что его можно списать с конфига nginx, сделав соответствующие адаптации. Собственно вопрос - а чем nginx не устраивает? Он простой и удобный.
Уже появились полу-платные сборки :)
http://www.sexilog.fr/features/
Толково! Мне нравится. Надо будет развернуть и потестить.
habr тоже решил об этом написать :)
"Централизованый сбор Windows event логов, без установки агента, с последующей визуазизацией средствами ELK "
http://habrahabr.ru/post/255815/
Добрый день, отличная статья, легка для понимания даже новичкам. Но вот в чем проблема, при переходе по ссылке, для скачивания конфига nginx, она дает 404 ошибку. Как можно устранить эту проблему или найти альтернативный путь?
Андрей, Kibana 4.2.0, уже переписана на node.js
https://github.com/elastic/kibana
Ссылка на гитхаб выше - качаете, правите конфиг, запускаете. С Кибаной вообще меньше всего проблем.
Это значит, что nginx не нужен? Не совсем понимаю...
Алексей, это значит что nginx ВООБЩЕ не нужен. =) У проекта Кибана теперь новая веб-платформа - node.js, в состав которой входит пакет, реализующий web-сервер. Так что просто установите Кибану в соответствии с инструкциями.
Спасибо!
Еще вопрос:
"Если вы не планируете создавать других дашбордов, то можно сразу поставить по умолчанию дашборд Logstash.
Для этого нужно заменить файл дашборда по умолчанию на файл дашборда Logstash:
sudo cp /var/www/app/dashboards/logstash.json /var/www/app/dashboards/default.json"
Что-то нет этих файлов. Тоже что-то поменялось?
Открываю в браузере Kibana и там пусто. Он мне предлагает вручную создать графики.
Алексей, статье уже год. За этот год проект Кибана претерпел значительные изменения. С ним нужно заново разбираться, как он работает и как правильно его подключить к ElasticSearch. Я, к сожалению, сейчас не имею возможности развернуть этот продукт, так как нахожусь в коммандировке. Боюсь вам придется самому читать мануалы по Кибане и настраивать ее.
ОК! Спасибо.
Друзья может для кого то это важно,
чистку индексов настроил через cron на хосте ELK
добавил запись в crontab -e 0 0 * * 1 /usr/bin/curl -XDELETE 'http://localhost:9200/logstash-2016.06.29/'
Очищать индекс каждый понедельник,
Для уменьшения индекса в конфиге nxlog добавил строку
Exec if $EventID == 4624 drop(); - одна строка на каждое событие которое я не хочу мониторить в итоге лог уменьшился в 10 раз
Автору статьи огромный спасибос.
Не за что. Только ELK так перелопатили сильно (особенно Kibana) что статью надо бы переписать, да все времени нет.
Александр, а чем сейчас собираете и анализируете логи?
Сейчас, Евгений, я сильно сменил специализацию и занимаюсь VMware, потому использую их чудесный продукт Log Insight. Продукт к сожалению платный, однако по функционалу очень мощный и удобный и довольно простой в освоении.
В версии 3.3 появился отличный query-API (REST) по работе с которым через powershell я постараюсь написать тут, как только появится время.
А данная статья сильно устарела, так как сам ELK сильно изменился, однако недавно помогал коллеге разворачивать его и могу сказать что ELK (Kibana в частности) стала только удобнее. И если воспользоваться данной статьей не как how-to, а как изложением идеи - можно саму разобраться как сделать все на новом ELK, будет даже удобнее.
Так же для сбора и анализа логов можно использовать GFI EM но он платный :-( , опять же если вы хотите собирать хранить логи то ELK вполне с этим справляется. Чем больше логов, тем выше производительность и свободное место.