¿En qué se diferencia la agregación de métricas de la agregación de registros? No pueden los logs incluir métricas? ¿No pueden los sistemas de agregación de registros hacer las mismas cosas que los sistemas de agregación de métricas?

Estas son preguntas que escucho a menudo. También he visto a los vendedores lanzando su sistema de agregación de registros como la solución a todos los problemas de observabilidad. La agregación de registros es una herramienta valiosa, pero normalmente no es una buena herramienta para los datos de series temporales.

Un par de características valiosas en un sistema de agregación de métricas de series temporales son el intervalo regular y el sistema de almacenamiento personalizado específicamente para los datos de series temporales. El intervalo regular permite a un usuario derivar resultados matemáticos reales de forma consistente. Si un sistema de agregación de registros recoge las métricas en un intervalo regular, puede funcionar potencialmente de la misma manera. Sin embargo, el sistema de almacenamiento no está optimizado para los tipos de consultas que son típicos en un sistema de agregación de métricas. Estas consultas requerirán más recursos y tiempo para ser procesadas utilizando los sistemas de almacenamiento que se encuentran en las herramientas de agregación de registros.

Entonces, sabemos que un sistema de agregación de registros probablemente no es adecuado para datos de series de tiempo, pero ¿para qué sirve? Un sistema de agregación de registros es un gran lugar para recoger datos de eventos. Se trata de actividades irregulares que son significativas. Un ejemplo podría ser los registros de acceso a un servicio web. Estos son significativos porque queremos saber qué está accediendo a nuestros sistemas y cuándo. Otro ejemplo sería una condición de error de la aplicación, ya que no es una condición de funcionamiento normal, podría ser valiosa durante la solución de problemas.

Un puñado de reglas para el registro:

• Incluir una marca de tiempo
• Formatear en JSON
• No registrar eventos insignificantes
• Registrar todos los errores de la aplicación
• Podría registrar las advertencias
• Activar el registro
• Escribir los mensajes en una forma humanamenteforma legible
• NO registrar datos informativos en producción
• NO registrar nada que un humano no pueda leer o reaccionar

Costes de la nube

Cuando se investigan herramientas de agregación de registros, la nube puede parecer una opción atractiva. Sin embargo, puede venir con costos significativos. Los registros representan una gran cantidad de datos cuando se agregan en cientos o miles de hosts y aplicaciones. La ingesta, el almacenamiento y la recuperación de esos datos son caros en los sistemas basados en la nube.

Como punto de referencia de un sistema real, una colección de unos 500 nodos con unos cientos de aplicaciones da como resultado 200 GB de datos de registro al día. Probablemente hay margen de mejora en ese sistema, pero incluso reducirlo a la mitad costará casi 10.000 dólares al mes en muchas ofertas de SaaS. Esto a menudo incluye la retención de sólo 30 días, lo que no es muy largo si quieres mirar los datos de tendencia año tras año.

Esto no es para desalentar el uso de estos sistemas, ya que pueden ser muy valiosos, especialmente para las organizaciones más pequeñas. El propósito es señalar que podría haber costos significativos, y puede ser desalentador cuando se dan cuenta. El resto de este artículo se centrará en las soluciones comerciales y de código abierto que son autoalojadas.

Opciones de herramientas

ELK

ELK, abreviatura de Elasticsearch, Logstash y Kibana, es la herramienta de agregación de registros de código abierto más popular del mercado. La utilizan Netflix, Facebook, Microsoft, LinkedIn y Cisco. Los tres componentes son desarrollados y mantenidos por Elastic. Elasticsearch es esencialmente una implementación del motor de búsqueda NoSQL, Lucene. Logstash es un sistema de canalización de registros que puede ingerir datos, transformarlos y cargarlos en un almacén como Elasticsearch. Kibana es una capa de visualización en la parte superior de Elasticsearch.

Hace unos años, se introdujo Beats. Los Beats son recolectores de datos. Simplifican el proceso de envío de datos a Logstash. En lugar de tener que entender la sintaxis adecuada de cada tipo de registro, un usuario puede instalar un Beat que exportará los registros de NGINX o los registros del proxy Envoy correctamente para que puedan ser utilizados eficazmente dentro de Elasticsearch.

Cuando se instala una pila de ELK a nivel de producción, se pueden incluir algunas otras piezas, como Kafka, Redis y NGINX. Además, es habitual sustituir Logstash por Fluentd, del que hablaremos más adelante. Este sistema puede ser complejo de operar, lo que en sus primeros días llevó a muchos problemas y quejas. Estos se han solucionado en gran medida, pero sigue siendo un sistema complejo, por lo que es posible que no quieras probarlo si eres una operación más pequeña.

Dicho esto, hay servicios disponibles para que no tengas que preocuparte por eso. Logz.io lo ejecutará por ti, pero su precio de lista es un poco caro si tienes muchos datos. Por supuesto, es probable que seas más pequeño y no tengas muchos datos. Si no puedes permitirte el lujo de Logz.io, puedes buscar algo como AWS Elasticsearch Service (ES). ES es un servicio que ofrece Amazon Web Services (AWS) que hace que sea muy fácil conseguir que Elasticsearch funcione rápidamente. También tiene herramientas para obtener todos los registros de AWS en ES usando Lambda y S3. Esta es una opción mucho más barata, pero se requiere cierta gestión y hay algunas limitaciones.

