Escalonando o Logstash (com redis / elasticsearch)

Em um cluster com mais de 12 servidores centos 5.8, implantei o logstash usando o remetente nativo do logstash, que envia de /var/log/*/*.logvolta para um servidor central de logstash.

Tentamos usar o rsyslogd como remetente, mas devido a um erro no módulo ImFile do rsyslogd, se a extremidade remota não responder, os logs se acumularão na memória.

No momento, estamos usando o Redis como o mecanismo de transporte; portanto, o logstash01 possui o redis em execução localmente, vinculado ao IP da VLAN para esses logs.

Portanto, o logstash-shipper envia para redis no logstash01. O logstash01 envia para o Elasticsearch em execução em um processo separado.

Aqui está o que estamos vendo. O Elasticsearch possui 141 threads bloqueados. O rastreamento do pai do elasticsearch mostra:

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

Aqui está o jstack do elasticsearch

Aqui está o jstack do logstash

Então .. Ontem à noite, alguns dos servidores da Web (cujos logs são seguidos por logstash) ficaram loucos, com médias de carga acima de 500.

No logstash01, existe este

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

Então, o OOM-killer matou o redis-server, o que significava logs empilhados na memória nos servidores que estavam enviando coisas. O que de alguma forma significa que o apache mexe nas calcinhas. (Francamente, não sei bem como, apenas assumo que está seguindo o log) ..

Esta é a minha teoria de como os eventos se desenrolaram:

1. Tivemos um pico de tráfego.
2. Uma quantidade imensa de logs foi gerada.
3. Eles foram empilhados em Redis, pois o logstash / elasticsearch parece apenas ser capaz de lidar com 300-400 novos eventos / segundo.
4. Redis se encheu completamente até o ponto em que o assassino da OOM a matou sem sentido.
5. O Redis para de aceitar novos itens.
6. Os itens agora começam a se acumular no lado dos hosts remotos.
7. Tudo fica louco . O Apache para de aceitar solicitações. (Por quê?).

As perguntas são as seguintes:

8. Por que o apache enlouquece se há apenas algo seguindo seu log. Será que a coisa que o segue bloqueia o apache de escrever?

9. Existe uma maneira sensata de tornar a pesquisa elástica mais rápida / melhor / resiliente?

10. Existe uma maneira sensata de tornar os redis resilientes e não morrer por causa de ser OOM

11. Existe uma falha fundamental na maneira como eu configurei tudo, ou todo mundo tem esse problema?

- EDITAR -

Algumas especificações para @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

Sua postagem não descreve muito em termos de especificações (memória no indexador LS, volume de log ou muito mais), mas tentarei responder suas perguntas da melhor maneira possível. Isenção de responsabilidade: sou um dos desenvolvedores do logstash -

1. O apache enlouquecer provavelmente foi um efeito colateral do processo de logstash. Eu deixaria isso de lado por enquanto.

2. A maneira correta de criar ES f / b / s é adicionar mais nós ES. É muito fácil assim. Eles até se descobrem automaticamente, dependendo da topologia da rede. Após 17 anos nesse setor, nunca vi nada escalar horizontalmente tão fácil quanto o ElasticSearch.

3. Para f / b / s Redis, não use nenhum cluster redis. As versões mais recentes do Logstash podem executar o balanceamento de carga do Redis internamente. A saída Redis suporta uma lista de hosts Redis na configuração do plug-in e o suporte está prestes a ser adicionado ao lado da entrada também para corresponder a isso. Enquanto isso, é possível usar várias definições de entrada Redis no lado do indexador / consumidor.

4. Não posso responder isso além de dizer que parece que você está tentando fazer muito com um único (possivelmente host com pouca capacidade).

Qualquer bom processo de dimensionamento começa com a divisão de componentes colocados em sistemas distintos. Não vejo suas configurações listadas em nenhum lugar, exceto nos locais onde os 'gargalos' do logstash estão nos filtros. Dependendo de quantas transformações você estiver fazendo, isso poderá afetar o uso de memória dos processos do Logstash.

O Logstash funciona muito como legos. Você pode usar um bloco 2x4 ou dois blocos 2x2 para realizar a mesma tarefa. Exceto no caso do logstash, é realmente mais resistente usar tijolos menores do que um único tijolo grande.

Alguns conselhos gerais que normalmente damos são:

• envie logs o mais rápido possível a partir da borda Se você puder usar o transporte de rede puro em vez de gravar no disco, isso é bom, mas não é obrigatório. O Logstash é baseado em JVM e isso tem implicações boas e ruins. Use um remetente alternativo. Eu escrevi um baseado em python ( https://github.com/lusis/logstash-shipper ), mas eu sugiro que as pessoas usem o Beaver ( https://github.com/josegonzalez/beaver ).

• gere seus logs em um formato que exija o mínimo de filtragem possível (formato json ou idealmente json-event) Isso nem sempre é possível. Eu escrevi um app4 log4j para fazer isso ( https://github.com/lusis/zmq-appender ) e, eventualmente, interrompi o layout do padrão em seu próprio repositório ( https://github.com/lusis/log4j-jsonevent-layout ) Isso significa que não preciso fazer QUALQUER filtragem no logstash para esses logs. Acabei de definir o tipo na entrada como 'json-event'

Para o apache, você pode tentar esta abordagem: http://cookbook.logstash.net/recipes/apache-json-logs/

• divida as coisas em múltiplos componentes Em todas as palestras que fiz sobre o logstash, descrevo-o como um tubo unix para esteróides. Você pode fazer com que o pipeline seja longo ou curto quanto desejar. Você escala o logstash deslocando as responsabilidades horizontalmente. Isso pode significar tornar o pipeline mais longo, mas não estamos falando de nada estatisticamente relevante em termos de sobrecarga de latência. Se você tem maior controle sobre sua rede (isto é, NÃO no EC2), pode fazer coisas incríveis com isolamento de tráfego padrão.

Observe também que a lista de correio do logstash está MUITO ativa, portanto você deve sempre começar por aí. Limpe e gist suas configurações, pois esse é o melhor lugar para começar.

Existem empresas (como a Sonian) que escalam o ElasticSearch para níveis de petabyte e empresas (como Mailchimp e Dreamhost) que escalam o Logstash para níveis insanos também. Pode ser feito.