Redis Vs RabbitMQ come broker di dati / sistema di messaggistica tra Logstash ed elasticsearch

Stiamo definendo un'architettura per raccogliere le informazioni di registro dagli spedizionieri Logstash che sono installati su varie macchine e indicizzare i dati in un server elasticsearch centralmente e utilizzare Kibana come livello grafico. Abbiamo bisogno di un sistema di messaggistica affidabile tra gli spedizionieri Logstash e elasticsearch per garantire la consegna. Quali fattori dovrebbero essere considerati quando si seleziona Redis su RabbitMQ come un broker di dati / sistema di messaggistica tra i caricatori Logstash e elasticsearch o viceversa?

Dopo aver valutato sia Redis che RabbitMQ ho scelto RabbitMQ come nostro broker per i seguenti motivi:

1. RabbitMQ ti consente di utilizzare un livello di sicurezza integrato utilizzando certificati SSL per crittografare i dati che stai inviando al broker e significa che nessuno annuserà i tuoi dati e avrà accesso ai tuoi dati organizzativi vitali.
2. RabbitMQ è un prodotto molto stabile in grado di gestire grandi quantità di eventi al secondo e molte connessioni senza essere il collo di bottiglia.
3. Nella nostra organizzazione abbiamo già utilizzato RabbitMQ e avevamo una buona conoscenza interna sull'uso e un'integrazione già preparata con lo chef.

Per quanto riguarda il ridimensionamento, RabbitMQ ha un'implementazione del cluster incorporata che è possibile utilizzare in aggiunta a un bilanciatore del carico per implementare un ambiente broker ridondante.

Il mio cluster RabbitMQ è attivo attivo o attivo passivo?

Ora al punto più debole dell'utilizzo di RabbitMQ:

1. la maggior parte dei caricatori Logstash non supporta RabbitMQ ma, d'altra parte, il migliore, denominato Beaver, ha un'implementazione che invierà i dati a RabbitMQ senza problemi.
2. L'implementazione che Beaver ha con RabbitMQ nella sua versione attuale è un po 'lenta sulle prestazioni (per i miei scopi) e non è stata in grado di gestire la velocità di 3000 eventi / sec da un server e di tanto in tanto il servizio si è bloccato.
3. In questo momento sto lavorando a una soluzione che risolverà il problema delle prestazioni di RabbitMQ e renderà più stabile lo spedizioniere Beaver. La prima soluzione è aggiungere più processi che possono essere eseguiti contemporaneamente e daranno più potere al mittente. La seconda soluzione è cambiare Beaver per inviare i dati a RabbitMQ in modo asincrono, che in teoria dovrebbe essere molto più veloce. Spero di completare l'implementazione di entrambe le soluzioni entro la fine di questa settimana.

Puoi seguire il problema qui: https://github.com/josegonzalez/python-beaver/issues/323

E controlla la richiesta di pull qui: https://github.com/josegonzalez/python-beaver/pull/324

Se hai altre domande, non esitare a lasciare un commento.

Redis viene creato come archivio dati di valori chiave nonostante alcune funzionalità di base del broker di messaggi.

RabbitMQ viene creato come broker di messaggi. Ha molte funzionalità di broker di messaggi naturalmente.

Ho fatto delle ricerche su questo argomento. Se le prestazioni sono importanti e la persistenza no, RabbitMQ è una scelta perfetta. Redis è una tecnologia sviluppata con un intento diverso.

Di seguito è riportato un elenco di vantaggi per l'utilizzo di RabbitMQ su Redis:

• RabbitMQ utilizza il protocollo AMQP (Advanced Message Queuing Protocol) che può essere configurato per utilizzare SSL, ulteriore livello di sicurezza.
• RabbitMQ impiega circa il 75% del tempo che Redis impiega ad accettare i messaggi.
• RabbitMQ supporta le priorità per i messaggi, che possono essere utilizzate dai lavoratori per consumare prima i messaggi ad alta priorità.
• Non c'è possibilità di perdere il messaggio se un lavoratore si arresta in modo anomalo dopo aver consumato il messaggio, il che non è il caso di Redis.
• RabbitMQ ha un buon sistema di instradamento per indirizzare i messaggi a code diverse.

Alcuni svantaggi per l'utilizzo di RabbitMQ:

• RabbitMQ potrebbe essere un po 'difficile da mantenere, difficile da eseguire il debug dei crash.
• Le fluttuazioni del nome del nodo o dell'ip del nodo possono causare la perdita di dati, ma se gestiti correttamente, i messaggi durevoli possono risolvere il problema.

Mi sono chiesto la stessa cosa. I consigli precedenti della gente di Logstash raccomandano Redis su RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), tuttavia quella sezione delle note non esiste più nella documentazione corrente sebbene ci siano note generiche sull'utilizzo di un broker per gestire i picchi qui https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

Anche se sto usando anche RabbitMQ abbastanza felicemente, sto attualmente esplorando un broker Redis, poiché il protocollo AMQP è probabilmente eccessivo per il mio caso d'uso di registrazione.

Domande veloci da porre:

1. perché hai bisogno di un broker? Se stai utilizzando logstash o logstash-forwarder per leggere i file da questi server, entrambi rallenteranno se la pipeline si congestiona.
2. hai qualche esperienza con la somministrazione di rabbit o redis? A parità di condizioni, lo strumento che sai usare è lo strumento migliore.

Nel regno delle opinioni, ho gestito Redis come broker e l'ho odiato. Certo, quella potrebbe essere stata la mia inesperienza con redis (non un problema con il prodotto stesso), ma era l'anello più debole in cantiere e falliva sempre quando ne avevamo più bisogno.