Scasta Logstash (con redis / elasticsearch)

En un clúster de más de 12 centos 5.8 servidores, implementé logstash utilizando el cargador de logstash nativo, que envía de /var/log/*/*.logvuelta a un servidor central de logstash.

Intentamos usar rsyslogd como el remitente, pero debido a un error en el módulo ImFile de rsyslogd, si el extremo remoto no respondía, los registros se acumularían en la memoria.

Actualmente estamos utilizando Redis como mecanismo de transporte, por lo que logstash01 tiene redis ejecutándose localmente, vinculado a la IP para la VLAN para estos registros.

Entonces logstash-shipper envía a redis en logstash01. logstash01 envía a Elasticsearch ejecutándose en un proceso separado.

Esto es lo que estamos viendo. Elasticsearch tiene 141 hilos bloqueados. Enderezar el padre elástico de búsqueda muestra:

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

Aquí está el jstack de elasticsearch

Aquí está el jstack de logstash

Entonces ... Anoche, algunos de los servidores web (cuyos registros son seguidos por logstash) se volvieron locos, con promedios de carga superiores a 500.

En logstash01, hay esto

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

Así OOM-asesino mató a Redis-servidor, que a continuación, los registros destinados apilados en la memoria en los servidores de los que estaban entregando cosas .. ¿Qué de alguna manera significa que Apache consigue sus bragas en un giro. (Francamente, no estoy seguro de cómo, solo asumo que está siguiendo el registro) ...

Esta es mi teoría de cómo se desarrollaron los eventos:

1. Tuvimos un pico de tráfico.
2. Se generó una inmensa cantidad de registros.
3. Estos se acumularon en Redis, ya que logstash / elasticsearch solo parece ser capaz de manejar 300-400 nuevos eventos / segundo.
4. Redis se había llenado por completo hasta el punto en que el asesino de OOM lo mató sin sentido.
5. Redis deja de aceptar nuevos artículos.
6. Los elementos ahora comienzan a acumularse en el lado de los hosts remotos.
7. Todo se vuelve loco . Apache deja de aceptar solicitudes. (¿Por qué?).

Las preguntas son estas:

8. ¿Por qué Apache se vuelve loco si hay algo detrás de su registro? ¿Es que lo que sigue bloquea a Apache de la escritura?

9. ¿Hay alguna forma sensata de hacer que la búsqueda elástica sea más rápida / mejor / resistente?

10. ¿Hay alguna forma sensata de hacer que el redis sea resistente y no morir por ser OOM?

11. ¿Existe una falla fundamental en la forma en que lo configuré todo, o todos tienen este problema?

- EDITAR -

Algunas especificaciones 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

Su publicación no describe mucho en cuanto a especificaciones (memoria en el indexador LS, volumen de registro o mucho más), pero primero intentaré responder sus preguntas lo mejor que pueda. Descargo de responsabilidad: soy uno de los desarrolladores de logstash -

1. Apache volverse loco era probablemente un efecto secundario del proceso logstash actuando. Lo dejaría de lado por ahora.

2. La forma correcta de hacer ES f / b / s es agregar más nodos ES. En serio es así de fácil. Incluso se detectan automáticamente entre sí según la topología de la red. Después de 17 años en esta industria, nunca he visto nada escalar horizontalmente tan fácil como ElasticSearch.

3. Para f / b / s Redis, no use ninguna agrupación de redis. Las versiones más recientes de Logstash pueden hacer el equilibrio de carga de Redis internamente. La salida de Redis admite una lista de hosts Redis en la configuración del complemento y el soporte está a punto de agregarse también al lado de entrada para que coincida con eso. Mientras tanto, puede usar múltiples definiciones de entrada de Redis en el lado del indexador / consumidor.

4. No puedo responder esto más allá de decir que parece que estás tratando de hacer demasiado con un solo (posiblemente host con poca potencia).

Cualquier buen proceso de escalado comienza con la división de componentes colocados en sistemas distintos. No veo sus configuraciones en ninguna parte, excepto en los lugares donde los 'cuellos de botella' de logstash están en los filtros. Dependiendo de cuántas transformaciones esté haciendo, puede tener un impacto en el uso de memoria de los procesos de Logstash.

Logstash funciona muy parecido a los legos. Puede usar un ladrillo de 2x4 o puede usar dos ladrillos de 2x2 para realizar la misma tarea. Excepto en el caso de logstash, en realidad es más resistente usar ladrillos más pequeños que un solo ladrillo grande.

Algunos consejos generales que normalmente damos son:

• enviar registros lo más rápido posible desde el borde Si puede usar el transporte de red puro en lugar de escribir en el disco, eso es bueno, pero no es obligatorio. Logstash está basado en JVM y eso tiene implicaciones buenas y malas. Use un cargador alternativo. Escribí uno basado en Python ( https://github.com/lusis/logstash-shipper ) pero sugeriría que la gente use Beaver en su lugar ( https://github.com/josegonzalez/beaver ).

• genere sus registros en un formato que requiera el menor filtrado posible (formato json u óptimamente json-event) Esto no siempre es posible. Escribí un apéndice log4j para hacer esto ( https://github.com/lusis/zmq-appender ) y finalmente rompió el diseño del patrón en su propio repositorio ( https://github.com/lusis/log4j-jsonevent-layout ) Esto significa que no tengo que filtrar NINGÚN logstash para esos registros. Acabo de configurar el tipo en la entrada a 'json-event'

Para apache, puede probar este enfoque: http://cookbook.logstash.net/recipes/apache-json-logs/

• dividir las cosas en múltiples componentes En cada charla que he hecho sobre logstash, lo describo como un tubo unix con esteroides. Puede hacer que la tubería sea tan larga o tan corta como desee. Escala logstash cambiando las responsabilidades horizontalmente. Esto podría significar hacer que la tubería sea más larga, pero no estamos hablando de nada estadísticamente relevante en términos de sobrecarga de latencia. Si tiene un mayor control sobre su red (es decir, NO en EC2), puede hacer cosas increíbles con el aislamiento de tráfico estándar.

También tenga en cuenta que la lista de correo logstash está MUY activa, por lo que siempre debe comenzar allí. Desinfecte y muestre sus configuraciones, ya que es el mejor lugar para comenzar.

Hay compañías (como Sonian) que escalan ElasticSearch a niveles de petabytes y compañías (como Mailchimp y Dreamhost) que también escalan Logstash a niveles locos. Se puede hacer.