Какое решение для регистрации сервера меньше потребляет процессор Kafka, Fluentd и Logstash?

У меня есть распределенная система ведения журнала для мониторинга балансированных по нагрузке объектов сервера. Крайне важно, чтобы сервер не инвестировал много процессорного времени в процесс ведения журнала, позволяя приложению работать с максимально возможным количеством ресурсов.Какое решение для регистрации сервера меньше потребляет процессор Kafka, Fluentd и Logstash?

Было бы хорошо, чтобы знать, какой из них является «дешевле» с точки зрения времени процессора или любое другое решение этого вопроса:

Кафки
Fluentd
Logstash

Спасибо.

источник

2016-03-29 Kruser

Почему вы исключили эластичный грузоотправитель, изготовленный из эластичного материала, filebeat? –

@Alain благодарит за это, я пропустил это в своих исследованиях. Я мог бы добавить это к вопросу, поскольку я думаю, что это могло бы быть полезно для ответа. Это действительно легкий вес? – Kruser

Прежде всего, Kafka не является сборщиком бревен. Это распределенная очередь сообщений и может работать с коллекторами журналов, такими как Fluentd и Logstash, как потребителями, так и производителями.

Вместо мнений, давайте поместим некоторые цифры.

Использование процессора. Это зависит от того, сколько фильтров и обработки данных вы делаете на стороне клиента, используя Fluentd и/или Logstash. Если вы выполняете минимальную обработку, оба могут обрабатывать 10 000 сообщений в секунду. Оба могут использовать преимущества нескольких процессоров (http://docs.fluentd.org/articles/in_multiprocess, например)
Память: Fluentd использует около 40 МБ памяти, а Logstash использует около 100 МБ памяти. Если это слишком много, у Logstash есть Beats и Fluentd как Fluentd Forwarders (https://github.com/fluent/fluentd-forwarder).

источник

2016-03-29 20:11:58

Большинство сборщиков журналов основаны на распределенных архитектурах сообщений, и, конечно же, они обрабатывают его путем управления очередями. Спасибо за вашу помощь, но это не то, что я ищу. – Kruser

@ Karlos No, большинство лог-сборщиков не основаны на архитектуре распределенных сообщений вообще. Ни один из Logstash, Fluentd, syslog-ng и syslog не распространяется. Они разворачиваются в распределенной среде, но это отличается от распространенного программного обеспечения. Кроме того, действительно важно, что вы получаете разницу между сбором журнала и проглатыванием журнала. –

-1

Все, что связано с fluentd и logstash, имеют стоимость процессора, лучше не запускать их на сервере приложений. Для, kafka, поскольку на вашем сервере работает только клиент, он должен быть дешевле, но тогда стабильность вашего сервера зависит от стабильности серверов kafka.

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

источник

2016-03-29 14:20:55

При всем уважении, Kafka не является сборщиком журналов. То, о чем вы говорите, - это библиотека производителей для Kafka, которая на самом деле не является программным обеспечением, а частью кода, которую пользователь должен писать. –

@ Kiyoto, Kafka не является традиционным сборщиком журналов, но многие люди, даже крупные компании, теперь используют его для сбора журналов, чтобы вы могли подписаться на kafka для синтаксического разбора очень гибким способом. –

Позвольте мне уточнить. Мое определение сборщика данных - это часть программного обеспечения, которая включает в себя логику получения и анализа данных журнала без внешней логики. Кафка НЕ делает этого.Для Kafka это работа производителей Kafka, и эту роль берут на себя различные программы, в том числе Logstash, Fluentd, Heka, syslog-ng и т. Д. Смешение Kafka с фактическими сборщиками данных - очень опасное мышление, поскольку сборщики данных и очереди сообщений имеют совершенно разные требования и эксплуатационные характеристики (например, у Kafka никогда не будет никакой функции, связанной с разбором). –

Возможно, вы должны использовать простой легкий rsyslog, syslog-ng или syslogd. Зависит от того, какие технологии вы хотели бы использовать?

источник

2016-03-29 15:29:17

Да, мой предыдущий подход к этому решению заключался в использовании syslogd. Причина, по которой я перестала ее использовать, - это, в основном, фильтрация и пересылка сообщений. Это была трудная проблема с конфигурацией для отправки правильно отфильтрованных сообщений или добавления тегов к ним на основе зарегистрированного сообщения. Использовали ли вы хорошую фильтрацию сообщений, например, в журнальных полях, используя любые легкие решения, которые вы упомянули? – Kruser

Конечно, я рекомендую 'rsyslog': http://www.rsyslog.com/doc/v8-stable/configuration/filters.html –

BTW Я бы не использовал грузоотправителя, написанного на Ruby :) На самом деле я бы не" t использовать грузоотправителя, который первоначально занимает более 20 МБ памяти. Как только вы начнете глотать данные, количество использованной ОЗУ будет зависеть от конфигурации буферизации вашей памяти (и файловой системы). –

Мы используем Flume для сбора журналов и отправки в Kafka - это очень мало для использования ЦП и по памяти - это зависит от вас, сколько буферизации вы хотите сделать. Вы также можете написать свой собственный перехватчик Flume, если вам нужен индивидуальный синтаксический анализ/маршрутизация данных.

источник

2016-03-30 15:47:08 Marina

Похоже, Марина, я посмотрю на нее, потому что теперь этот ответ и тот, что есть у @Marko, являются самыми многообещающими для меня. – Kruser

Какое решение для регистрации сервера меньше потребляет процессор Kafka, Fluentd и Logstash?

ответ

Смежные вопросы