Buona installazione su AWS per ELK

Question

Stiamo cercando di ottenere una configurazione di stack ELK su Amazon ma non sappiamo veramente cosa abbiamo bisogno delle macchine per gestirlo senza problemi. Ora so che diventerà ovvio se non andrà liscio, ma speravamo ancora di avere un'idea di cosa avremmo avuto bisogno per la nostra situazione.

Quindi abbiamo 4 server che generano file di registro in un formato personalizzato. Circa ~ 45 milioni di righe di log ogni giorno, generando circa 4 file di 600mb (gzip), quindi circa ~ 24 GB di registri ogni giorno.

Ora stiamo esaminando lo stack ELK e vorremmo che i dashboard di Kibana mostrassero i dati in tempo reale, quindi stavo pensando di loggare usando syslog su logstash.

4 Server -> rsyslog (su quei 4 server) -> Logstash (AWS) -> elasticsearch (AWS) -> Kibana (AWS)

Così ora abbiamo bisogno di capire che tipo di hardware che sarebbe è necessario in AWS gestirlo.

Ho letto da qualche parte 3 master per ElasticSearch e 2 datanodi al minimo. Quindi questo sarebbe totale di 5 server + 1 server per Kibana e 1 per Logstash? Quindi avrei bisogno di un totale di 7 server per iniziare, ma questo sembra eccessivo. Vorrei conservare i miei dati per 1 mese, quindi 31 giorni al massimo, quindi avrei circa ~ 1,4 TB di dati logici grezzi in Elastic Search (~ 45 GB x 31)

Ma poiché non ho davvero un indizio su quale sarebbe la migliore impostazione, eventuali suggerimenti/suggerimenti/informazioni sarebbero benvenuti.

Potrebbe anche essere utile un sistema o uno strumento che gestisca questo per me (guasto del nodo, ecc.).

Grazie in anticipo,

darkownage

Answer 1

Ecco come ho architettato miei cluster Cloud:

3 nodi antichi - questi nodi del cluster coordinare e mantenere tre di loro aiuta tollera il fallimento. Idealmente questi si diffonderanno attraverso le zone di disponibilità. Questi possono essere abbastanza piccoli e, idealmente, non ricevono alcuna richiesta - il loro unico compito è quello di mantenere il cluster. In questo caso impostare discovery.zen.minimum_master_nodes = 2 per mantenere il quorum. Questi IP e questi IP sono solo ciò che si dovrebbe fornire a tutti i nodi del cluster in discovery.zen.ping.unicast.hosts

indici: probabilmente si dovrebbe approfittare di indici quotidiani - vedere https://www.elastic.co/guide/en/elasticsearch/guide/current/time-based.html Questo renderà più senso al di sotto, ma sarà anche utile se si inizia a scalare up - è possibile aumentare il conteggio dei frammenti nel tempo senza reindicizzare.

Data Nodi: A seconda della scala o dei requisiti di prestazione, ci sono alcune opzioni: i2.xlarge o d2.xlarge funzioneranno bene ma r3.2xlarge sono anche una buona opzione. Assicurati di conservare l'heap JVM < 30 GB. Mantenere i percorsi dei dati su unità effimere locali alle istanze: EBS non è proprio così ideale per questo caso d'uso, ma a seconda dei requisiti potrebbe essere sufficiente. Assicurarsi di disporre di più nodi di dati in modo che i frammenti di replica possano essere suddivisi tra zone di disponibilità. A mano a mano che aumentano i tuoi requisiti, basta ridimensionarli.

Caldo/caldo: a seconda del caso d'uso, a volte è utile suddividere i nodi dati in Hot/Warm (SSD veloce/HDD lento). Ciò è dovuto principalmente al fatto che tutte le operazioni di scrittura sono in tempo reale e la maggior parte delle letture si svolge nelle ultime ore. Se riesci a spostare i dati di ieri su unità più economiche e lente, ti aiuta un bel po '. Questo è un po 'più complicato ma puoi leggere di più allo https://www.elastic.co/blog/hot-warm-architecture. Ciò richiede l'aggiunta di alcuni tag e l'uso di un curatore su base notturna, ma in genere vale la pena a causa dei risparmi sui costi derivanti dallo spostamento di dati in gran parte non ricercati su SSD più costosi.

In produzione, eseguo ~ 20 r3.2xlarge per il livello caldo e 4-5 d2.xlarge per il livello caldo con un fattore di replicazione di 2 - questo consente ~ TB al giorno di ingerimento e una quantità decente di ritenzione . Scaliamo Hot per volume e Warm per conservazione.

Nel complesso, buona fortuna! È una pila divertente da costruire e utilizzare una volta che tutto è andato per il meglio.

PS - A seconda del tempo/risorse disponibili, è possibile eseguire il servizio elasticsearch gestito su AWS, ma l'ultima volta ho visto il suo ~ 60% più costoso rispetto a eseguirlo sulle proprie istanze e YMMV.

Answer 2

sembra che tu bisogno di qualcosa per iniziare con ELK Stack su AWS

sei stato provato questo paio di script CloudFormation, Sarebbe facilitare il processo di installazione e volontà aiutarti a configurare il tuo ambiente in un colpo solo.

ELK-Cookbook - CloudFormation Script

ELK-Stack with Google OAuth in Private VPC

commento qui sotto se questo non risolve il problema.