Pull to refresh

Comments 18

UFO just landed and posted this here
Ну банально же — логи. Сбор, сортировка, отправка в ElasticSearch, где их можно смотреть Кибаной.

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

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

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

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 под большие нагрузки ни разу не дешевый, теперь уж точно.
Но конкретно в вашем случае вы его неправильно готовили, видимо.

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

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

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

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

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

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

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

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

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

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


json.keys_under_root: true

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

Нам не достаточно maxmind базы, она недостаточно полная и точная, у нас своя через API, geoip-processor через ingest в какой-то из старых версий то ли криво работал, то ли что, в общем мутатор на централизованном LS нам понравился больше
Пишем и затем анализируем по необходимости «event trace for windows» полный трейс запросов до IIS. Такое количество выдерживает elasticsearch без препарса, если писать сразу в пул мастеров.
Sign up to leave a comment.

Articles