Я использую серверную часть Spring Boot, чтобы предоставить некоторый restful API, и мне нужно регистрировать все мои журналы запросов и ответов в ElasticSearch.
Какой из следующих двух методов имеет лучшую производительность?
Использование Spring Boot ResponseBodyAdvice для регистрации каждого запроса и ответа, отправляемого клиенту непосредственно в ElasticSearch.
Записывать каждый запрос и ответ в файл журнала и с помощью filebeat и/или logstash отправлять их в ElasticSearch.
Во-первых, я предполагаю, что у вас есть распределенное приложение, в противном случае просто запишите свои данные в файл журнала и все
Я также предполагаю, что у вас достаточно журналов журналов для управления, в противном случае, если вы планируете регистрировать пару сообщений в час, то на самом деле не имеет значения, каким путем вы пойдете - оба подойдут задание.
Технически оба пути могут быть реализованы, хотя для первого пути я бы предложил другой подход, по крайней мере я делал нечто подобное ~ 5 лет назад в одном из своих проектов:
Создайте настраиваемый модуль добавления журнала, который помещает все в некоторую очередь (для асинхронной обработки), и из этого взял проект Apache Flume, который может записывать данные в БД по вашему выбору в виде транзакций с пакетной поддержкой, "все или- ничего" семантика и т.д.
Этот подход решает проблемы, которые могут появиться в представленном вами «первом» варианте, в то время как некоторые другие проблемы останутся нерешенными.
Если я сравню первый и второй варианты, которые вы представили, Я думаю вам лучше с filebeat/logstash или даже обоими писать в ES, вот почему:
Когда вы входите в совет - вы "съедаете" ресурсы вашей JVM - память, ЦП для поддержки пула соединений ES, пул потоков для ведения фактического журнала (в противном случае бизнес-поток может замедлиться из-за регистрации запросов к ЭС).
Кроме того, вы не сможете записывать "в пакетном режиме" в elasticsearch без пользовательского кода, и вместо этого вам придется создавать "вставку" для каждого сообщения журнала, что может оказаться бесполезным.
Еще один "технический нюанс" - что произойдет, если приложение по какой-то причине будет перезапущено, сможете ли вы написать все журналы до перезапуска, если в совете все будет записано?
Еще один вопрос - что произойдет, если вы захотите "повернуть" индексы в ES, а именно создать индекс с TTL и создавать новый индекс каждый день.
filebeat/logstash потенциально может решить все эти проблемы, однако может потребоваться более сложная настройка. Кроме того, у вас, очевидно, будет больше сервисов для развертывания и обслуживания:
Как помогает logstash/filebeat? Вылетело из головы:
Что касается последствий для производительности - это в основном зависит от того, что вы измеряете, как именно выглядит ваше приложение, какое у вас оборудование, поэтому я боюсь, что не смогу дать вам четкий ответ на этот вопрос - вы должны измерить в вашем конкретном случае и придумать способ, который работает для вас лучше.
мы используем оба решения. первый подход имеет меньшую сложность. мы выбираем второй подход, когда не хотим трогать код и имеем слишком много экземпляров приложения.
о производительности. с записью непосредственно в elasticsearch у вас будет лучшая производительность, потому что вы не занимаете дисковый ввод-вывод. но предположим, что когда соединение между вашим приложением и сервером elasticsearch разрывается. вы бы потеряли журнал после нескольких повторных попыток.
использование rsyslog и logstash более надежно для больших кластеров.
Не уверен, что можно ожидать четкого ответа на этот вопрос. Это действительно зависит от вашей инфраструктуры и используемого оборудования.
И вы подразумеваете под производительностью производительность вашего spring boot backend приложения или производительность с точки зрения того, сколько времени требуется, чтобы ваши журналы прибыли в ElasticSearch?
Я предполагаю первое.
При отправке журналов непосредственно на ElasticSearch вашим узким местом будет используемая сеть, а при регистрации запросов и ответов в файл журнала сначала вашим узким местом, вероятно, будет используемая harddisk и возможная максимальная I/O операция.
Обычно я бы сказал, что отправка журналов напрямую на ElasticSearch по сети должна быть более быстрым вариантом, когда вы работаете внутри своей компании/сети, потому что по сравнению с этим запись на диск всегда довольно медленная. Но если вы используете быстрый SSDs, эффектом можно пренебречь. И если вам нужно отправить свои сетевые пакеты в другое место/страну, это также может быстро измениться.
Итак:
Если у вас есть быстрое сетевое подключение к вашему ElasticSearch и HDDs/более медленному SSDs, производительность может быть выше при использовании сети.
Если ваш ElasticSearch находится не у вас и вы можете использовать быстрый SSD, запись журналов в файл может оказаться более быстрым вариантом.
Но, в конце концов, вам, возможно, придется опробовать оба подхода, реализовать несколько таймеров и проверить самостоятельно.