Scaling Logstash (con redis / elasticsearch)

Su un cluster di oltre 12 centos 5,8 server, ho distribuito logstash usando lo shipper logstash nativo, che rimanda /var/log/*/*.loga un server logstash centrale.

Abbiamo provato a utilizzare rsyslogd come mittente, ma a causa di un bug nel modulo ImFile di rsyslogd, se l'estremità remota non rispondeva, i log si accumulerebbero in memoria.

Attualmente stiamo usando Redis come meccanismo di trasporto, quindi logstash01 ha redis in esecuzione localmente, associato all'IP della VLAN per questi registri.

Quindi logstash-shipper invia a redis su logstash01. logstash01 invia a Elasticsearch in esecuzione in un processo separato.

Ecco cosa stiamo vedendo. Elasticsearch ha 141 thread bloccati. Stracing mostra il genitore di elasticsearch:

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

Ecco il jstack di elasticsearch

Ecco il jstack di logstash

Quindi .. La scorsa notte, alcuni dei server web (i cui registri sono corretti dal logstash) sono impazziti, con medie di carico superiori a 500.

Su logstash01, c'è questo

Dec 19 00:44:45 logstash01 kernel: [736965.925863] Killed process 23429 (redis-server) total-vm:5493112kB, anon-rss:4248840kB, file-rss:108kB

Quindi OOM-killer ha ucciso redis-server, il che significava che i registri si accumulavano in memoria sui server che stavano spedendo roba .. Il che in qualche modo significa che Apache ha una svolta. (Francamente, non sono sicuro di come, presumo solo che stia seguendo il registro) ..

Questa è la mia teoria di come si sono svolti gli eventi:

1. Abbiamo avuto un picco di traffico.
2. È stata generata un'enorme quantità di registri.
3. Questi si sono accumulati in Redis, poiché logstash / elasticsearch sembra essere in grado di gestire solo 300-400 nuovi eventi / secondo.
4. Redis si era riempito completamente fino al punto in cui l'assassino di OOM lo aveva massacrato senza senso.
5. Redis smette di accettare nuovi articoli.
6. Gli oggetti ora iniziano ad accumularsi sul lato host remoti.
7. Tutto va dadi . Apache smette di accettare richieste. (Perché?).

Le domande sono queste:

8. Perché apache impazzisce se c'è solo qualcosa che fa la coda al suo registro. È forse la cosa che fa la coda a bloccare l'apache dalla scrittura?

9. Esiste un modo sano per rendere elasticsearch più veloce / migliore / resiliente?

10. C'è un modo sano per rendere i redis resilienti e non morire a causa della loro OOM

11. C'è un difetto fondamentale nel modo in cui ho impostato tutto o tutti hanno questo problema?

-- MODIFICARE --

Alcune specifiche per @lusis.

admin@log01:/etc/init$ free -m
             total       used       free     shared    buffers     cached
Mem:          7986       6041       1944          0        743       1157
-/+ buffers/cache:       4140       3845
Swap:         3813       3628        185

Filesystem             Size  Used Avail Use% Mounted on
/dev/sda2               19G  5.3G   13G  31% /
udev                   3.9G  4.0K  3.9G   1% /dev
tmpfs                  1.6G  240K  1.6G   1% /run
none                   5.0M     0  5.0M   0% /run/lock
none                   3.9G     0  3.9G   0% /run/shm
/dev/sda1               90M   72M   14M  85% /boot
/dev/mapper/data-disk  471G  1.2G  469G   1% /data

/dev/sda2 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda1 on /boot type ext2 (rw)
/dev/mapper/data-disk on /data type ext3 (rw)
/data/elasticsearch on /var/lib/elasticsearch type none (rw,bind)

log01:/etc/init$ top 
top - 14:12:20 up 18 days, 21:59,  2 users,  load average: 0.20, 0.35, 0.40
Tasks: 103 total,   1 running, 102 sleeping,   0 stopped,   0 zombie
Cpu0  :  3.0%us,  1.0%sy,  0.0%ni, 95.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu1  : 12.0%us,  1.0%sy,  0.0%ni, 86.6%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu2  :  4.7%us,  0.3%sy,  0.0%ni, 94.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  5.6%us,  1.3%sy,  0.0%ni, 93.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  5.3%us,  1.3%sy,  0.0%ni, 93.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  6.4%us,  1.0%sy,  0.0%ni, 92.3%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   8178120k total,  6159036k used,  2019084k free,   761780k buffers

Il tuo post non descrive molto in termini di specifiche (memoria sull'indicizzatore LS, volume di registro o molto altro) ma cercherò prima di rispondere alle tue domande. Disclaimer: sono uno degli sviluppatori di logstash -

1. Apache impazzire era probabilmente un effetto collaterale del processo di logstash. Lo metterei da parte per ora.

2. Il modo sano di creare ES f / b / s è aggiungere più nodi ES. È davvero così facile. Si scoprono anche a vicenda a seconda della topologia di rete. Dopo 17 anni in questo settore non ho mai visto nulla scalare orizzontalmente con la stessa facilità di ElasticSearch.

3. Per f / b / s Redis, non utilizzare alcun cluster redis. Le versioni più recenti di Logstash possono eseguire il bilanciamento del carico Redis internamente. L'output Redis supporta un elenco di host Redis nella configurazione del plug-in e il supporto sta per essere aggiunto anche al lato di input per corrispondere a quello. Nel frattempo è possibile utilizzare più definizioni di input Redis sul lato indicizzatore / consumatore.

4. Non posso rispondere a ciò oltre a dire che sembra che tu stia provando a fare molto con un singolo host (possibilmente sottodimensionato).

Qualsiasi buon processo di ridimensionamento inizia con la suddivisione dei componenti collocati in sistemi distinti. Non vedo le tue configurazioni configurate da nessuna parte, ma i luoghi in cui i "colli di bottiglia" del logstash sono nei filtri. A seconda di quante trasformazioni stai facendo, può avere un impatto sull'utilizzo della memoria dei processi Logstash.

Logstash funziona in modo molto simile ai lego. Puoi usare un mattoncino 2x4 oppure puoi usare due mattoncini 2x2 per svolgere lo stesso compito. Tranne nel caso del logstash, in realtà è più robusto usare mattoni più piccoli di un singolo mattone grande.

Alcuni consigli generali che normalmente forniamo sono:

• spedire i log il più rapidamente possibile dal bordo Se è possibile utilizzare il trasporto di rete puro invece di scrivere su disco, è carino ma non necessario. Logstash è basato su JVM e ha implicazioni buone e cattive. Utilizzare uno spedizioniere alternativo. Ne ho scritto uno basato su Python ( https://github.com/lusis/logstash-shipper ) ma suggerirei invece che la gente usi Beaver ( https://github.com/josegonzalez/beaver ).

• genera i tuoi log in un formato che richiede il minor filtraggio possibile (formato json o json-event in modo ottimale) Questo non è sempre possibile. Ho scritto un appender log4j per farlo ( https://github.com/lusis/zmq-appender ) e alla fine ho suddiviso il layout del modello nel suo repository ( https://github.com/lusis/log4j-jsonevent-layout ). Questo significa che non devo fare QUALSIASI filtro nel logstash per quei registri. Ho appena impostato il tipo in input su "json-event"

Per apache, puoi provare questo approccio: http://cookbook.logstash.net/recipes/apache-json-logs/

• spezzare le cose in più componenti In ogni discorso che ho fatto sul logstash, lo descrivo come un tubo unix sugli steroidi. Puoi rendere la pipeline lunga o corta quanto vuoi. Il logstash viene ridimensionato spostando le responsabilità in senso orizzontale. Ciò potrebbe significare allungare la pipeline ma non stiamo parlando di qualcosa di statisticamente rilevante in termini di latenza ambientale. Se hai un maggiore controllo sulla tua rete (cioè NON su EC2) puoi fare cose sorprendenti con l'isolamento del traffico standard.

Nota inoltre che la mailing list del logstash è MOLTO attiva, quindi dovresti sempre iniziare da lì. Disinfetta e trasforma le tue configurazioni in quanto è il posto migliore da cui iniziare.

Ci sono aziende (come Sonian) che ridimensionano ElasticSearch a livelli petabyte e aziende (come Mailchimp e Dreamhost) che ridimensionano Logstash anche a livelli folli. Si può fare.