Что использовать для доставки журналов с сервера приложений: Logstash forwarder, FLume или Fluentd?

  1. Пересылка Logstash легкая, но от пересылки logstash до logstash есть задержка по сети. [если я использую пересылку Logstash на одном компьютере и отправляю журналы в Logstash, который находится на другом компьютере]

  2. Flume/Flume-ng: высокая загрузка ЦП для того же объема данных (например, для 2 МБ это около 20 процентов)

  3. Fluentd: не использует Java, он основан на CRuby, но его загрузка ЦП также составляет 30 процентов в пиковое время, .

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


logging apache fluentd logstash-forwarder flume-ng
person Sudarshan Kumar    schedule 10.09.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Интересная статистика производительности.

По моему опыту, logstash-forwarder довольно легкий, а шифрование/сжатие очень полезно. Это действительно может вызвать некоторую задержку. Для вас это важный фактор? Я предполагаю, что задержка меньше 2-3 секунд. Я думаю, что во многих случаях использования управления журналами работа в реальном времени не является строгим требованием.

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

Взгляните на rsyslog, который имеет много конфигураций того, как часто он копирует журналы. Вы можете запустить его в докере и более строго ограничить ресурсы rsyslog или любого другого агента (https://hub.docker.com/r/logzio/logzio-rsyslog-shipper/)

Другим вариантом может быть публикация журналов непосредственно с вашего сервера приложений с массовой публикацией HTTP путем написания собственного кода. Это то, что можно использовать с наиболее открытым исходным кодом, таким как ELK, и мы рекомендуем использовать его на http://logz.io.

person Tomer Levy    schedule 14.09.2015