Logstash de Escala (com redis / elasticsearch)

Question

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

Nós tentamos usar o rsyslogd como o remetente, mas devido a um bug no módulo ImFile do rsyslogd, se a extremidade remota não respondesse, os logs se acumulariam na memória.

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

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

Veja o que estamos vendo. Elasticsearch tem 141 tópicos bloqueados. Stracing o pai 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 web (cujos logs são seguidos pelo logstash) ficaram malucos, com uma média de carga acima de 500.

No logstash01, há isso

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, OOM-killer matou o redis-server, que significava que os logs empilhavam na memória dos servidores que estavam enviando coisas. O que, de alguma forma, significa que o apache obtém sua calcinha em uma reviravolta. (Francamente, não tenho certeza de como, presumo que esteja seguindo o log) ...

Esta é minha teoria de como os eventos se desenrolaram:

1. Tivemos um pico de tráfego.
2. Uma quantidade imensa de logs foi gerada.
3. Estes são empilhados no Redis, já que o logstash / elasticsearch só parece ser capaz de lidar com 300-400 novos eventos / segundo.
4. Redis tinha preenchido completamente ao ponto em que o matador de OOM o massacrou sem sentido.
5. Redis para de aceitar novos itens.
6. Os itens agora começam a se acumular no lado dos hosts remotos.
7. Tudo fica nozes . O Apache para de aceitar pedidos. (Por quê?).

As perguntas são estas:

8. Por que o apache enlouquece se há apenas algo seguindo seu log. É que a coisa que está por trás bloqueia o apache da escrita?

9. Existe uma maneira sensata de tornar o elasticsearch mais rápido / melhor / resiliente?

10. Existe uma maneira sensata de tornar os redis resilientes e não morrerem por serem OOM'd

11. Existe uma falha fundamental na maneira como configurei tudo ou todos têm 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

    

Answer 1

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

1. Apache enlouquecendo provavelmente foi um efeito colateral do processo de logstash agindo. Eu deixaria isso de lado por enquanto.

2. A maneira sã de fazer ES f / b / s é adicionar mais nós ES. É tão fácil assim. Eles até mesmo se descobrem mutuamente, dependendo da topologia da rede. Depois de 17 anos nesta indústria, nunca vi nada horizontalmente tão fácil como o ElasticSearch.

3. Para f / b / s Redis, não use nenhum cluster de redis. Versões mais recentes do Logstash podem fazer o balanceamento de carga Redis internamente. A saída do Redis suporta uma lista de hosts Redis na configuração do plugin e o suporte está prestes a ser adicionado ao lado da entrada, bem como para corresponder a isso. Nesse ínterim, você pode usar várias definições de entrada do Redis no lado do indexador / consumidor.

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

Qualquer bom processo de escalonamento começa com a quebra de componentes colocados em sistemas distintos. Eu não vejo suas configurações em qualquer lugar, exceto nos lugares onde os 'gargalos' do logstash estão nos filtros. Dependendo de quantas transformações você está fazendo, isso pode ter um impacto no uso de memória dos processos do Logstash.

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

Alguns conselhos gerais que normalmente damos são:

• envia logs o mais rápido possível da borda Se você pode usar o transporte de rede puro em vez de gravar em disco, isso é bom, mas não é obrigatório. O Logstash é baseado em JVM e isso tem boas e más implicações. Use um remetente alternativo. Eu escrevi um baseado em python ( link ), mas eu sugiro que as pessoas usem o Beaver ( link ).

• gere seus logs em um formato que requer o mínimo de filtragem possível (json ou otimamente o formato de evento json) Isso nem sempre é possível. Escrevi um appender log4j para fazer isso ( link ) e acabei quebrando o layout do padrão em seu próprio repositório ( link ). Isso significa que não preciso fazer QUALQUER filtragem no logstash para esses logs. Acabei de definir o tipo de entrada para 'json-event'

Para o apache, você pode tentar essa abordagem: link

• divida as coisas em vários componentes Em todas as conversas que fiz sobre o logstash, eu o descrevo como um tubo unix em esteróides. Você pode fazer o pipeline o tempo que desejar. Você dimensiona o logstash ao mudar 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ê tiver maior controle sobre sua rede (ou seja, NÃO no EC2), poderá fazer algumas coisas incríveis com o isolamento de tráfego padrão.

Observe também que a lista de discussão do logstash é MUITO ativa, então você deve sempre começar por aí. Sanitize e guarde suas configurações, pois esse é o melhor lugar para começar.

Existem empresas (como a Sonian) escalando o ElasticSearch para níveis de petabyte e empresas (como Mailchimp e Dreamhost), escalando o Logstash para níveis insanos também. Isso pode ser feito.