прямое ведение журнала в elasticsearch по сравнению с использованием logstash и filebeat

avatar
Arvin Rokni
9 августа 2021 в 06:34
359
3
0

Я использую серверную часть Spring Boot, чтобы предоставить некоторый restful API, и мне нужно регистрировать все мои журналы запросов и ответов в ElasticSearch.

Какой из следующих двух методов имеет лучшую производительность?

  1. Использование Spring Boot ResponseBodyAdvice для регистрации каждого запроса и ответа, отправляемого клиенту непосредственно в ElasticSearch.

  2. Записывать каждый запрос и ответ в файл журнала и с помощью filebeat и/или logstash отправлять их в ElasticSearch.

Источник

Ответы (3)

avatar
Mark Bramnik
9 августа 2021 в 07:03
2

Во-первых, я предполагаю, что у вас есть распределенное приложение, в противном случае просто запишите свои данные в файл журнала и все

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

Технически оба пути могут быть реализованы, хотя для первого пути я бы предложил другой подход, по крайней мере я делал нечто подобное ~ 5 лет назад в одном из своих проектов:

Создайте настраиваемый модуль добавления журнала, который помещает все в некоторую очередь (для асинхронной обработки), и из этого взял проект Apache Flume, который может записывать данные в БД по вашему выбору в виде транзакций с пакетной поддержкой, "все или- ничего" семантика и т.д.

Этот подход решает проблемы, которые могут появиться в представленном вами «первом» варианте, в то время как некоторые другие проблемы останутся нерешенными.

Если я сравню первый и второй варианты, которые вы представили, Я думаю вам лучше с filebeat/logstash или даже обоими писать в ES, вот почему:

Когда вы входите в совет - вы "съедаете" ресурсы вашей JVM - память, ЦП для поддержки пула соединений ES, пул потоков для ведения фактического журнала (в противном случае бизнес-поток может замедлиться из-за регистрации запросов к ЭС).

Кроме того, вы не сможете записывать "в пакетном режиме" в elasticsearch без пользовательского кода, и вместо этого вам придется создавать "вставку" для каждого сообщения журнала, что может оказаться бесполезным.

Еще один "технический нюанс" - что произойдет, если приложение по какой-то причине будет перезапущено, сможете ли вы написать все журналы до перезапуска, если в совете все будет записано?

Еще один вопрос - что произойдет, если вы захотите "повернуть" индексы в ES, а именно создать индекс с TTL и создавать новый индекс каждый день.

filebeat/logstash потенциально может решить все эти проблемы, однако может потребоваться более сложная настройка. Кроме того, у вас, очевидно, будет больше сервисов для развертывания и обслуживания:

  • logstash намного тяжелее, чем filebeat, с точки зрения потребления ресурсов, и обычно вы должны анализировать сообщение журнала (обычно с фильтром grok) в logstash.
  • filebeat гораздо более «скромнее», когда речь заходит о потреблении ресурсов, и если у вас есть много экземпляров для ведения журнала (действительно распределенное ведение журнала, которое, как я полагаю, у вас все равно есть), подумайте о том, чтобы установить службу filebeat (deamon set если у вас есть k8s) на каждом узле, с которого вы будете собирать логи, чтобы один процесс filebeat мог обрабатывать разные экземпляры, а затем развернуть кластер экземпляров logstash на отдельной машине, чтобы они делали тяжелый лог -все время перемалывать и стримить данные на ES.

Как помогает logstash/filebeat? Вылетело из головы:

  • Он будет работать в своем собственном темпе, поэтому даже если процесс выйдет из строя, сообщения, созданные этим процессом, все равно будут записаны в ES
  • Он даже может пережить короткие отключения самой ES, я думаю (следует проверить)
  • Он может обрабатывать разные процессы, написанные на разных технологиях, что, если завтра вы захотите собрать логи с сервера базы данных, например, на котором нет spring/не написанной java вообще
  • Он может обрабатывать ротацию индексов, внутреннюю пакетную запись, поэтому вы получите эффективное управление ES, которое в противном случае вам пришлось бы писать самостоятельно. Каковы недостатки подхода logstash/filebeat? Опять вылетело из головы, не полный список что ли:
  • Ну, через сеть будет проходить гораздо больше данных в целом
  • Если вы используете "LogEvent", вам не нужно анализировать строку, поэтому это преобразование является избыточным.

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

avatar
hamid bayat
9 августа 2021 в 06:52
1

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

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

использование rsyslog и logstash более надежно для больших кластеров.

avatar
spcial
9 августа 2021 в 06:49
2

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

И вы подразумеваете под производительностью производительность вашего spring boot backend приложения или производительность с точки зрения того, сколько времени требуется, чтобы ваши журналы прибыли в ElasticSearch?

Я предполагаю первое.

При отправке журналов непосредственно на ElasticSearch вашим узким местом будет используемая сеть, а при регистрации запросов и ответов в файл журнала сначала вашим узким местом, вероятно, будет используемая harddisk и возможная максимальная I/O операция.

Обычно я бы сказал, что отправка журналов напрямую на ElasticSearch по сети должна быть более быстрым вариантом, когда вы работаете внутри своей компании/сети, потому что по сравнению с этим запись на диск всегда довольно медленная. Но если вы используете быстрый SSDs, эффектом можно пренебречь. И если вам нужно отправить свои сетевые пакеты в другое место/страну, это также может быстро измениться.

Итак:

Если у вас есть быстрое сетевое подключение к вашему ElasticSearch и HDDs/более медленному SSDs, производительность может быть выше при использовании сети.

Если ваш ElasticSearch находится не у вас и вы можете использовать быстрый SSD, запись журналов в файл может оказаться более быстрым вариантом.

Но, в конце концов, вам, возможно, придется опробовать оба подхода, реализовать несколько таймеров и проверить самостоятельно.