Supresión logs locales y unificación ELK


(Alberto Solórzano) #1

Hola,

Me están planteando un proyecto en el que suprimir todo el volcado de logs locales y derivarlos directamente a una plataforma ELK.

La información que prima es la de logs de aplicaciones en PHP e iteracciones de Webservers, sobre todo cara a depurar aplicaciones "grandes" que generan un tamaño de BBDD desorbitado en el que casi el 80% es información de logs.

Consideran interesante también volcar todos los logs de sistema, apache, MySQL.. cara a la explotación de datos por parte del departamento de calidad y Big Data.

Seguro que alguno de los expertos que anda por aquí tiene la bondad de indicarme más o menos cómo abordar el proyecto y por qué camino he de avanzar.

Gracias, un saludo.


(Ismael Hasan Romero) #2

Hola Alberto! La respuesta a esta pregunta da para escribir un libro :). Voy a intentar tocar brevemente algunos puntos que creo que pueden ser clave:

No intentes añadir todas las fuentes de datos desde el principio. Mi impresión por el mensaje es que vais a comenzar a usar el stack de Elastic ahora, por lo que imagino que no tenéis mucha experiencia todavía. Lo ideal es que empieces con una de las fuentes de datos a modo de POC, para que os familiaricéis con el stack, cómo procesar la información... Una de las ventajas del stack es que es fácil escalar, así que lo más sencillo es empezar por una fuente de datos, "dominarla" y entender mejor el stack a través de la práctica, y entonces comenzar a añadir las demás - posiblemente añadiendo en el proceso más máquinas para adecuar el cluster al tamaño del proyecto.

Capacity planning: por lo que entiendo, este proyecto va a manejar una gran cantidad de datos. Es importante evaluar cual es el tamaño ideal de shard para el cual los tiempos de búsqueda e indexación están dentro de las expectativas. Con ese tamaño, puedes decidir cuantos nodos necesitas en tu cluster, etc.
Un tema a considerar aquí es que los logs son de naturaleza temporal, i.e, día a día. En este caso, si la decisión en el tamaño de los shards no fuese la adecuada, simplemente lo cambiamos para los siguientes días. Este blog contiene buen material respecto a shards, etc.

Políticas de retención. Es importante mantener una política de retención estricta - la cantidad de datos no puede crecer indefinidamente. Esto se puede automatizar con Curator.

Arquitecturas hot-warm. Cuando tenemos un proyecto que va a manejar muchos datos de naturaleza temporal es típico que los datos más recientes sean los más utilizados, mientras que los menos recientes son más bien históricos - no se actualizan, no se consultan habitualmente. En este sentido es típico tener máquinas con discos rápidos para los datos frescos, y máquinas con discos más lentos pero con mayor capacidad de almacenamiento para los datos antiguos; por ejemplo, mantener en máquinas que responden rápido 3 días de datos, y en máquinas que responden más lento 3 meses.

Procesado de datos. Aquí entran en juego los diferentes tipos de datos que tienes como origen. Si los datos no necesitan procesamiento (o no necesitan procesamiento complejo), es habitual usar Beats, que son aplicaciones stand-alone escritas en Go. Si se requiere algún procesado extra, Logstash puede ser usado (con o sin Beats), ya que nos va a permitir realizar procesado de la información (por ejemplo, separar líneas de logs en campos, etc). Otra alternativa cuando requerimos algún tipo de procesado es utilizar Ingest nodes.

Como ves, es un tema muy amplio :D. Espero que estos puntos te sirvan para comenzar un proyecto exitoso! Como decía, empieza con un POC pequeño, y luego ya es más sencillo adaptar la arquitectura a hot-warm si es necesario, etc.


(system) #3

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.