GalaeciaMetrics

En cuanto a por qué escogimos Grafana, la posibilidad de haber probado esta herramienta en una asignatura cursada en la carrera, aunque levemente, nos animó a intentarlo y a aprender más sobre esta. Aunque diéramos únicamente monitorización de servidores/ordenadores, el hecho de poder expandirlo a cualquier tipo de datasource, nos dio una clara indicación de que debíamos intentar este desafío. Si hablamos de la temática de la aplicación/dashboard, nuestro gran interés por los deportes nos empujan inevitablemente a intentar relacionarlo con el reto, buscando así una solución a hacer actividades al aire libre en Galicia.

Tras dedicar las primeras horas a un brainstorming de ideas en grupo para escoger cuál se adaptaría mejor a los requisitos del reto, decidimos optar por un enfoque más atlético. Dar solución a la problemática que encuentran deportistas que intentan salir al aire libre sin conocer de antemano cuáles son las condiciones atmosféricas. Debido a que queríamos datos de calidad y no directamente parsear de las fuentes de datos de origen, optamos por una arquitectura de backend siguiendo un patrón MVC (Modelo Vista Controlador) para cargar datos crudos en una base de datos y procesarlos. Dividimos la estructura en contenedores Docker por responsabilidad, un contenedor para la base de datos, uno para los ingestores que poblaban la BD y procesan los datos, el contenedor de Grafana y otro finalmente para el servidor web donde se muestra la página. Una vez que cargamos datos en la BD, comenzamos a implementar nuevas funcionalidades en nuestro dashboard, así como la integración de alertas a través de Discord. Finalmente, montamos un mock de lo que podrá ser en un futuro una página web que utilice este dashboard para mostrar información al usuario final.

El primer paso siempre es el más complejo, desde escoger la idea hasta escribir la primera línea de código. Sin duda uno de los mayores obstáculos que encontramos ha sido la integración de diferentes data sources de distintas API, en las que cada una tenía una estructura concreta que primero teníamos que estudiar para saber qué datos sacar. Esto, sumando a que construimos una estructura backend de preprocesamiento de los datos que obtenemos de las API para luego poder cargarlos al dashboard de grafana y de la app, ha formado la mayor dificultad del reto que hicimos.

Estamos orgullosos de haber participado en el HackUDC y realizar un proyecto que de normal nos llevaría varias semanas o por lo menos más de dos días. Por otra parte, destacar que pese a creer en ocasiones que no ibamos a dar cumplido con la fecha de entrega, logramos salir adelante centrándonos en las funcionalidades principales. También estamos contentos con como hemos trabajado en equipo y como hemos ido repartiendo tareas y ayudado entre nosotros.

Aprendimos a crear dashboards más complejos y a darle un significado a datos que por si solos, probablemente no nos darían mucha información, por otra parte también hemos reforzado nuestros conocimientos sobre Docker, PostgreSQL y sistemas de alerting, que ya habiamos tocado por ejemplo con AWS.

Las vías de expansión del proyectos son enormes, debido a que pese a ver conseguido grandes avances, todavía faltan muchos deportes a tener en cuenta e incluso nuevas funcionalidades, aquí nombramos unas cuantas:

IAD Acuático: Integrar boyas de Puertos del Estado y modelos de oleaje para crear un algoritmo de "Aptitud para el Surf" analizando periodo de ola y mareas.
Integración CAP de AEMET: Cortar directamente el IAD a 0 y mandar alarmas "Push" si hay alertas oficiales Naranjas/Rojas por temporales.
Mejorar la aplicación web que hemos creado que utilizamos para complementar los dashboards que nos proporciona Grafana, ya que esta versión de la aplicación todavía es un boceto, pese a que visualmente no lo parezca, en cuanto a funciones todavía tiene mucho que aportar.
Bot Conversacional: Permitir a los usuarios preguntar a un Bot de Telegram "¿Es seguro salir en bici hoy por Vigo?" y que este lea de forma natural nuestra TimescaleDB.