ElasticSearch / Logstash / Kibana Как бороться с резкими скачками трафика журналов

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

Мы используем стандартную настройку ELK (ElasticSearch / Logstash / Kibana) в AWS для нужд ведения журналов наших веб-сайтов.

У нас есть группа автомасштабируемых экземпляров Logstash за балансировщиком нагрузки, которые регистрируются в группе автомасштабируемых экземпляров ElasticSearch за другим балансировщиком нагрузки. Затем у нас есть единственный экземпляр, обслуживающий Кибану.

Для повседневной работы мы используем 2 экземпляра Logstash и 2 экземпляра ElasticSearch.

Наш веб-сайт испытывает короткие периоды высокого уровня посещаемости во время мероприятий - наш трафик увеличивается примерно на 2000% во время этих мероприятий. Мы заранее знаем об этих происходящих событиях.

В настоящее время мы просто временно увеличиваем количество экземпляров ElasticSearch во время мероприятия. Однако у нас были проблемы, из-за которых мы впоследствии слишком быстро уменьшили масштаб, что означало, что мы потеряли сегменты и испортили наши индексы.

Я подумывал установить для параметра auto_expand_replicas значение "1-all", чтобы каждый узел имел копию всех данных, поэтому нам не нужно беспокоиться о том, как быстро мы увеличим или уменьшим масштаб. Насколько значительными будут накладные расходы на перенос всех данных на новые узлы? В настоящее время мы храним данные журнала только около 2 недель - всего получается около 50 ГБ.

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


logstash kibana
person bScutt    schedule 10.12.2014    source источник
comment
Какая-либо конкретная причина, по которой вы используете временное автомасштабирование ES? Количество узлов, которые вам нужны в кластере, в основном зависит от того, сколько данных вы хотите хранить и как вы запрашиваете данные, а не от скорости входящих сообщений.   -  person Magnus Bäck    schedule 10.12.2014
comment
У меня сложилось (возможно, наивное) впечатление, что, увеличив количество узлов в кластере ES, вы сможете увеличить количество обрабатываемых входящих сообщений.   -  person bScutt    schedule 10.12.2014
comment
Возможно, это правда, но вы сами обнаружили, что это не очень практично. Я думаю, что есть более эффективные способы борьбы с пиками, например наличие промежуточного буфера (например, брокера сообщений), из которого Logstash может извлекать сообщения. Это, очевидно, требует, чтобы у вас не было жестких требований к доступности сообщений журнала.   -  person Magnus Bäck    schedule 10.12.2014
comment
Я действительно подумал о каком-то буфере для Logstash, чтобы получать сообщения, однако возможность просматривать журналы во время этих событий в режиме реального времени чрезвычайно ценно для нас, поэтому я надеялся избежать этого, масштабируя ElasticSearch ...   -  person bScutt    schedule 10.12.2014
comment
Вы не описываете какие-либо доступные ресурсы (в частности, ОЗУ), какую-либо отладку или настройку, которые вы уже сделали, и т. Д. Вы можете перейти с 1 EPS до 20 EPS, насколько нам известно.   -  person Alain Collins    schedule 14.12.2014

Ответы (1)


arrow_upward
5
arrow_downward

Мой совет

Лучше всего использовать Redis в качестве брокера между Logstash и Elasticsearch:

Архитектурная схема предлагаемого решения

Это описано в некоторых старых документах Logstash, но все еще довольно красиво. соответствующие.

Да, вы увидите минимальную задержку между созданием журналов и их окончательной посадкой в ​​Elasticsearch, но она должна быть минимальной, поскольку задержка между Redis и Logstash относительно мала. По моему опыту, Logstash довольно быстро справляется с отставанием в Redis.

Такой тип настройки также дает вам более надежную настройку, при которой, даже если Logstash выходит из строя, вы все равно принимаете события через Redis.

Просто масштабируем Elasticsearch

Что касается вашего вопроса о том, помогут ли дополнительные узлы без данных в периоды интенсивной записи: я так не думаю, нет. Узлы без данных хороши, когда вы видите, что выполняется много поисков (чтений), поскольку они делегируют поиск всем узлам данных, а затем объединяют результаты перед отправкой их обратно клиенту. Они снимают нагрузку с агрегирования результатов с узлов данных.

Записи всегда будут включать ваши узлы данных.

Я не думаю, что добавление и удаление узлов - отличный способ решить эту проблему.

Вы можете попробовать настроить пулы потоков и очереди в ваши пиковые периоды. Допустим, обычно у вас есть следующее:

threadpool:
  index:
    type: fixed
    size: 30
    queue_size: 1000
  search
    type: fixed
    size: 30
    queue_size: 1000

Таким образом, у вас есть ровное количество доступных потоков поиска и индексации. Непосредственно перед пиковым временем вы можете изменить настройку (на ходу) на следующее:

threadpool:
  index:
    type: fixed
    size: 50
    queue_size: 2000
  search
    type: fixed
    size: 10
    queue_size: 500

Теперь у вас есть намного больше потоков, выполняющих индексацию, что обеспечивает более высокую пропускную способность индексации, в то время как поиск откладывается на второй план. Для хорошей меры я также увеличил queue_size, чтобы увеличить количество невыполненных работ. Однако это может работать не так, как ожидалось, поэтому рекомендуется поэкспериментировать и настроить.

person Jrgns    schedule 24.03.2015