Hoy hablamos de Beats; unos componentes que utilizados correctamente nos ahorrarán tiempo y complejidad en la extracción de datos de nuestros procesos de negocio.
¿Qué son los Beats?
Los Beats son los agentes de extracción de datos nativos de Elasticsearch, se utilizan para extraer e introducir datos para todas las funcionalidades que este nos ofrece una vez que se instalan en la infraestructura deseada.
¿Dónde se ubican en el Stack de Elastic?
A nivel de Stack de Elasticsearch los Beats están en la capa más baja, es decir, son los encargados de realizar la parte de la recolección de datos de las distintas tecnologías de las cuales necesitamos recoger información de valor para nuestras monitorizaciones de procesos técnicos o funcionales
- No siempre se utilizan los Beats como punto de inicio de lectura de datos puesto que Logstash también permite integración con infinidad de inputs
- Antes de extraer datos de una tecnología hay que analizar qué estrategia se utilizará para el proceso de ETL de dicho proceso
¿Qué tipos de Beats existen?
A día de hoy los Beats oficiales de Elasticsearch son los siguientes:
- Auditbeat: Lee datos del framework de auditoría de Linux (auditd) y controla la integridad de los archivos.
- Metricbeat: Extrae métricas de sistema y aplicaciones. Se integra de forma nativa con infinidad de tecnologías gracias a los módulos preexistentes.
- Filebeat: Recolecta logs de sistema y aplicaciones. Se integra de forma nativa con infinidad de tecnologías gracias a los módulos preexistentes.
- Winlogbeat: Misma funcionalidad que filebeat para leer los eventos de los sistemas Windows.
- Packetbeat: Monitoriza el tráfico de red de tu infraestructura y consigue métricas como latencia y errores, tiempos de respuesta, patrones y tendencias de comportamiento de usuarios.
- Heartbeat: Mide el tiempo de disponibilidad de un sistema o aplicación de forma activa con sondas de monitorización.
APM Server aunque no es un Beat, también está desarrollado sobre libbeat.
Todos los beats están desarrollados sobre libbeat, una librería escrita completamente en Go que ofrece la API que todos los Beats usan para enviar datos a Elasticsearch, estandariza las funcionalidades a nivel de código, opciones de input y de configuraciones entre beats.
Aparte de los beats oficiales existe una larga lista de “Community Beats” que se desarrollan por la comunidad de cara a cubrir necesidades más concretas.
¿Cómo funcionan? Ejemplo de problema
Imaginemos el escenario de un entorno sencillo compuesto por un servidor Apache proxificado por un Nginx.
Debido a la alta carga de tráfico que está recibiendo el proxy, es necesario controlar que el número actual de conexiones de clientes inactivas no sea superior a un determinado umbral.
Centrándonos en Nginx, ¿Qué datos de interés podemos extraer de las métricas?
Metricbeat
- Primeramente revisamos en la documentación del módulo de metricbeat los metricsets soportados.
a. Vemos que Nginx a día de hoy solamente soporta extraer métricas mediante el módulo ngx_http_stub_status (stubstatus).
b. Verificar del lado de nginx que stubstatus está correctamente instalado y accesible mediante su endpoint.
c. Siguiendo la documentación del metricset, vemos un ejemplo de los datos que nos sacaría una lectura:
- Observamos que tenemos la métrica “waiting”; es la que nos permitirá controlar las conexiones en espera.
- Realizando una correcta configuración de metricbeat y elasticsearch para extraer esa métrica en cuestión, conseguiremos medir satisfactoriamente dicha necesidad con un panel similar al siguiente:
además de poder configurar el alertado basado en Machine Learning, abstrayéndonos totalmente de tener que configurar algún tipo de umbral y poder detectar alta volumetría de forma dinámica y eficiente.
Filebeat
La información de los logs de Nginx (access.log y error.log) contienen información muy valiosa y con una correcta extracción mediante Filebeat podemos conseguir un cuadro de mandos como el siguiente (y más):
