Учимся готовить Log4j + Logstash + ElasticSearch + Kibana 3 + Auth (Google OAuth2/BasicAuth/CAS Authentication)

[morkot]

Спасибо за статью!

Только зачем все это ставить и настраивать в ручную, когда есть Chef cookbook?

[script88]

Какой смысл использовать комбайн, когда можно затратить куда меньше времени на единичный случай?!

[morkot]

Если вы считаете, что команды типа:
— vagrant provision
— chef-solo
— knife bootstrap
— другой способ
занимает больше врмени, тогда ОК.

[Ipeacocks]

Все кроме вас так считают.

[morkot]

А не много ли вы на себя берёте, отвечая за всех?

[script88]

Если нет chef`а? Установить предложите ?!

[egor_masalitin]

Примерное время настройки этого решения для одного проекта 1-2 часа, для моих целей это было лучшим вариантом.

[Jimilian]

Не vim, а less. Если речь про просмотр. Не less, a grep — если про первичный анализ. А так, себя хорошо зарекомендовал awk.
Но logstash не о том, чтобы просто посмотреть логи. Он про то, чтобы собрать эти логи с кучи источников/серверов в одном месте, и сделать их анализ быстро и удобно. С поиском, регулярками и прочим.
Обычный же файл логов, т.е. сырые данные тоже нужны. Но только после того, когда понятно, что и где мы ищем.

[igor_suhorukov]

Вполне можно пользоваться только kibana для просмотра и не заходить на хост для grep/awk. Для этого нужны фильтры по времени + фильтр по хосту, приложению и его инстансу. Попробуйте на гистограмме в kibana выделить участок с помощью мыши ;-)

[isden]

Я как-то ради интереса пробовал открыть в vim лог на 10+ гигов. Через несколько минут плюнул и прибил процесс.

[CyberFlow]

А этот патч для kibana решает проблему с тем, что при использовании embedded elasticsearch он торчит «голым задом» наружу? А то штатные средства авторизации kibana прикрывают только web-мордочку, при этом обычным curl можно получить дынные с server_ip:9200.

[egor_masalitin]

Нет, оно также прикрывает только веб морду, ElasticSearch отдельный модуль, и безопасность там я решал другим способом. Фактически это можно решить открывая только 2 порта с сервера
1. Для обмена логами (Доступ открывался только для ip адресов серверов с приложениями)
2. Для веб морды
Остальные составляющие крутятся внутри, и доступ к ним есть только локально.

[CyberFlow]

Тогда у меня вопрос: чем лучше авторизация средствами этого прокси-патча, к тому же требующего node.js на сервере, чем обычная base auth средствами apache или nginx? Есть очевидные плюсы, если не считать фишек типа Google OAuth2?

[egor_masalitin]

Я выбрал именно этот вид авторизации из за возможной масштабируемости, и лично для меня было проще развернуть этот вид аутентификации, по причине простоты использования и конфигурирования, не хотелось настраивать все это вручную. Также требовалось минимальное время настройки системы, а учитывая уже предустановленный node.js на сервере, это был хороший вариант. Однако вы правы, в части случаев возможно удобнее настроить обычную аутентификацию средствами apache или nginx, будет интересно это попробовать.

[CyberFlow]

Спасибо за ответы, аргументацию понял. Просто смутило, что пароли хранятся плэйнтекстом и node.js.

[egor_masalitin]

В своем проекте я использовал Google OAuth2, base auth использовал в статье для демонстрации работы системы. Так как ее быстрее и проще всего настроить и показать.

[igor_suhorukov]

В нашем приложении настроил jetty proxy servlet, прикрутил websso фильтр, интегрированный с корпоративным LDAP и живем счастливо и безопасно. Если боитесь update,delete REST запросов, можно создать фильтр по url и также отключить в ES выражения на mvl и groovy и т.п.

[houk]

в заголовке опечатка — Logj4

[egor_masalitin]

Спасибо, исправил

[javax]

А можно ли так по логам искать? Делать срезы по времени, по log level, поиск по тексту?

[egor_masalitin]

Да, можно настраивать фильтрацию как угодно, допустим если нас интересуют только ERROR логи, с текстом начинающимся на Hibernate, и которые были выброшены из определенного класса. К тому же между ними удобно переключаться, по поводу срезов во времени, то возможно или задать рамки явно в фильтрах, или просто на веб морде выделить мышкой необходимый диапазон. Подробней про фильтры можно прочитать тут

[Jimilian]

Если верить документации log4j, у SocketAppender'a есть существенный недостаток: если хост, на который нужно писать логи, упал, то приложение, пишущее логи, встаёт колом. Есть ли где-нибудь на просторах Open Source реализация SocketAppendera с буфером и просто дропающая логи при его переполнении?

[egor_masalitin]

Это не совсем так, при выключенном севере принимающем логи(в нашем случае Logstash) логи просто не доходят до него, но:
1. Приложение продолжает работать, и писать логи в файлы как и ранее.
2. Через определенные интервалы времени пытается восстановить подключение, и если оно восстановлено, то передача логов возобновляется.
Данная система является надстройкой, дополнительной системой, упрощающей работу с логами, особенно если речь идет о логах от разнообразных сервисов.
Если вы найдете способ реализации «SocketAppendera с буфером» напишите в комментариях или лс, так как это было бы действительно интересно.
Однако также эту систему можно настроить не только на Log4j, но и фактически на любую другую подобную технологию. В моем случае необходима была работа именно с Log4j, без возможности замены.

[Jimilian]

Тогда еще два вопроса:

1. А при упавшем хосте и/или потере коннекта (сетка моргнула/упала) до хоста какое будет поведение?
2. Если верить опять же документации, если соединение есть, но при этом канал забит/слаб, то скорость работы приложения будет ограничена скоростью записи в этот канал?

Правда, я, по умолчанию, веду речь о старом добром Log4j версии 1, на смену которому в июле вышел Log4j версии 2, в котором, как я понял, можно сделать всё логирование асинхронным. Но у меня опыта работы с ним нет, поэтому о минусах говорить не могу.

[egor_masalitin]

Я использую Log4j 1 версии.
1. Проясните ситуацию, я не совсем понял вопрос
2. Я тестирую эту систему уже 3 месяца, и за все это время задержек в работе программы не обнаруживал, хотя бывало что и виртуалка падала, или вообще могла пару дней не работать, соединение нормально восстанавливалось, и все продолжало стабильно работать.

Единственное что как то обнаружил, это то, что нужно проверять правильная ли дата стоит на самом сервере, так как иначе могут быть проблемы плана: кинули лог, а он не отображается, и появляется только через минут 10, так как по временным рамкам он в другом диапазоне, так что нужно проверять что бы дата и время всегда были правильными.

[Jimilian]

1. Из документации:

   In particular, if the network link to the the server is down, the client will be blocked.

   
   Т.е., допустим, ваш сервер LogStash поднят на хост с ip = 192.168.206.1, при этом падает не LogStash, а сеть, т.е. узел 192.168.206.1 становится недоступен.
2. Возможно, в вашей системе не тот объем логов/отличный канал между клиентом (приложением) и сервером (logStash)/лаг в десяток миллисекунд не заметен.

Синхронизация времени на серверах — да, это тоже интересный момент, как и выставление timezone, например )

В общем, аккуратней нужно быть с SocketAppender'ом из коробки :)

[egor_masalitin]

Тут вы правы.
1. По поводу первого вопроса, я понял ситуацию, но не совсем понял вопрос, но если вы спрашиваете восстановится ли соединение после возобновления узла, то да, в моем случае оно возобновлялось.
2. Да, может и так, я использовал его не для просмотра GET/POST логов например, а для просмотра обычных INFO/ERROR/WARN логов кидаемых приложением. Однако есть еще такой момент, при деплое моего приложения, хибернейт кидает порядка 200-300 логов сразу, и даже учитывая это, время на деплой увеличивалось только на время необходимое для установления соединения с Logstash. Но возможно это нужно будет проверить на увеличенном объеме кидаемых логов, и тогда будет сильна видна разница.

[igor_suhorukov]

Проще не SocketAppender использовать, а парсить логи из файловой системы file input модуль. Но соответственно, нужно настроить regexp для извлечения именованных полей в json запись в elasticsearch. И вообще logstash в такой системе не обязателен, если требуется сохранять логи только своего приложения. Буду делать доклад про мониторинг большого in-memory data grid кластера с помощью ELK. Кто будет на конференции, с удовольствием поделюсь опытом. Чуть освобожусь, напишу здесь статью про Elasticsearch в более забавном применении

[egor_masalitin]

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

[igor_suhorukov]

Logstash можно запустить in-process в java программе с помощью jruby, если жалко отдельного процесса. Кроме того можно парсить логи из файловой системы любой своей программой почти на любом языке программирования без logstash. Отправлять через REST API в elasticsearch записи логов в нужном формате(такой же json, как формирует logstash). В этом случае logstash не нужен. Формат можете подсмотреть с помощью elasticHQ, в изучении записей может также помочь elasticsearch-head.

В случае своего парсера логов elasticsearch+kibana будет достаточно. Соответственно в парсере можно предусмотреть ожидание, если elasticsearch не доступен. Продолжить парсинг можно будет с того же места при восстановлении. В этом случае никаких больших буферов в памяти не нужно и сообщения не потеряются.

Если же требования к надежности хранения данных в ES параноидальные, то можно настроить количество реплик для каждой записи логов в индексе и дополнительно использовать механизм snapshot

[egor_masalitin]

Так то оно да, но это нарушает одно из моих условий:
«3. Простота в настройке и использовании»
Условия ставились таким образом, что на реализацию системы выделялось минимальное количество времени, и была необходима система, которую можно было бы быстрее, и проще развернуть. Она не является основной в моем случае, она лишь надстройка помогающая в поиске, а писать свою реализацию этого в моем случае было нецелесообразно.

[igor_suhorukov]

Согласен, отличный аргумент для выбора logstash!

[igor_suhorukov]

Network Time Protocol daemon может помочь. Обязательно надо помнить при парсинге дат из логов, что в logstash json записи время передается в timezone UTC.

[igor_suhorukov]

В kibana делать срезы по времени, log level можно с помощью фильтров которые можно сохранить в виде разных дашбордов в тот же инстанс Elasticsearch. В Elasticsearch отличный полнотекстовый поиск, но для. Надо только учитывать, что при поиске по регулярному выражению ищет не по всему полю из множества слов, а по тому что оказалось в индексе после токенизации, но и это можно обойти. Для нормального поиска по русскому тексту требуются небольшие танцы с бубном и настройками

[Ipeacocks]

Умеет ли это все работать с rsyslog или syslog-ng?

Было бы круто, если вы в начале статьи описали что есть что в этой схеме Logstash + ElastickSearch + Kibana 3 и какую роль выполняет каждый из них.

[egor_masalitin]

Умеет ли это все работать с rsyslog или syslog-ng?

Да, но для этого нужно отдельно конфигурировать, и лично я этого не пробовал.

Было бы круто, если вы в начале статьи описали что есть что в этой схеме Logstash + ElastickSearch + Kibana 3 и какую роль выполняет каждый из них.

Первоначально так и хотел сделать, но из за недостатка времени к сожалению не вышло. Я планирую оптимизировать эту систему, ускорить установку, упростить запуск и остановку. Тогда и постараюсь ответить на все ваши вопросы.

[igor_suhorukov]

Elasticsearch — распределенный поисковый движок, надстройка над apache lucene с автоматическим шардированием индексов, REST сервисами для поиска по индексам, обновления и администрирования хранилища индексов. Упрощенно можно рассматривать как NoSQL базу для хранения и индексирования данных в формате json. Отличный выбор если объем данных огромный, требуется полнотекстовый поиск и простое горизонтальное масштабирование хранилища.

Kibana3 — html5 фронтэнд для просмотра данных в elasticsearch, фильтрации и визуализации данных. Кроме ES для работы ему ничего больше не нужно, он взаимодействует c ES по REST.

Logstash — парсер/агрегатор логов. Есть input модули, в том числе и для syslog. DSL на ruby для конфигурирования, возможны выражения на ruby, if в конфигурации и т.п. Фильтры для извлечения и обработки информации из input модулей. codec для преобразования форматов данных и output для сохранения в какую либо систему для анализа. Elasticsearch отлично подходит в качестве output системы.

ELK высокоинтегрированный стек. Возможен запуск всех трех компонентов в одном java процессе. Logstash(через встроенный jruby), embedded Elasticsearch и получить браузером статику Kibana через веб сервер. Но возможно запускать ES и Logstash в разных процесах, с различной топологией кластера ES(различное количество процессов сервера на различных узлах с записью данных на разные диски, мультикаст или юникаст обнаружение узлов кластера)

[vba]

У вас вначале статьи написано ElastickSearch вместо ElasticSearch.

[egor_masalitin]

Спасибо, исправил

[Fisik]

Недостатком такой связки является отсутствие возможности выгрузить какую-то пачку логов в эксель/сsv/txt за 1 клик прямо из кибаны.

Соответственно приходится писать микро-приложение которое дернет API и сохранит результат в эксель =(

[vba]

Странно конечно, экспортировать логи в эксель, но должен вас огорчить, логстэш имеет плагин для экспорта в csv.

[igor_suhorukov]

Можно не писать такое приложение, так как elasticsearch-head имеет функцию выгрузки в CSV формат. На 27 слайде моей презентации про Elasticsearch/Logstash/Kibana есть скриншот как это делается

[igor_suhorukov]

Вот так

выгружать в csv

[basi1io]

Я вместо форка использовал nginx с basic_auth.
Можно проксировать запросы на любой порт, при этом есть авторизация.

[PontiyPilat]

kibana-authentication-proxy немного умер, авторы рекомендуют проксировать/авторизовывать другими средствами.

github.com/elasticsearch/kibana/issues/1628

Example for nginx:

Включаем ssl при подключении к elastic в кибана:
kibana/config.js:

— elasticsearch: «http://»+window.location.hostname+":9200",
+ elasticsearch: «https://»+window.location.hostname/,

example.org.conf for nginx:

server {
listen *:443 ssl;

server_name example.org

ssl on;
…

location / {
proxy_pass 127.0.0.1:9292;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/.*/_mapping {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/.*/_search$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/_aliases$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/_nodes$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/kibana-int/dashboard/.*$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/kibana-int/temp.*$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/.*/_aliases$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}