System administration
*nix
Comments 18
+1
Я вам искренне благодарен за статью.
Меня уже здесь пинали ногами по разным частям тела, но рискну еще раз на амбразуру. Вы рассказываете __как запустить эту штуковину__, но ни слова о том, __какие задачи__ можно ей решить. Про ELK слышали все, наверное. Что есть оно такое ELK. Но вот как его есть. Чем оно может быть полезным. Как его использовать на практике.
Вероятнее всего, вы меня пошлете куда-нибудь в гугл. Но может быть, дополнение или еще одна статья, объясняющая как это употреблять сделает вас супергероями. А меня в очередной раз не запинают :)
0
Ну банально же — логи. Сбор, сортировка, отправка в ElasticSearch, где их можно смотреть Кибаной.

У меня например, в logstash ещё стоит плагин для работы с jabber и когда разработчики выпускают новый релиз — logstash кидает сообщение в отдельную комнату чата (чтобы не спамить в основных) что за приложение и какой версии сейчас задеплоилось и с какой ошибкой, если не успешно.

Плюс критичные секции мониторинга так же логгируются в отдельный pipeline и тот же плагин кидает сообщения из этого порта уже в общий чат.
0
По сути, да, как сказал Oz_Alex, основное это обработка логов и подготовка их для просмотра в Кибане.
Но на самом деле там очень много настроек и комбинаций использования, поэтому адаптировать можно под разные задачи.
В гугл не пошлю, т.к. сам там провёл достаточно много времени. Не на все вопросы смог найти ответы. Поэтому и статью решил написать.
Не обещаю быстро, но скорее всего напишу ещё.
0
Чем оно может быть полезным. Как его использовать на практике.

Использую:
— для сбора логов с nginx+lua — в интересных местах добавлен вывод тела ответа сервера и заголовков запроса.
— с приложений на питоне и свой формат логов — интересующие поля + метрики.
— с различных сетевых устройств — syslog с обработкой.
ELK даёт возможность поиска, визуализации, статистики, триггеры по каким-то параметрам с оповещением. В общем, удобно.
+1
Скажите, пожалуйста, какой объем логов вы обрабатываете? Я пытался около 3-х лет назад использовать ELK для обработки 7тб логов в сутки и мне не удалось сконфигурировать кластер, который бы это потянул: habr.com/ru/post/282866/#comment_8881108
0
Нет, такого объёма у нас нет на данный момент. Сейчас около 10 Гб в сутки.
0
Да, и спасибо за ссылку. Я не видел этой статьи и обсуждения. Прочитал с интересом.
0

kt97679 заливка 7Тб данных в день даёт порядка 81 мб/сек на запись. Даже обычные HDD дают такой перформанс, не говоря уже о SAS 15k rpm или использовании bcache.
Ёлка же хорошо работает под нагрузкой, когда у нее храние и сериализация данных резделены. Соответственно, нужно разделять ingest и data nodes. Мастер-ноды тоже отдельно.


Использование более 30 Gb RAM per node не является эффективным из-за особенностей JVM.


A node with a 30GB heap should therefore have a maximum of 600 shards, but the further below this limit you can keep it the better.

Но в Elastic 7.0 это вообще переработали: https://www.elastic.co/guide/en/elasticsearch/reference/7.0/misc-cluster.html#cluster-shard-limit


В общем… elastic под большие нагрузки ни разу не дешевый, теперь уж точно.
Но конкретно в вашем случае вы его неправильно готовили, видимо.

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

Разделение по типам нод у меня было, не помогло.

Про 30Гб я знал, java запускалась с соответствующими параметрами, так что здесь проблем не было.

Главным образом меня интересовало насколько елк масштабируется горизонтально и исходя из результатов моего эксперимента ответ был — после определенной нагрузки масштабирование не возможно.

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

NickyX3 iops является одним из основных показателей при работе с ёлкой, поскольку при проседании оных кластер деградирует и разваливается. Но в таких случаях, конечно же, без графиков утилизации нагрузки по времени определить тонкие места нельзя, поэтому я и предположил, что проблемы были в настройках ёлки и привёл ссылку на breaking changes для седьмой версии, как раз таки касательно лимитов на шарды и перформанс ;-}

0
Мне вот тоже интересно… 80к индексов и logstash лежит.
0
ээээ, зачем вас столько индексов? Мне просто стало интересно что за задача такая?
У меня вон логи nginx'а летят, и только только те, которые в php-back уходят (в логах добавлено время ответа back), но там нагрузки не сильно много, 300-600к реквестов в сутки, с этим прекрасно справляется одна нода ELK в виртуалке с 4Gb RAM. Данные хранятся за месяц. Logstash на этой же машине, а вот логи в него шлются с фронтов fllebeat'ом.
0

А если выкинуть logstash, написав свой json формат логов для nginx, и шипать их через filebeat сразу в elastic, то производительность будет ещё выше.

0
В Filebeat не очень удачный парсинг, в LS есть мутаторы и плагины к примеру для разбора UserAgent и RemoteIP->Geo в объекты
0

geoip есть и как в модуль nginx, и как часть elasticsearch geoip-processor. Зачем вам тормозной logstash?
А парсить логи, если у вас соблюдается формат полей — не надо.


json.keys_under_root: true

В конфиге filebeat и всё.

0
Нам не достаточно maxmind базы, она недостаточно полная и точная, у нас своя через API, geoip-processor через ingest в какой-то из старых версий то ли криво работал, то ли что, в общем мутатор на централизованном LS нам понравился больше
0
Пишем и затем анализируем по необходимости «event trace for windows» полный трейс запросов до IIS. Такое количество выдерживает elasticsearch без препарса, если писать сразу в пул мастеров.
Only those users with full accounts are able to leave comments., please.