¿Debo usar Logstash o los nodos de ingestión de Elasticsearch?

Logstash fue uno de los componentes originales de Elastic Stack y ha sido, durante mucho tiempo, la herramienta para analizar, enriquecer o procesar datos. Con los años, se fueron agregando muchos complementos de entrada, salida y filtro, lo que la convirtió en una herramienta bastante flexible y potente, apta para una variedad de arquitecturas diferentes.

Los nodos de ingestión se presentaron con Elasticsearch 5.0 como una forma de procesar documentos en Elasticsearch antes de la indexación. Estos nodos permiten arquitecturas más sencillas con una cantidad mínima de componentes, en las que las aplicaciones envían datos directamente a Elasticsearch para procesar e indexar. A menudo, esto simplifica el inicio con Elastic Stack, pero también escala horizontalmente cuando los volúmenes de datos aumentan.

Sin embargo, el nodo de ingestión duplica algunas de las funcionalidades de Logstash, por lo que muchos usuarios preguntan con frecuencia cuál deben usar. En esta artículo del blog, analizaremos los aspectos arquitectónicos que debes tener en cuenta a la hora de elegir entre los dos con el objetivo de ayudarte a tomar una decisión mejor informada.

Esta es la tercera entrega de nuestra serie sobre preguntas frecuentes que tienen los usuarios. Las anteriores fueron:

• ¿Cuántas particiones debo tener en mi clúster de Elasticsearch?
• ¿Por qué veo rechazos masivos en mi clúster de Elasticsearch?

¿Cómo entran y salen los datos?

Una de las diferencias principales entre Logstash y el nodo de ingestión es la forma en que los datos entran y salen.

A medida que el nodo de ingestión se ejecuta dentro del flujo de indexación de Elasticsearch, los datos deben insertarse mediante solicitudes masivas o de indexación. Por lo tanto, debe haber un proceso que escriba datos activamente en Elasticsearch. Un nodo de ingestión no puede extraer datos de una fuente externa, como una cola de mensajes o una base de datos.

Hay una restricción similar después de que los datos se procesan: la única opción es indexar los datos localmente en Elasticsearch.

Por otro lado, Logstash cuenta con una amplia variedad de complementos de entrada y salida, y puede usarse para admitir diversas arquitecturas. Puede actuar como servidor y aceptar datos insertados por los clientes por TCP, UDP y HTTP, además de extraer datos activamente desde, por ejemplo, bases de datos y colas de mensajes. En lo que respecta a la salida de datos, hay una gran variedad de opciones disponibles, por ejemplo, colas de mensajes como Kafka y RabbitMQ o el archivo de datos a largo plazo en S3 o HDFS.

¿Qué hay de las colas y la contrapresión?

Al enviar datos a Elasticsearch, ya sea directamente o mediante una canalización de ingestión, los clientes necesitan poder resolver el caso cuando Elasticsearch no pueda aceptar más datos. Esto es lo que denominamos aplicar contrapresión. Si los nodos de datos no pueden aceptar datos, el nodo de ingestión dejará de aceptar datos también.

Las arquitecturas en las que no hay un mecanismo de cola incorporado a la canalización de procesamiento, ya sea en la fuente o a lo largo del proceso, tienen el potencial de perder datos si no se puede acceder a Elasticsearch o este no puede aceptar datos durante un período prolongado. Esto incluye Beats, que no puede almacenar ni leer datos desde el archivo, así como otros procesos que pueden escribir datos directamente en Elasticsearch, como syslog-ng.

Logstash puede poner datos en cola en un disco mediante la función de colas persistentes, lo que permite que Logstash ofrezca garantías de entrega al menos una vez y almacene datos en búfer a nivel local durante los picos de ingestión. Logstash también admite la integración con diversos tipos de colas de mensajes, lo que permite contar con varios patrones de implementación compatibles.

¿Cómo enriquezco y proceso mis datos?

El nodo de ingestión incluye más de 20 procesadores diferentes que abarcan la funcionalidad de los complementos más usados de Logstash. Sin embargo, una de las limitaciones es que la canalización del nodo de ingestión solo funciona en el contexto de un único evento. Además, los procesadores en general no pueden comunicarse con otros sistemas ni leer datos del disco, lo que limita los tipos de enriquecimiento que pueden llevar a cabo.

Logstash cuenta con una selección significativamente más grande de complementos para elegir. Esto incluye complementos para agregar o transformar contenido basado en búsquedas en archivos de configuración, Elasticsearch o bases de datos relacionales.

