Imagina que estás dando un paseo por el emocionante mundo de la monitorización y gestión de datos en tu cluster de Elasticsearch. Tradicionalmente, disponíamos de los famosos “Elastic Beats”, como pequeños ayudantes que recopilaban y enviaban información valiosa a tu central de mando. Pero ahora tenemos en nuestras manos el siguiente nivel. Ha llegado el momento de conocer a los “Elastic Agents”.
Antes se tomaba como que los beats eran agentes únicos que solo buscaban un tipo de dato único, pero ahora con Elastic Agents tenemos todo un escuadrón que pueden realizar varias tareas al mismo tiempo.
Ahora, con la evolución natural de Beats a Elastic Agents, podemos disfrutar de la centralización de las configuraciones y normalización en el sistema que estemos manejando.
Descripción básica de beats
Antes de empezar a mencionar los componentes de “Elastic Agents”, vamos a conocer ligeramente a sus predecesores: los beats.
Por decirlo de forma simple, estas herramientas nos ayudan a enviar datos de distinta índole, ya sean logs, métricas o eventos, para poder ser encolados, procesados o almacenados para su posterior monitorización.
La familia beats
Todo tipo de agentes para todo tipo de datos
Filebeat
Agente ligero para logs y otros datos
Metricbeat
Agente ligero para datos de métricas
Packetbeat
Agente ligero para datos de red
Winlogbeat
Agente ligero para logs de eventos de Windows
Auditbeat
Agente ligero para información de auditoría
Heartbeat
Agente ligero para monitoreo de tiempo de actividad
Los beats, además, cuenta con la posibilidad de realizar un procesamiento ligero de los datos que, si bien no es tan versátil como el de Logstash, puede resultar útil en ciertas ocasiones.
Elastic Agents
Ahora tenemos que pensar que todo lo anterior mencionado en la parte de Beats se puede unificar en un único agente, el cual podrá encargarse de la recogida y envío de los datos hacia nuestro output.
Este agente es capaz de recoger los datos tanto del host donde se encuentran como externos sin importar que tipo de dato sea, métricas, logs etc. En la siguiente imagen podemos ver un esquema de la estructura básica y el flujo que siguen los datos utilizando Elastic Agents.
Elastic Agents cuenta principalmente con tres componentes
Integraciones
Las integraciones son elementos que tienen los agentes para poder conectarse, consumir, enviar y procesar datos. Esto permite a Elastic Agents una gran flexibilidad y funcionalidad, al tener integraciones con una gran variedad de tecnologías.
Como no podía ser de otra manera, Elastic Agent tiene integraciones con los componentes del stack de Elasticsearch, Logstash y Kibana de donde podrán recoger o enviar datos y procesarlos; así mismo cuenta también con integraciones para los Beats de Elasticsearch, aunque pueda parecer redundante, ya que Elastic Agents busca sustituir los Beats. Si queremos comenzar a integrar el agente y es necesario que envíe información a un Beat, se puede realizar sin problema.
Por otra parte, la característica que nos ofrece mayor flexibilidad es la integración con los módulos de terceros y de la comunidad que a su vez ofrece compatibilidad con una gran cantidad de tecnologías entre las que se encuentran AWS, PostgreSQL, Kubernetes, Kafka o Slack entre muchos otros.
Políticas
Son un componente esencial para la trasmisión y procesamiento de los datos, a partir de un conjunto de reglas de comportamiento y configuraciones. Con ellas podemos definir cómo van a recoger los datos los agentes según nuestras necesidades específicas, así como el tipo de datos a recolectar y las aplicaciones a las que atacaremos.
Otra funcionalidad interesante es que nos permite ocultar secretos o datos confidenciales para que no sean vistos en el output.
En ellas se pueden organizar los destinos de envío de los datos, la actualización y el mantenimiento de los grupos de agentes asociados, lo que permite una gran escalabilidad y automatización para gestionar nuestra flota de agentes de manera centralizada y eficiente.
Fleet
Es el centro de mando de los agentes que tengamos desplegados, donde podremos organizar los despliegues, ver el estado de cada uno de los agentes y realizar la administración de las políticas y del versionado.
Permite a las organizaciones administrar de forma eficiente y centralizada una gran cantidad de agentes, garantizando unanimidad en el comportamiento y configuración de los agentes a los que administra.
Formas de despliegue
Fleet Managed
Utilizando el antes mencionado Fleet server podremos realizar los despliegues y configuraciones de manera centralizada, utilizando la interfaz gráfica que se ofrece en Kibana para este componente. De manera intuitiva, conseguiremos desplegar los agentes junto con sus políticas de configuración ofreciendo una gran escalabilidad y flexibilidad.
El servidor de Fleet es el encargado de mediar entre Kibana Fleet UI y los Elastic Agents instalados.
Standalone
Este tipo de despliegue no utiliza el Fleet server, normalmente se utiliza para realizar despliegues en entornos independientes que no necesitan administración centralizada de las configuraciones. Para ello debes configurarlo de manera manual, así como realizar su seguimiento y la verificación de su funcionamiento.
Beats vs Elastic Agent
Podemos ver que ambas opciones son bastante flexibles y tienen sus propias ventajas e inconvenientes.
Utilizar Elastic Agents nos puede facilitar tanto la gestión como el despliegue de los agentes gracias a las políticas, lo que es bastante atractivo, ya que podemos gestionarlo todo desde un mismo lugar, Fleet. Además, con un único agente podemos recoger varios casos de uso, es decir, podemos recoger con el mismo agente, logs, métricas, etc. de distintas integraciones.
Como contraparte, podemos ver que los outputs que están disponibles para Elastic Agents son menos variados que en Beats; como, por ejemplo, el output de Redis no está disponible actualmente y el de Kafka ahora mismo se encuentra dentro de la fase beta.
Así pues, para realizar la gestión centralizada de los agentes es necesario instalar un componente nuevo que es el Fleet server, añadiendo así un componente extra en nuestra infraestructura, además de que si queremos migrar de Beats a Elastic Agents necesitaremos mantener ambas infraestructuras y componentes hasta que se finalice completamente el proceso.
Por último, añadir que los agentes de Fleet no soportan la configuración de las colas de memoria por el usuario.
Conclusión
En definitiva, podemos ver que Elastic Agents nos puede ofrecer una alternativa sólida a los clásicos Beats, debido a la gran variedad de integraciones, además de su gestión y administración centralizada tanto de configuraciones como de despliegues de los distintos agentes que queramos tener, dándole una gran ventaja en escalabilidad a Beats.
Por otro lado, Beats tienen una base muy grande de usuarios y cuenta con una gran utilización entre la comunidad debido a su simplicidad y ligereza.
Como opinión personal, creo que en el futuro se seguirán utilizando ambas herramientas, ya que su utilización puede variar dependiendo de nuestras propias necesidades; pero sí que veo que un entorno centralizado donde poder realizar la administración y despliegue de varios agentes y que cada uno de los agentes pueda realizar varias extracciones o tratamiento de datos de varias fuentes gracias a las integraciones era necesario, ya que la manera de automatizar los despliegues de Beats era con herramientas externas o personalizadas, así como para el mantenimiento de las configuraciones.
