Las empresas apoyan sus decisiones en distintas fuentes de datos, entre las que se incluyen los datos propios generados por sus sistemas informáticos. Estos pequeños fragmentos de información, llamados logs, nos ayudan a entender el comportamiento de nuestros programas y sistemas de información, a analizar su rendimiento y a detectar vulnerabilidades / oportunidades dentro del negocio.
Hace unas semanas profundizábamos en este tema a través de un post introductorio sobre los logs y hoy os proponemos retomarlo con un caso de uso muy sencillo. ¿Lo vemos?
¿Por qué te interesa centralizar tus logs?
Los equipos de IT se ocupan de mantener los sistemas funcionando pero, en los últimos años, hemos empezado a ver cómo se aplican técnicas de análisis para obtener insights de negocio. Las aplicaciones generan información, logs, que se almacena en sus propios ficheros causando, de esta forma, problemas de visibilidad.
Y aquí surge la necesidad de centralizar. La agrupación de los ficheros de logs en un único sitio facilita analizar el rendimiento de ese sistema y plantear continuamente posibles mejoras. Aquí tienes otras ventajas que pueden interesarte:
- Detección de errores: Permite depurar las aplicaciones, es decir, realizar las pruebas necesarias para prevenir posibles problemas.
- Gestión de excepciones.
- Configuración de alarmas y disparadores.
- Extracción de información adicional: Se puede acceder a datos secundarios como, por ejemplo, a los códigos HTTP de solicitudes a servidores invocados por las APIs de nuestros programas.
La configuración de alertas en tiempo real, por ejemplo, puede prevenir futuras reparaciones manuales, así como los datos nos ayudan a detectar la necesidad de actualizar tanto el software como el hardware y reducir los tiempos de intervención de personal cualificado. Al final, el ahorro económico es evidente.
¿Cómo centralizamos los logs?
Caso de uso: Cómo recoger y almacenar logs
Aunque las posibilidades son infinitas, centraremos el caso de uso en resolver un problema habitual en equipos de desarrollo: ¿Cómo analizar programas que siempre están en ejecución emitiendo información a ficheros?
Normalmente, los técnicos suelen revisar estos ficheros de logs manualmente, o a través de herramientas de búsqueda, para identificar el origen de errores de funcionamiento o, también, para obtener métricas. Como puedes imaginar, esta tarea termina convirtiéndose en un proceso lento y tedioso. Vamos a ver cómo agilizarlo.
Herramientas: Fluentd y Graylog
En el mercado hay muchas tecnologías que te permiten trabajar con logs pero nos centraremos en estas dos: Fluentd y Graylog. Ambas soluciones son gratuitas y de código abierto de forma que podréis experimentar con ellas sin ningún problema.
- Fluentd: Es un recolector de datos, es decir, se dedica a buscar y recoger toda la información que generan las diferentes aplicaciones de tu sistema. Su principal característica es la conexión de distintas fuentes de datos con múltiples destinos (desde bases de datos a servicios web, otros ficheros, etc.).
- Graylog: Es una solución de software de código abierto para el almacenamiento y visualización de los logs generados. Permite, además, realizar consultas sobre los datos, crear cuadros de mando, alarmas y muchas otras funcionalidades interesantes en entornos de TI y programación. Se compone de tres componentes fundamentales:
- Mongo DB: Es el almacén de configuraciones y metadatos.
- ElasticSearch: Actúa como motor de búsquedas y almacenamiento.
- Graylog Server: Es el propio servidor de Graylog que incluye todas sus funcionalidades y una interfaz de usuario web (Graylog UI).
Arquitectura para un sistema centralizado de logs
En primer lugar, debemos visualizar la arquitectura que queremos construir. Aunque hay muchas posibilidades, os proponemos esta estructuración para resolver el problema planteado:
Posible arquitectura de un sistema centralizado de logs
Las distintas aplicaciones de la empresa (P1, P2, Pn en el gráfico), como pueden ser servicios Web, aplicaciones de gestión de recursos humanos, de contenidos, extractores de datos propios…, suelen escribir sus logs en sus respectivos ficheros. Aquí es donde entra Fluentd que escaneará y recuperará línea a línea su contenido conforme se produce.
Con Fluentd, no necesitaremos modificar el código de los programas así que evitaremos errores, bloqueos o retardos en su funcionamiento. Las aplicaciones seguirán trabajando con normalidad y conseguiremos acceso a sus logs sin perjudicarlas.
¿Cómo configurar Graylog?
Es conveniente crear, en primer lugar, dos entradas de datos en Graylog. De esta forma, podremos distinguir si la ejecución proviene de un entorno de desarrollo (pruebas e integración) o, directamente, desde producción.
¿Qué tipo de datos envía cada aplicación? Esto dependerá de cada caso y, probablemente, implique implementar algún tipo de lógica o análisis de los logs en Fluentd (programable en lenguaje Ruby). Así extraeremos sólo la información que nos interese del sistema como, por ejemplo, métricas de ejecución o un determinado evento.
Todos estos datos en forma de logs llegarán a Graylog, la pieza central del sistema que nos ofrece:
- Búsquedas en tiempo real: La disponibilidad del dato es casi inmediata, desde que se inserta hasta que se puede consultar
- Almacén de datos: Podemos decidir qué y cuánta información almacenaremos.
- Panel de control: Visualización y gráficos de los datos almacenados.
- Alertas: Sistema de notificación basado en reglas sobre los datos. Por ejemplo, podemos configurar una alerta por email, Slack, Telegram… cada vez que un sistema se reinicie.
- Extractores: Modificación y enriquecimiento de los datos al vuelo.
Una vez puesto en marcha el sistema, veremos llegar los datos en Graylog a través del cuadro de mando principal de la aplicación web o Graylog UI. Aquí tenéis un ejemplo:
Vista principal de mensajes en Graylog
Realmente, la parte más interesante de este tipo de proyecto reside en la presentación al usuario en forma de cuadros de mando y paneles de configuración sencillos. La visualización de los logs facilita el análisis tanto de la actuación del usuario como del sistema en sí mismo.
Graylog ofrece, además, la posibilidad de configurar extractores, alarmas y salidas hacia otros canales de información para todos y cada uno de los eventos recibidos enriqueciendo así el dato.
¿Estás aprovechando tus logs? ¿Conoces otras soluciones de código abierto para crear este tipo de arquitecturas? Déjanos cualquier aportación en la sección de comentarios.
