В настоящее время у меня есть архитектура с filebeat в качестве отправителя журналов, которая отправляет журналы в экземпляр индексатора хранилища журналов, а затем в управляемый эластичный поиск в AWS. Из-за постоянных TCP-соединений я не могу балансировать нагрузку с помощью экземпляров индексатора нескольких журналов AWS ELB, поскольку filebeats всегда выбирает экземпляры и отправляет их туда. Поэтому я решил использовать Redis. Теперь, видя, насколько сложно масштабировать redis и сделать его высокодоступным компонентом в стеке ELK, я хочу спросить, в чем вообще смысл redis. Я миллион раз читал, что он действует как буфер, но если filebeats перестает отправлять журналы в logstash, если logstash не может справиться с нагрузкой, зачем нам вообще буфер. Filebeat достаточно умен, чтобы остановить отправку журналов. Logstash достаточно умен, чтобы перестать отправлять журналы в эластичный поиск, если эластичный поиск не работает. Итак, трубопровод останавливается. Я действительно не понимаю, что redis действует как буфер в каждой стандартной архитектуре ELK.
В чем смысл REDIS в стеке ELK?
Ответы (1)
Redis, Kafka или XYZ можно использовать как буфер в стеке ELK, как вы правильно заметили.
Сотрудники ES опубликовали сообщение в блоге вчера об использовании Kafka в конвейере, но с тем же успехом это мог быть Redis или XYZ. Они хорошо замечают, КОГДА такой буфер может понадобиться, а когда нет.
Наличие такого буфера - хорошая идея, чтобы
- обрабатывать всплески событий
- иметь дело с потенциально недоступным ES-кластером
Если вы не ожидаете такого поведения, т.е. знаете,
- ваши мероприятия всегда будут проходить с одинаковой скоростью и / или
- вы согласны с тем, что ваши журналы будут отправлены немного позже, на случай, если вам понадобится обновить кластер ES
... тогда вам не нужен такой буфер. Более того, это будет одним программным обеспечением меньше, чем вам нужно управлять, отслеживать и поддерживать.
Когда дело доходит до экосистемы Elastic Stack, не существует универсального подхода, он всегда зависит от вашего конкретного варианта использования и требований. Вам нужно спросить себя, что важно для вас, вашей системы (систем) и ваших пользователей, а затем соответствующим образом разработать свое решение.
