Где я должен обрабатывать события журнала для logstash? (Агент против сервера)

Это может быть очень общий вопрос типа «зависит от вашей среды», но я хотел бы узнать о передовой практике, основанной на вашем опыте работы с logstash и агрегацией журналов в целом.

Итак, я пытаюсь интегрировать logstash в нашу производственную среду, и у нас есть большое количество событий журнала (65 КБ в минуту), которые будут собираться в одном центральном месте. У меня есть 10 виртуальных машин, которые размещены на разных физических машинах, и все они будут отправлять соответствующие журналы на сервер logstash, который находится в другом физическом поле. Чтобы сделать некоторую аналитику и очистить, я добавляю еще несколько полей в каждое событие журнала (5 полей/событие). Вопрос в том, где я должен фильтровать и добавлять поля к событию? на агентах logstash, работающих на 10 виртуальных машинах, или на сервере, который каждую минуту будет собирать 650 тыс. сообщений?

Несмотря на то, что я выделил серверу достаточно памяти (32 ГБ) и он может обрабатывать все эти события, было бы «нормально» обрабатывать такое большое количество событий на сервере или мне следует обрабатывать их на стороне клиента с гораздо меньшим объемом памяти, но нести расходы на отправку этих событий по сети, что может привести к перегрузке сети.

Любая помощь и/или предложения/опыт приветствуются!


logging logstash kibana elasticsearch
person user3195649    schedule 29.10.2014    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Я всегда считал, что проще всего разместить Logstash в том же ящике, что и данные, которые он обрабатывает. Прямо там вы можете предварительно обработать и обработать данные, а затем отправить их в ElasticSearch для хранения и поиска.

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

person bradvido    schedule 29.10.2014

arrow_upward
1
arrow_downward

Лично я бы пошел по пути «сервера» и запустил одного агента на указанном сервере. 65 минут в минуту должно быть легко для мощного сервера. В основном две причины:

  1. Во-первых, если вам нужно изменить какие-либо правила обработки (шаблоны GROK, правила KV и т. д.), вам нужно будет сделать это только на этой одной машине, перезапустить процесс logstash и вуаля, готово.

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

В рабочей среде на всех серверах приложений работает Logstash-Forwarder для пересылки всех необработанных журналов в Сервер агента Logstash, который выполняет весь сбор и обработку журналов. Еще не было никаких проблем.

person Nick    schedule 30.10.2014

arrow_upward
1
arrow_downward

Есть два преимущества использования полного логсташа в качестве вашего грузоотправителя:

  • вы можете добавить небольшую нагрузку на каждую распределенную машину для обработки, вместо того, чтобы нуждаться в более мощной централизованной машине для обработки всей информации.
  • вы можете анализировать и ограничивать информацию, отправляемую на централизованный компьютер (игнорируя определенные записи журнала и т. д.), тем самым экономя пропускную способность сети.

Недостатки этого:

  • вы используете JVM на каждой машине!
  • вы должны распространять свою конфигурацию на каждую машину при внесении изменений.

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

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

10 000 событий в секунду — это достойная нагрузка для logstash и elasticsearch.

Удачи!

person Alain Collins    schedule 30.10.2014