Архитектурные решения Logstash

Итак, у нас есть несколько серверов, работающих на Amazon Web Services EC2, и мы хотим настроить logstash/elasticsearch для распределенного ведения журналов.

Из того, что я читал, обычно выбирают несколько вариантов:

  1. logstash на каждом узле сервера, используя входной фильтр File и переходя непосредственно к кластеру ElasticSearch в качестве выходного фильтра.
  2. logstash на каждом узле сервера, используя пересылку logstash, подключаясь к logstash в кластере ElasticSearch, который перенаправляет его в ElasticSearch в качестве выходного фильтра.
  3. logstash на каждом узле сервера, используя фильтр ввода файлов и используя Redis в качестве очереди. Затем logstash на каждом узле ElasticSearch, который получает от Redis и передает ElasticSearch.

Есть также варианты с использованием AsyncAppender (у которого не очень хорошая репутация).

У меня возникает соблазн выбрать № 1, особенно потому, что мы используем шаблон Layout, который автоматически преобразуется в JSON. Таким образом, мы сохраним дополнительные файлы с JSON на каждом узле сервера и отправим входной файл непосредственно в ElasticSearch.

Каковы негативы этого? Почему часто рекомендуется очередь/брокер?


amazon-ec2 logstash logstash-forwarder elasticsearch
person MJB    schedule 13.02.2015    source источник
comment
Кажется, что фильтр ввода файлов сам по себе не так надежен, когда не может подключиться к elasticsearch? Является ли это основной причиной очереди?   -  person MJB    schedule 13.02.2015
comment
Мы выбрали вариант №2. Мне не нравится идея запуска JVM на всех наших серверах с одной стороны. Работал хорошо для нас. Хорошо, если ваши фильтры определены только один раз.   -  person ficuscr    schedule 13.02.2015
comment
Достаточно справедливо, но, поскольку все наши серверы приложений в любом случае являются java, для нас это не проблема;)   -  person MJB    schedule 13.02.2015

Ответы (1)


arrow_upward
0
arrow_downward

Вот некоторые проблемы с вашими сценариями:

1: Должна быть установлена ​​JVM на каждой машине, с соответствующим объемом памяти и проблемами с обслуживанием. Поскольку они пишут прямо в elasticsearch, ваши фильтры должны быть распределены по каждой машине.

3: По-прежнему эта JVM на каждом сервере, плюс дополнительный шаг Redis.

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

Обратите внимание, что logstash и logstash-forwarder отключаются, когда logstash занят, поэтому вам не нужен брокер, такой как redis, в этой среде (при условии, что вы можете запустить logstash до смены файлов журнала).

Если можете, запустите logstash-forwarder на серверах, отправив их вывод на централизованный сервер logstash, а затем на elasticsearch. Это в основном ваш вариант № 2.

person Alain Collins    schedule 21.02.2015