Beats y Logstash también permiten filtrar y anular eventos en función de criterios configurables, algo que no es posible actualmente en el nodo de ingestión.

¿Cuál es más fácil de configurar?

Este es un tema muy subjetivo, y depende de tu experiencia y de lo que sueles hacer. Cada canalización de nodo de ingestión se define en un documento JSON que se almacena en Elasticsearch. Se puede definir una gran cantidad de canalizaciones diferentes, pero los documentos solo se pueden procesar por una sola cuando atraviesan el nodo de ingestión. Este formato puede ser un poco más fácil de usar que el formato de archivo de configuración de Logstash, al menos para canalizaciones bien definidas y razonablemente simples. Para canalizaciones más complejas con múltiples formatos de datos, el hecho de que Logstash admita el uso de condicionales para controlar el flujo suele facilitar su uso. Asimismo, Logstash admite la definición de múltiples canalizaciones separadas lógicamente, que pueden administrarse a través de una interfaz de usuario basada en Kibana.

También vale la pena mencionar que la medición y la optimización de la canalización es generalmente más fácil en Logstash, ya que este admite el monitoreo y ofrece una excelente interfaz de usuario (UI) de visualización de la canalización que puede usarse para detectar atascos y problemas potenciales rápidamente.

¿Cómo se ve afectado el consumo de recursos de hardware?

Una de las mayores ventajas de los nodos de ingestión es que admiten arquitecturas muy simples, en las que Beats puede escribir directamente en una canalización de nodo de ingestión. Cada nodo en un clúster de Elasticsearch puede actuar como nodo de ingestión, lo que permite acotar el consumo de recursos de hardware y simplificar la complejidad de la arquitectura, al menos para los casos de uso más pequeños.

Cuando los volúmenes de datos aumentan o el procesamiento se vuelve más complejo y se genera mayor carga de la CPU en el clúster, generalmente se recomienda cambiar a nodos de ingestión dedicados. En este punto, se necesita hardware adicional para alojar los nodos de ingestión dedicados o Logstash, y cualquier diferencia en el consumo de recursos dependerá, en gran medida, del caso de uso.

¿Los nodos de ingestión pueden hacer algo que Logstash no pueda?

Hasta ahora, parece que los nodos de ingestión solo ofrecen un subconjunto de la funcionalidad que admite Logstash, pero esto no es totalmente cierto.

Los nodos de ingestión admiten el complemento de procesador de datos adjuntos de ingestión, que puede usarse para procesar e indexar datos adjuntos en formatos comunes, como PPT, XLS y PDF. Actualmente, no hay complementos equivalentes disponibles para Logstash, por lo que, si planeas indexar varios tipos de datos adjuntos, es posible que necesites un nodo de ingestión.

Dado que la canalización de ingestión se ejecuta justo antes de la indexación de datos, es también el método más confiable para agregar una marca de tiempo que indique cuándo se indexó el evento, por ejemplo, para medir y analizar las demoras de ingestión de forma precisa. Configurar esto antes de que los datos lleguen correctamente a Elasticsearch puede resultar engañoso, ya que puede haber demoras entre la fijación de la marca de tiempo y la indexación de datos en Elasticsearch, por ejemplo, si se aplica contrapresión o si el cliente se ve forzado a reintentar la indexación de los datos varias veces. Este tipo de marcas de tiempo puede usarse para medir la demora de ingestión por documento.

¿Puedo usar Logstash y el nodo de ingestión en conjunto?

Aunque la mayoría de las veces se prefiere usar uno de ellos, naturalmente es posible usar ambos en conjunto, ya que Logstash admite el envío de datos a una canalización de ingestión. Para arquitecturas más complejas puede haber múltiples flujos lógicos con requisitos muy diferentes. Algunos pueden pasar por Logstash, mientras que otros se envían directamente a los nodos de ingestión de Elasticsearch. Usar el que tenga más sentido para cada flujo de datos facilitará el mantenimiento de la arquitectura.

Conclusiones

Hay cierta superposición de funcionalidades entre Logstash y el nodo de ingestión de Elasticsearch. Esto quiere decir que algunas arquitecturas pueden implementarse con cualquiera de estas tecnologías. Ambas opciones tienen sus ventajas y sus desventajas, por lo que es importante analizar los requisitos y la arquitectura de tu canalización de procesamiento entera, y seleccionar la más adecuada en función de los criterios expuestos en esta artículo del blog. La elección no es siempre preferir una, ya que pueden usarse en conjunto o en paralelo para diferentes partes de la canalización de procesamiento.