Elastic, la empresa matriz de la pila, ofrece un producto más robusto que utiliza el modelo de núcleo abierto, que proporciona opciones adicionales en torno a las herramientas de análisis, y la presentación de informes. También puede alojarse en Google Cloud Platform o AWS. Esta podría ser la mejor opción, ya que esta combinación de herramientas y plataformas de alojamiento ofrece una solución más barata que la mayoría de las opciones de SaaS y sigue proporcionando mucho valor. Este sistema podría reemplazar efectivamente o darle la capacidad de un sistema de información de seguridad y gestión de eventos (SIEM).

La pila ELK también ofrece grandes herramientas de visualización a través de Kibana, pero carece de una función de alerta. Elastic proporciona la funcionalidad de alerta dentro del complemento X-Pack de pago, pero no hay nada incorporado para el sistema de código abierto. Yelp ha creado una solución a este problema, llamada ElastAlert, y probablemente haya otras. Esta pieza adicional de software es bastante robusta, pero aumenta la complejidad de un sistema ya de por sí complejo.

Graylog

Graylog ha aumentado recientemente su popularidad, pero tuvo sus inicios cuando Lennart Koopmann lo creó allá por 2010. Dos años después nació una empresa con el mismo nombre. A pesar de su creciente uso, todavía está muy por detrás de la pila ELK. Esto también significa que tiene menos características desarrolladas por la comunidad, pero puede utilizar los mismos Beats que utiliza la pila ELK. Graylog ha ganado elogios en la comunidad Go con la introducción del Graylog Collector Sidecar escrito en Go.

Graylog utiliza Elasticsearch, MongoDB, y el Graylog Server bajo el capó. Esto hace que sea tan complejo de ejecutar como la pila ELK y tal vez un poco más. Sin embargo, Graylog viene con alertas integradas en la versión de código abierto, así como varias otras características notables como el streaming, la reescritura de mensajes y la geolocalización.

La característica de streaming permite que los datos se dirijan a Streams específicos en tiempo real mientras se procesan. Con esta función, un usuario puede ver todos los errores de la base de datos en un solo Stream y los errores del servidor web en un Stream diferente. Las alertas pueden incluso basarse en estos Streams cuando se añaden nuevos elementos o cuando se supera un umbral. La latencia es probablemente uno de los mayores problemas de los sistemas de agregación de registros, y los flujos eliminan ese problema en Graylog. Tan pronto como llega el registro, puede ser enrutado a otros sistemas a través de un Stream sin ser procesado completamente.

La función de reescritura de mensajes utiliza el motor de reglas de código abierto Drools. Esto permite que todos los mensajes entrantes sean evaluados contra un archivo de reglas definidas por el usuario permitiendo que un mensaje sea eliminado (llamado Blacklisting), que un campo sea añadido o eliminado, o que el mensaje sea modificado.

La característica más interesante podría ser la capacidad de geolocalización de Graylog, que soporta el trazado de direcciones IP en un mapa. Esta es una característica bastante común y está disponible en Kibana también, pero añade un montón de valor, especialmente si usted quiere usar esto como su sistema SIEM. La funcionalidad de geolocalización se proporciona en la versión de código abierto del sistema.

Graylog, la empresa, cobra por el soporte en la versión de código abierto si lo desea. También ofrece un modelo de núcleo abierto para su versión Enterprise que ofrece archivo, registro de auditoría y soporte adicional. No hay muchas otras opciones de soporte o alojamiento, por lo que probablemente estará por su cuenta si no utiliza Graylog (la empresa).

Fluentd

Fluentd fue desarrollado en Treasure Data, y el CNCF lo ha adoptado como un proyecto de incubación. Fue escrito en C y Ruby y es recomendado por AWS y Google Cloud. Fluentd se ha convertido en un sustituto habitual de Logstash en muchas instalaciones. Actúa como un agregador local para recoger todos los registros de los nodos y enviarlos a los sistemas de almacenamiento central. No es un sistema de agregación de registros.

Utiliza un robusto sistema de plugins para proporcionar integraciones rápidas y fáciles con diferentes fuentes de datos y salidas de datos. Dado que hay más de 500 plugins disponibles, la mayoría de sus casos de uso deberían estar cubiertos. Si no lo están, esto suena como una oportunidad para contribuir a la comunidad de código abierto.

Fluentd es una opción común en entornos Kubernetes debido a sus bajos requisitos de memoria (sólo decenas de megabytes) y su alto rendimiento. En un entorno como Kubernetes, donde cada pod tiene un sidecar de Fluentd, el consumo de memoria aumentará linealmente con cada nuevo pod creado. El uso de Fluentd reducirá drásticamente la utilización de su sistema. Esto se está convirtiendo en un problema común con las herramientas desarrolladas en Java que están destinadas a ejecutarse una por nodo, donde la sobrecarga de memoria no ha sido un problema importante.