Наилучший подход к отправке централизованного выхода журнала Scribe в elasticsearch

Question

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

Центральный сервер писца в настоящее время регистрирует все агрегированные журналы на диске. Но теперь мы хотим проиндексировать их на ElasticSearch для визуализации.

Мой точный вопрос: какой лучший (самый надежный, отказоустойчивый, менее вычислительно дорогой & объем памяти эффективный) способ пересылки журналов с выхода центрального сервера писца в ElasticSearch для индексирования?

Несколько идей стоит изучить:

1. Scribe Сервер -> Файл -> Logstash -> ElasticSearch
2. Scribe Сервер -> Файл -> [X] -> RabbitMQ -> Logstash -> ElasticSearch
3. Scribe Сервер -> Файл -> [Y] -> ElasticSearch
4. Scriber Сервер -> [Z] -> Упругие Поиск

Любые хорошие варианты X, Y или Z? Какой из них лучше всего подходит? Пожалуйста, предложите.

Спасибо.

Answer 1

Согласно мне вариант Z - лучший подход. ElasticSearch подходит для отказоустойчивой системы. Для этого механизма существует определение осколков и реплик. Но вы должны учитывать эффективность памяти. Количество вашего проиндексированного документа будет увеличено к тому времени, и для него потребуется как минимум в 2 раза больше места для хранения, так как в файле конфигурации по умолчанию есть только один осколок и одно определение реплики.

EDIT:
Если у вас уже есть центральный сервер писца, я предполагаю, что у вас есть все сообщения журнала на вашем центральном сервере. Но все варианты могут быть использованы для вашего приложения, если у вас нет структуры обмена сообщениями для вашего центрального сервера. Если вы хотите добиться асинхронности индексирования, вы можете использовать RabbitMQ или Apache solition. Я думаю, вы можете взглянуть на эластичный поиск performance considerations для индексирования. Каков ваш индекс в секунду? Это жизненно важно для вашего приложения? Мое другое предложение - MongoDB. Если вы не настаиваете на ElasticSearch, я могу предложить вам найти по телефону MongoDB. Вы должны это проверить comparison.