Растущая длина Redis

Наш конвейер: VMware-Netflow -> Logstash -> Redis -> Logstash-indexer -> 3xElastic

Данные, которые я собрал:

  • Я заметил в кибане, что приходящие потоки были 1 час, затем 2, затем 3 и так далее.
  • Запуск «redis-clillen netflow» показывает очень большое число, которое медленно увеличивается.
  • Запуск 'redis-cli INFO показывает довольно постоянный ввод со скоростью 80 кбит/с и вывод со скоростью 1 кбит/с. Я думаю, что они должны быть примерно равны.
  • Загрузка процессора на всех узлах довольно незначительна.

Что я пробовал:

  • Я убедился, что logstash-indexer отправляет данные на все 3 эластичных узла.
  • Я запустил много дополнительных экземпляров logstash на индексаторах, теперь Redis показывает 40 клиентов.

Я не уверен, что еще попробовать.


elastic-stack redis logstash
person Matt Ruge    schedule 24.05.2016    source источник
comment
Вы проводили нагрузочные испытания отдельных компонентов? Например. сколько журналов может обрабатывать ваш индексатор в минуту. Сколько строк журнала вы получаете от грузоотправителя Logstash в минуту?   -  person Chro    schedule 26.05.2016
comment
По сути, это зависит от того, насколько быстро индексатор может обрабатывать журналы. По моему опыту, Redis сам по себе очень быстр, и обычно это связано с Logstash, что является проблемой.   -  person Chro    schedule 26.05.2016

Ответы (1)


arrow_upward
0
arrow_downward

TLDR: перезагрузил все три узла elasticsearch, и жизнь снова удалась.

Я непреднамеренно отключил elasticsearch в качестве вывода и отправил свои сетевые потоки в эфир. Размер очереди в Redis упал до 0 за считанные минуты. Как ни печально, это доказало, что это был elasticsearch, а не logstash или redis.

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

После перезагрузки все они согласовались правильно, и записи происходят как надо.

person Matt Ruge    schedule 27.05.2016