¿Alguna vez te has preguntado cómo escalar tu Agente o tu implementación independiente de Beats? ¿Te estás enfrentando al desafío de ingestar datos de numerosos grupos de registros de CloudWatch, solo para descubrir que tu sistema está abrumado por una legión de procesos Beats tipo Grinch que consumen la memoria RAM de tu máquina o saturan tus CPU? Estás pensando, ¿y si agrego uno o quince Agentes más (digamos que tu campaña navideña hizo que tu negocio se volviera viral)? Antes de hacerlo, veamos primero cómo Beats hace su magia y luego repasaremos un ejemplo de cómo hacerlo asegurándote de sacar el máximo provecho de tu configuración.
A lo largo de este artículo, utilizaremos un clúster de ejemplo que usa Elastic Agent, pero la esencia del contenido es igualmente aplicable a Beats independientes. Elastic Agent simplifica el despliegue y la administración del clúster al utilizar múltiples Beats, haciendo que que el escalado sea más sencillo, asegurando la gestión centralizada del agente y la consistencia en las políticas y configuraciones. También ofrece la ventaja adicional de un menor consumo general de CPU y memoria, liberando recursos para otras aplicaciones.
Nos sumergiremos en dos tipos de inputs de Filebeat, es decir, S3-SQS y CloudWatch. En este contexto, discutiremos la escalabilidad vertical y horizontal, también conocida como escalabilidad hacia afuera (escalabilidad hacia adentro para lo inverso), y la escalabilidad vertical también conocida como escalabilidad hacia arriba (escalabilidad hacia abajo para lo inverso).
La escalabilidad vertical se refiere a aumentar tus recursos (más RAM, CPU, etc.), y la escalabilidad horizontal se refiere a agregar más agentes/Beats, es decir, instancias. Con eso, profundizamos en los inputs.
Input S3-SQS
El input S3-SQS (también conocido como S3 input) puede operar en varios modos, entre los cuales:
- S3->Elastic
El input S3-SQS se puede utilizar para ingresar directamente desde un bucket de Amazon S3. Después de la lista inicial del bucket S3 configurado, Filebeat consultará la API de S3 en busca de cambios en ese bucket con una frecuencia del parámetro de configuración bucket_list_interval (por defecto, 300 segundos).
Este modo de operación es con estado en Filebeat, lo que significa que se mantiene el estado de cada archivo, incluido el último desplazamiento que un recolector estaba leyendo, y se guarda regularmente en disco en lo que se llama el archivo de registro (Registry File). Este archivo es crucial para preservar la posición de lectura y asegurar que todas las líneas de registro se envían, especialmente cuando el destino de salida (por ejemplo, Elasticsearch o Logstash) no está disponible temporalmente. Además, la información de estado se mantiene en la memoria mientras Filebeat está en funcionamiento.
Cuando Filebeat se reinicia, reconstruye el estado utilizando datos del archivo de registro, lo que le permite reanudar cada recolector en la última posición conocida. Filebeat asigna un identificador único a los archivos para que un archivo no se identifique por su nombre y ruta, haciéndolo inmune a las operaciones de cambio de nombre y mover. De esta manera, detecta si un archivo ha sido procesado anteriormente.
Debido a la naturaleza de consulta del input, no es posible escalar horizontalmente en este modo, solo verticalmente. Un parámetro de configuración que puede resultarte útil antes de cambiar a otro servidor o cambiar el tipo de instancia en la nube con a otra con más recursos es el parámetro de configuración number_of_workers. Su valor predeterminado para esta entrada es 5. Lo que hace este parámetro es crear un número especificado de hilos ligeros (para aquellos interesados en los detalles, las goroutines comparten un solo espacio de direcciones y se ejecutan simultáneamente) . Esto puede mejorar significativamente el rendimiento, así que esto podría ser algo que quieras probar para tu caso de uso y configuración específicos.
Consejos sobre cómo ajustar number_of_workers: Puedes comenzar con el número de trabajadores igual al número de CPUs. Dado que Filebeat realiza varias operaciones bloqueantes (memoria, por ejemplo, escribir en disco, red, enviar datos a Elasticsearch), puedes experimentar aumentando gradualmente el número de trabajadores para encontrar el lugar óptimo.
Una configuración válida en este modo con múltiples Agentes/Beats es tener cada uno configurado con un bucket diferente. No tiene sentido configurar con el mismo por las razones mencionadas anteriormente.
Nota: Para casos de uso que involucren un gran volumen de archivos para un bucket, el registro puede volverse excesivamente grande. Para esto, puedes buscar opciones de configuración en Filebeat para gestionar el tamaño del archivo de registro o cambiar al modo de operación #2, explicado a continuación, para escalar horizontalmente de manera realmente paralela.
- S3->SQS->Elastic / S3->SNS->SQS->Elastic
Para crear esta configuración, necesitas crear un SQS Queue (SQS cola) y configurar S3 para publicar eventos en esta cola mediante la creación de una notificación de eventos.
Puedes escalar horizontalmente (hacia afuera) configurando múltiples Filebeats para ingerir desde la misma cola SQS. Esto es especialmente útil cuando necesitas leer un gran volumen de archivos. El mecanismo detrás de la ingesta desde SQS se basa en el sondeo prolongado (long polling). En lugar de sondear el servidor con una frecuencia establecida, la solicitud del cliente permanece abierta en el lado del servidor con un tiempo de espera relativamente largo, y en cuanto hay actualizaciones, el servidor envía la información al cliente de manera más cercana al tiempo real (es decir, menor latencia).
SQS garantiza al menos una entrega y solo un procesamiento al realizar un seguimiento de un tiempo de espera de visibilidad (parámetro de configuración
visibility_timeout), es decir, el receptor (es decir, Filebeat) debe operar dentro de la ventana de visibilidad para procesar el mensaje y enviar de vuelta al servidor una señal de que no ha procesado el mensaje y el mensaje se puede eliminar de manera segura. Si no lo hace dentro de esa ventana, el mensaje se enviará nuevamente.
Escalar horizontalmente de esta manera puede aumentar potencialmente significativamente el rendimiento.
Nota (S3 -> SNS -> SQS -> Elastic): También puedes agregar el servicio SNS para la entrega de mensajes, de arquitectura push. Esto significa que, primero, configuras Notificaciones de Amazon S3 a SNS. Luego, creas un tema de SNS (es decir, un canal de comunicación) y suscribes las colas SQS a este canal. Cuando se envía un mensaje al tema, el servicio SNS enviará el mensaje a todos los servicios SQS suscritos. Ten en cuenta que SNS envía varias copias de mensajes a varios suscriptores, y ten en cuenta si necesita registros de uno o más servicios.
Input CloudWatch
El input CloudWatch puede operar en varios modos, entre los cuales:
- CloudWatch -> Elastic
Similarmente al primer modo de operación del input S3-SQS, es decir, ingerir directamente desde un S3 bucket, este modo funciona sobre el mismo principio, sondeando la API de AWS con una frecuencia de scan_frequency (por defecto, 1 minuto para CloudWatch).
Este modo de operación también es con estado y funciona de manera casi idéntica.
De manera similar, debido a la naturaleza de sondeo del input, no es posible escalar horizontalmente en este modo, solo verticalmente. Un parámetro de configuración que podría resultar útil antes de mudarse a otro servidor o cambiar el tipo de instancia en la nube a otra con más recursos es el parámetro de configuración number_of_workers. Su valor predeterminado para esta entrada es 5. Lo que hace este parámetro es crear un número especificado de hilos ligeros (para aquellos interesados en los detalles, las goroutines comparten un solo espacio de direcciones y se ejecutan simultáneamente). Esto puede mejorar significativamente el rendimiento, por lo que esto podría ser algo que desees probar para tu caso de uso y configuración específicos.
Consejos para ajustar number_of_workers: Puedes comenzar con el número de trabajadores igual al número de CPUs. Dado que Filebeat realiza varias operaciones bloqueantes (memoria, por ejemplo, escribir en disco, red, enviar datos a Elasticsearch), puedes jugar con aumentar el número de trabajadores incrementalmente para encontrar el lugar óptimo.
Una configuración válida en este modo con múltiples Agentes/Beats es tener cada uno configurado con un grupo de registros diferente. No tiene sentido configurar con el mismo grupo de registros por las razones mencionadas anteriormente.
Como regla general: Si hay varios grupos de registros:
- Utiliza un solo agente y number_of_workers para escalar dentro del agente.
- Utiliza un agente por grupo de registros/prefijo de grupo de registros.
Si hay solo un grupo de registros y el usuario nota la limitación (throttling):
- Especifica un flujo de registros/prefijo de flujo de registros en lugar de un grupo por agente.
Nota: El parámetro de latencia tiene en cuenta el retraso en el lado de AWS al publicar los eventos, lo que puede resultar en documentos faltantes.
Nota: Para casos de uso que involucren un gran volumen de registros, el registro podría volverse excesivamente grande. Para esto, puedes buscar opciones de configuración en Filebeat para gestionar el tamaño del archivo de registro o cambiar al modo de operación #2, explicado a continuación, para escalar horizontalmente de manera verdaderamente paralela.
Similarmente al segundo modo de operación de la entrada S3-SQS, este modo funciona con el mismo principio, por lo que en esta sección haremos un breve resumen y nos centraremos más en las opciones que tienes para configurar el pipeline ( tubería - cadena de servicios en este caso) en el lado de AWS.
CloudWatch tiene una opción para exportar registros a S3, sin embargo, debe hacerse manualmente cada vez. Si esto se ajusta a tu caso de uso, puedes exportar los registros a S3 y seguir las mismas instrucciones para S3->SQS->Elasticsearch, modo de operación #2 para la entrada S3-SQS.
Para automatizar este proceso, puedes usar filtros de suscripción con AWS Lambda en su lugar. La función Lambda puede enviar los registros a SNS. Luego puedes configurar una o más colas (SQS Queues) para suscribirte a los temas de SNS. Para obtener más información sobre este patrón y un ejemplo de cómo implementarlo, puedes echar un vistazo a este blog.
Finalmente, puedes escalar horizontalmente (hacia afuera) configurando múltiples Filebeats para ingerir desde la misma cola SQS. Esto es especialmente útil cuando necesitas leer un gran volumen de archivos. El mecanismo detrás de la ingesta desde SQS se basa en el sondeo prolongado (long polling), explicado con más detalle anteriormente para el segundo modo de operación del input
S3-SQS.
SQS garantiza al menos una entrega y un procesamiento al realizar un seguimiento de un tiempo de espera de espera de visibilidad (parámetro de configuración visibility_timeout), es decir, el receptor (es decir, Filebeat) debe operar dentro de la ventana de visibilidad para procesar el mensaje y enviar de vuelta al servidor una señal de que no ha procesado el mensaje y el mensaje se puede eliminar de manera segura. Si no lo hace dentro de esa ventana, el mensaje se enviará nuevamente.
Conclusión - nota sobre el rendimiento final
La escalabilidad a varios agentes no necesariamente aumentará el rendimiento en el mismo factor. Esto se debe a que la solución de extremo a extremo consta de varios componentes, como muestra el diagrama a continuación, y solo hemos estado analizando la optimización que podemos hacer en el remitente (Agente/Beats) para acelerar el tiempo de procesamiento.
Ten en cuenta que también hay demoras en poner los datos disponibles en AWS, entre los propios servicios. En este artículo, tampoco hemos analizado Elasticsearch. Los resultados de extremo a extremo dependerán de todos los componentes en la cadena. Ahora que hemos revisado Beats, para comenzar con la configuración más óptima del rendimiento para tu caso de uso en Elasticsearch, puedes consultar esta publicación de blog.
Finalmente, si necesitas procesar registros en tiempo real y no estás dispuesto a tolerar ningun retraso, entonces es probable que otras soluciones como ESF y Kinesis Firehose sean una mejor opción.
Esta publicación también está disponible en inglés.