Мне интересно, каковы плюсы и минусы использования Redis в качестве брокера в инфраструктуре?
На данный момент все мои агенты отправляют на центральный сервер NXLog, который проксирует запросы в logstash --> ES.
Что я получу, используя сервер Redis между сборщиком nxlog и logstash? Мне это кажется бессмысленным, поскольку nxlog уже имеет хорошие буферы памяти и диска на случай, если logstash не работает.
Что бы я выиграл?
Спасибо
При большой нагрузке: вызов ES (HTTP) напрямую может быть опасным, и у вас могут возникнуть проблемы, если ES сломается.
Redis может обрабатывать больше (намного больше) Написать запрос и отправить его в асинхронной логике в ES (HTTP).
Я начал использовать Redis, потому что чувствовал, что он разделит ввод и часть фильтра. По крайней мере, в те периоды, когда я часто меняю конфигурацию.
Как вы знаете, если вы измените конфигурацию logstash, вам придется перезапустить его. Все клиенты (в моем случае через syslog) обречены переподключаться к демону logstash, когда он снова в деле.
Поместив перед собой индексатор, который содержит относительно статическую конфигурацию ввода, и отправив все на повторную обработку, я могу перезапустить logstash, не вызывая сбоев в работе центра обработки данных. Я столкнулся с некоторыми проблемами, потому что наши разработчики не нашли времени (пока), чтобы уменьшить количество бесполезных журналов, отправляемых в системный журнал, что привело к переполнению сервера. До того, как у нас появился logstash, они переполняли дисковое пространство для журналов - хотя более общая проблема... :)
При использовании с Logstash Redis действует как очередь сообщений. У вас может быть несколько авторов и несколько читателей.
Использование Redis (или любой другой службы очередей) позволяет масштабировать Logstash горизонтально, добавляя дополнительные серверы в «кластер». Это не имеет значения для небольших операций, но может быть чрезвычайно полезным для более крупных установок.
При использовании Logstash с Redis вы можете настроить Redis так, чтобы в памяти сохранялись только все записи журнала, которым требуется очередь в памяти (например, memcache).
Вы можете прийти к моменту, когда количество отправленных журналов не будет обрабатываться Logstash, и это может привести к остановке вашей системы на постоянной основе (наблюдается в нашей среде).
Если вы считаете, что Redis создает дополнительную нагрузку на ваш диск, вы можете настроить его так, чтобы все журналы хранились в памяти до тех пор, пока они не будут обработаны logstash.
Когда мы построили нашу инфраструктуру ELK, у нас изначально было много проблем с индексатором logstash (чтение из Redis). Redis сделает резервную копию и в конце концов умрет. Я полагаю, это произошло потому, что в надежде не потерять файлы журналов Redis был настроен на сохранение кеша на диск время от времени. Когда очередь становилась «слишком большой» (но все еще в пределах доступного места на диске), Redis умирал, унося с собой все кэшированные записи.
Если это лучшее, что может сделать Redis, я бы не рекомендовал его.
К счастью, нам удалось решить проблемы с индексатором, который обычно оставлял очередь Redis пустой. Мы настроили наш мониторинг на быстрое оповещение, когда очередь действительно резервируется, и это был хороший признак того, что индексатор снова не доволен.
Надеюсь, это поможет.
