Redis Vs RabbitMQ como um corretor de dados / sistema de mensagens entre Logstash e elasticsearch

Estamos definindo uma arquitetura para coletar informações de log por remetentes Logstash que são instalados em várias máquinas e indexar os dados em um servidor elasticsearch centralmente e usar Kibana como a camada gráfica. Precisamos de um sistema de mensagens confiável entre os remetentes Logstash e a elasticsearch para garantir a entrega. Quais fatores devem ser considerados ao selecionar o Redis em vez do RabbitMQ como um corretor de dados / sistema de mensagens entre os remetentes do Logstash e o elasticsearch ou vice-versa?

Depois de avaliar o Redis e o RabbitMQ, escolhi o RabbitMQ como nosso corretor pelos seguintes motivos:

1. O RabbitMQ permite que você use uma camada interna de segurança usando certificados SSL para criptografar os dados que você está enviando para o corretor e isso significa que ninguém vai farejar seus dados e ter acesso aos seus dados organizacionais vitais.
2. RabbitMQ é um produto muito estável que pode lidar com uma grande quantidade de eventos por segundo e muitas conexões sem ser o gargalo.
3. Na nossa organização já utilizávamos o RabbitMQ e tínhamos um bom conhecimento interno de utilização e uma integração já preparada com o chef.

Com relação ao escalonamento, o RabbitMQ possui uma implementação de cluster integrada que você pode usar além de um balanceador de carga para implementar um ambiente de broker redundante.

Meu cluster RabbitMQ é ativo ativo ou ativo passivo?

Agora, para o ponto mais fraco de usar RabbitMQ:

1. a maioria dos remetentes de Logstash não suporta RabbitMQ, mas por outro lado, o melhor, chamado Beaver, tem uma implementação que enviará dados para RabbitMQ sem problemas.
2. A implementação que o Beaver tem com o RabbitMQ em sua versão atual é um pouco lenta no desempenho (para meus propósitos) e não foi capaz de lidar com a taxa de 3000 eventos / s de um servidor e de vez em quando o serviço travava.
3. No momento, estou trabalhando em uma correção que resolverá o problema de desempenho do RabbitMQ e tornará o remetente do Beaver mais estável. A primeira solução é adicionar mais processos que podem ser executados simultaneamente e darão mais poder ao remetente. A segunda solução é mudar o Beaver para enviar dados ao RabbitMQ de forma assíncrona, o que teoricamente deveria ser muito mais rápido. Espero terminar de implementar as duas soluções até o final desta semana.

Você pode acompanhar o problema aqui: https://github.com/josegonzalez/python-beaver/issues/323

E verifique a solicitação de pull aqui: https://github.com/josegonzalez/python-beaver/pull/324

Se você tiver mais perguntas, fique à vontade para deixar um comentário.

O Redis é criado como um armazenamento de dados de valor-chave, apesar de ter alguns recursos básicos do agente de mensagens.

RabbitMQ é criado como um agente de mensagens. Ele tem muitos recursos de agente de mensagens naturalmente.

Eu tenho feito algumas pesquisas sobre este assunto. Se o desempenho é importante e a persistência não, o RabbitMQ é a escolha perfeita. Redis é uma tecnologia desenvolvida com um propósito diferente.

A seguir está uma lista de profissionais para usar RabbitMQ em vez de Redis:

• O RabbitMQ usa o Advanced Message Queuing Protocol (AMQP), que pode ser configurado para usar SSL, uma camada adicional de segurança.
• O RabbitMQ leva aproximadamente 75% do tempo que o Redis leva para aceitar mensagens.
• RabbitMQ oferece suporte a prioridades para mensagens, que podem ser usadas por trabalhadores para consumir mensagens de alta prioridade primeiro.
• Não há chance de perder a mensagem se algum trabalhador travar após consumir a mensagem, o que não é o caso do Redis.
• O RabbitMQ possui um bom sistema de roteamento para direcionar mensagens para diferentes filas.

Alguns contras para usar RabbitMQ:

• RabbitMQ pode ser um pouco difícil de manter, difícil de depurar travamentos.
• As flutuações no nome do nó ou no ip do nó podem causar perda de dados, mas, se bem gerenciadas, as mensagens duráveis ​​podem resolver o problema.

Eu estive me perguntando a mesma coisa. Recomendações anteriores do pessoal do Logstash recomendam Redis em vez do RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), no entanto, essa seção das notas não existe mais na documentação atual, embora haja notas genéricas sobre o uso de um corretor para lidar com picos aqui https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

Embora eu também esteja usando o RabbitMQ com bastante satisfação, estou explorando um corretor Redis, uma vez que o protocolo AMQP é provavelmente um exagero para o meu caso de uso de registro.

Perguntas rápidas para fazer:

1. por que você precisa de um corretor? Se você estiver usando logstash ou logstash-forwarder para ler arquivos desses servidores, ambos ficarão mais lentos se o pipeline ficar congestionado.
2. você tem alguma experiência com administração de coelho ou redis? Todas as coisas sendo iguais, a ferramenta que você sabe como usar é a melhor ferramenta.

No reino das opiniões, administrei o redis como corretor e odiei. Claro, pode ter sido minha inexperiência com redis (não é um problema com o produto em si), mas era o elo mais fraco do pipeline e sempre falhava quando mais precisávamos.