Pitch del Proyecto: FlyXolotl
Inspiración
La idea de FlyXolotl nació de la ambición de conectar el monitoreo tradicional de TI con los datos del mundo real. Queríamos ir más allá de la simple recolección de métricas internas, creando un sistema que:
Sirviera como un receptor centralizado de webhooks (como Zabbix), manejando la lógica de inserción/actualización de alertas críticas.
Correlacionara esos eventos de monitoreo con datos geográficos y meteorológicos en tiempo real (vuelos y clima).
El objetivo fue construir un backend robusto, unificado y persistente (Python/Flask + PostgreSQL) capaz de manejar flujos de datos dispares y convertir el "monitoreo de sistemas" en "monitoreo contextual".
What it does (Qué hace)
FlyXolotl es una aplicación de monitoreo contextual con dos funciones principales:
Rastreo de Vuelos y Correlación Climática: Obtiene datos de aeronaves activas sobre el Valle de México (CDMX) a través de OpenSky Network, y para cada vuelo, consulta Open-Meteo para obtener las condiciones climáticas exactas en su ubicación.
Gestión de Webhooks de Alerta (Zabbix): Actúa como un endpoint (/api/zabbix) para recibir y gestionar alertas de sistemas externos. Persiste estos eventos en PostgreSQL, diferenciando e identificando si un evento es un PROBLEM (nuevo) o RESOLVED (recuperación), manteniendo un registro limpio de las alertas activas.
How we built it (Cómo lo construimos)
El proyecto se construyó utilizando el stack Python/Flask para el backend y PostgreSQL como capa de persistencia de datos, con el ORM Psycopg2.
Estructura de la DB: Se definieron dos tablas clave: vuelos (para datos geográficos, de aeronave, y clima) y alertas (con event_id como clave única para manejar la sincronización de Zabbix).
Conexión de APIs: Se implementaron funciones para llamar a OpenSky Network (filtrando geográficamente por CDMX) y Open-Meteo (obteniendo el clima por latitud/longitud de la aeronave).
Lógica de Webhook: El endpoint /api/zabbix se diseñó para tomar el JSON entrante de Zabbix, extraer campos clave como host, trigger, severity, y event_id. La función guardar_alerta_en_db implementó una lógica condicional para realizar un UPDATE si el estado era RESOLVED, o un INSERT/UPDATE si era un PROBLEM o una actualización de severidad.
Resiliencia: Se añadió una función de fallback (generar_vuelos_falsos) para garantizar que la aplicación siempre devuelva datos simulados si la API de OpenSky falla.
Challenges we ran into (Desafíos que encontramos)
Los desafíos se centraron en la homogeneización y la robustez de la integración:
Fragilidad de la API de OpenSky: Los datos de vuelo se entregan como listas indexadas numéricamente (por ejemplo, longitud es v[5]). Esto requiere una indexación manual y es frágil ante cualquier cambio en el orden de la API externa.
Sincronización de Eventos (Zabbix): Implementar la lógica de "resolución" de alertas en la base de datos fue complejo. Necesitamos asegurar que un evento con estado RESOLVED no se insertara como una nueva entrada, sino que localizara y actualizara la entrada PROBLEM existente basándose en el campo event_id.
Manejo de Tiempos: Tuvimos que crear una lógica robusta para convertir diferentes formatos de timestamp (UNIX de OpenSky, ISO o UNIX de Zabbix) al tipo de dato TIMESTAMP compatible con PostgreSQL sin fallar.
Accomplishments that we're proud of (Logros de los que estamos orgullosos)
Estamos más orgullosos de la integración y correlación de datos de tres sistemas externos (OpenSky, Open-Meteo y Zabbix) en una base de datos unificada.
Además, logramos:
Implementar una persistencia de alertas robusta que maneja correctamente los ciclos de vida de los incidentes (problema, actualización, resolución) en PostgreSQL.
Asegurar la resiliencia de la aplicación mediante la función de graceful degradation que genera datos de vuelo simulados si las APIs de terceros no responden.
What we learned (Lo que aprendimos)
El proyecto solidificó aprendizajes críticos en ingeniería de backend:
Integración de Datos: Dominio en la normalización de datos crudos de APIs con estructuras no estándar (como listas sin claves).
Diseño de DB para Eventos: Uso de la cláusula ON CONFLICT (implícita en la lógica de actualización Python/Psycopg2) y la elección de claves únicas (event_id) para gestionar el ciclo de vida de los eventos de monitoreo.
Manejo de Conexiones: Uso de with conectar_db() as conn: para garantizar la correcta gestión de los recursos de la base de datos (PostgreSQL/Psycopg2).
What's next for FlyXolotl (Próximos pasos para FlyXolotl)
En el futuro, nos gustaría expandir FlyXolotl con las siguientes características:
Visualización de Mapa en Tiempo Real (Frontend): Mostrar los vuelos y las alertas activas superpuestas en un mapa interactivo (usando Leaflet o Google Maps), permitiendo a los usuarios ver geográficamente dónde están ocurriendo los problemas monitoreados.
Notificaciones Proactivas: Integrar una capa de notificaciones (por ejemplo, a través de Telegram o Slack) para el estado de las alertas de Zabbix.
Autenticación de Usuarios: Implementar un sistema de autenticación para proteger el endpoint de Zabbix y permitir solo a usuarios autorizados simular o ver el dashboard de alertas.
Log in or sign up for Devpost to join the conversation.