Comments 18
У меня например, в logstash ещё стоит плагин для работы с jabber и когда разработчики выпускают новый релиз — logstash кидает сообщение в отдельную комнату чата (чтобы не спамить в основных) что за приложение и какой версии сейчас задеплоилось и с какой ошибкой, если не успешно.
Плюс критичные секции мониторинга так же логгируются в отдельный pipeline и тот же плагин кидает сообщения из этого порта уже в общий чат.
Но на самом деле там очень много настроек и комбинаций использования, поэтому адаптировать можно под разные задачи.
В гугл не пошлю, т.к. сам там провёл достаточно много времени. Не на все вопросы смог найти ответы. Поэтому и статью решил написать.
Не обещаю быстро, но скорее всего напишу ещё.
Чем оно может быть полезным. Как его использовать на практике.
Использую:
— для сбора логов с nginx+lua — в интересных местах добавлен вывод тела ответа сервера и заголовков запроса.
— с приложений на питоне и свой формат логов — интересующие поля + метрики.
— с различных сетевых устройств — syslog с обработкой.
ELK даёт возможность поиска, визуализации, статистики, триггеры по каким-то параметрам с оповещением. В общем, удобно.
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 под большие нагрузки ни разу не дешевый, теперь уж точно.
Но конкретно в вашем случае вы его неправильно готовили, видимо.
Разделение по типам нод у меня было, не помогло.
Про 30Гб я знал, java запускалась с соответствующими параметрами, так что здесь проблем не было.
Главным образом меня интересовало насколько елк масштабируется горизонтально и исходя из результатов моего эксперимента ответ был — после определенной нагрузки масштабирование не возможно.
Повторюсь, это было 3 года назад, с тех пор елк вполне мог улучшиться.
NickyX3 iops является одним из основных показателей при работе с ёлкой, поскольку при проседании оных кластер деградирует и разваливается. Но в таких случаях, конечно же, без графиков утилизации нагрузки по времени определить тонкие места нельзя, поэтому я и предположил, что проблемы были в настройках ёлки и привёл ссылку на breaking changes для седьмой версии, как раз таки касательно лимитов на шарды и перформанс ;-}
У меня вон логи nginx'а летят, и только только те, которые в php-back уходят (в логах добавлено время ответа back), но там нагрузки не сильно много, 300-600к реквестов в сутки, с этим прекрасно справляется одна нода ELK в виртуалке с 4Gb RAM. Данные хранятся за месяц. Logstash на этой же машине, а вот логи в него шлются с фронтов fllebeat'ом.
А если выкинуть logstash, написав свой json формат логов для nginx, и шипать их через filebeat сразу в elastic, то производительность будет ещё выше.
geoip есть и как в модуль nginx, и как часть elasticsearch geoip-processor. Зачем вам тормозной logstash?
А парсить логи, если у вас соблюдается формат полей — не надо.
json.keys_under_root: trueВ конфиге filebeat и всё.
Практическое применение ELK. Настраиваем logstash