Perché ho bisogno di un broker per la mia produzione ELK stack + specifiche della macchina?

Question

Recentemente ho messo in piedi una casella Ubuntu di test stack ELK per testare la funzionalità e ne sono stato molto contento. Il mio caso d'uso per la produzione comporterebbe l'ingestione di almeno 100 GB di tronchi al giorno. Voglio essere il più scalabile possibile, in quanto questo 100GB/giorno può aumentare rapidamente dato che avevamo più sorgenti log.

Ho letto alcuni articoli sulla produzione ELK, incluso il fantastico Logz.io ELK Deployment. Mentre ho un'idea generale di cosa devo fare, non sono sicuro su alcuni concetti chiave, su quante macchine ho bisogno per una grande quantità di dati e se ho bisogno di un broker come Redis incluso nella mia architettura.

Qual è il punto di un broker come Redis? Nella mia istanza di test, ho più fonti di log che inviano i log su TCP, syslog e forwarder logstash al mio Logstash direttamente sul mio server ELK (che ha anche Elasticsearch, Nginx e Kibana installati configurati con SSL).

Al fine di mantenere una disponibilità elevata, un cluster di produzione all'avanguardia, quali macchine + specifiche ho bisogno per almeno 100 GB di dati al giorno, probabilmente in scala verso 150 GB o più in futuro? Sto pianificando di utilizzare i miei server. Da quello che ho cercato, il punto di partenza dovrebbe essere qualcosa del tipo (supponendo che includo Redis):

• 2/3 server con un'istanza Redis + Logstash (indicizzatore) per ogni server. Per le specifiche, sto pensando 32 GB di RAM, veloce I/O disco 500 GB forse SSD, 8 core (i7)
• 3 server per Elasticsearch (questo è quello di cui sono più insicuro) - So che ho bisogno di almeno 3 nodi master e 2 nodi dati, quindi 2 server avranno 1 master/1 dati ciascuno - questi saranno potenti 64 GB di RAM, 20 TB, 8 core. L'altro nodo master rimanente può trovarsi su una macchina con specifiche basse, in quanto non sta gestendo i dati.
• 2 server per Nginx/Kibana: si tratta di macchine con bassa specifica, in quanto sono solo il server Web e l'interfaccia utente. È necessario un bilanciamento del carico qui?

MODIFICA: Pianificazione della conservazione dei registri per 60 giorni.

Answer 1

Come per Redis, funge da buffer nel caso in cui logstash e/o elasticsearch siano inattivi o lenti. Se si utilizza l'intero logstash o logstash-forwarder come mittente, esso rileverà quando logstash non è disponibile e interromperà l'invio dei registri (ricordando da dove era stato interrotto, almeno per un po ').

Quindi, in un ambiente logstash/logstash-forwarder puro, vedo pochi motivi per utilizzare un broker come redis.

Quando diventa importante è per le fonti che non si preoccupano dello stato di logstash e non bufferizzano nella loro parte. syslog, snmraprap e altri rientrano in questa categoria. Dal momento che le tue fonti includono syslog, selezionerei i broker nel tuo setup.

Redis è un'app che richiede molta RAM e la quantità di memoria necessaria determinerà la durata di un'interruzione del logstash che è possibile sostenere. Su un server da 32 GB (condiviso con logstash), quanta memoria vorresti dare? Quanto è grande la dimensione media del documento? Quanti documenti ci vorrebbe per riempire la memoria? Quanto tempo ci vuole per generare tanti documenti? Nella mia esperienza, i redis falliscono orribilmente quando la memoria si riempie, ma quello poteva essere solo io.

Logstash è un processo che richiede molta CPU poiché tutti i filtri vengono eseguiti.

Per quanto riguarda le dimensioni del cluster elasticsearch, @magnus ha già indicato alcune informazioni che potrebbero essere d'aiuto. A partire da 64 GB, le macchine sono fantastiche e vengono ridimensionate orizzontalmente secondo necessità.

È necessario disporre di due nodi client (non dati) che vengono utilizzati come punto di accesso per gli inserti (invio efficiente delle richieste al nodo dati corretto) e ricerche (gestione della fase di 'riduzione' con i dati restituiti dai dati nodi). Due di questi in una configurazione di failover sarebbero un buon inizio.

Due macchine kibana ti daranno ridondanza. Metterli in una configurazione di failover è anche un bene. nginx era più usato con kibana3, credo. Non so se le persone lo stanno usando con kibana4 o si sono spostati a "scudo".

Spero che questo aiuti.