Inspiration

Resolver una problematica que mantenga la satisfaccion de los clientes y comprender que el sistema se caiga y prentendemos con nuestro sistema evitar esa disgustación

What it does

Analizar datos y identificar los errores reales, basandonos en metricas de la empresa utilizando metodos estadisticos y analiticos

How we built it

Construimos un sistema de alerta temprana para Gracko, un despacho contable de 12 personas. Avisa de problemas de TI antes de que el cliente llame, sin dar falsas alarmas.

  1. Enfoque en una sola empresa. El kit traía 4 empresas. Decidimos enfocarnos solo en Gracko para entenderla a fondo y quitamos los datos de las demás.

  2. Entender qué es "normal". Leímos el contexto.md de Gracko: horario de oficina, respaldo nocturno a las 23:00, carga masiva de declaraciones y cierre de nómina. Así separamos los señuelos (cosas que se ven feas pero son normales) de los incidentes reales.

  3. Reglas basadas en tendencias, no en picos. Los datos tienen ruido, así que trabajamos con promedios móviles y buscamos cosas que suben sin bajar. Creamos 4 reglas:

  4. Disco: entre 60 % y 70 % y creciendo durante 90 minutos seguidos.

  5. CPU: más de 40 % fuera de oficina, del respaldo y de los eventos del negocio.

  6. Ataque VPN (aviso temprano): los errores suben poco a poco mientras CPU, disco y latencia están normales.

  7. Ataque VPN (confirmación): más de 12 intentos fallidos de madrugada en los logs.

  8. Reglas del reto desde el diseño. El detector revisa minuto a minuto y solo usa datos del pasado. Los horarios y eventos se leen de contexto.md, sin fechas fijas en el código, y la solución oficial solo se usó para calificarnos.

  9. Evaluación. Probamos en las 54 corridas del kit y nos calificamos con las 10 que traen solución: 30/30 incidentes detectados, 0 falsas alarmas, con avisos ~49 h antes (disco), ~2 h antes (VPN) y ~14 h antes (CPU).

  10. Alertas útiles para una pyme.

  11. Archivo CSV con el formato del reto (tenant, timestamp, confianza, tipo).

  12. Discord: las alertas llegan al canal del equipo por webhook.

  13. Gemini (nivel gratuito, Flash-Lite): explica cada alerta en 3 oraciones sencillas para el dueño del negocio, terminando con una solución segura. Se llama solo cuando hay alertas, con límites propios de uso y un texto de respaldo sin costo.

Challenges we ran into

  • Muestras al azar vs. tendencias. Al principio pensamos revisar 100 filas al azar, pero así no se ven las tendencias. Lo cambiamos a minutos seguidos.
  • Un señuelo escondido en los logs. Nuestra primera regla de VPN ("entre 9 y 12 intentos fallidos") detectaba a un usuario que olvidó su contraseña y dejaba pasar el ataque real de 212 intentos. Ajustamos la regla a "más de 12".
  • Avisar del ataque VPN a tiempo. Al principio avisábamos 4 minutos tarde. Revisando el firewall, los logs y las métricas, encontramos que los errores empezaban a subir unas 3 horas antes. Con esa pista, el aviso pasó a llegar ~2 horas antes.
  • Demasiadas alertas. El aviso del disco se repetía cada hora durante 47 horas. Implementamos un solo aviso por incidente.
  • Apagones en los datos. En un hueco de 15 minutos, el programa copiaba el último valor de CPU (del respaldo) y daba una falsa alarma. Ahora solo rellenamos huecos de hasta 3 minutos.
  • Fechas fijas en el código. Los eventos del negocio estaban escritos a mano, y los jueces pueden usar otros datos. Hicimos que el detector lea el contexto automáticamente.
  • Riesgo de "aprendernos el examen". Algunos umbrales los ajustamos mirando las corridas de práctica. Por eso mantenemos una regla de respaldo basada en los logs.
  • Costos de la IA. Queríamos usar IA sin pagar. Elegimos el modelo más ligero, apagamos su razonamiento extra (~300 tokens por alerta) y pusimos límites propios. El modelo que pedimos (Gemini 2.5 Flash-Lite) ya no estaba disponible para cuentas nuevas, así que usamos 3.5 Flash-Lite.
  • Consejos peligrosos de la IA. Gemini recomendó "apagar el equipo", lo que habría cancelado el respaldo nocturno. Le pusimos la regla de dar solo soluciones seguras.
  • Problemas del entorno. Python no estaba en el PATH, la red del lugar bloqueaba Discord y había que proteger la clave de Gemini y el webhook para no subirlos a GitHub.
  • Poca experiencia y poco sueño. Aprendimos Python, Git y APIs sobre la marcha, en pocas horas

Accomplishments that we're proud of

estamos orgullosos de poder desarrollar un sistema que pueda tomar datos, analizarlos y buscar patrones con estadisticas para evitar problemas o errores.

What we learned

aprendimos a utilizar las herramientas para poder crear un sistema para notificar errores basados en probabilidades y estadisticas. Aprendimos a usar Gemini api y conectar phyton con discord, junto con agentes de agente de ia(Cloud code).

What's next for V-Alert

Conectarlo con una base de datos junto con los servidores para analizar los datos en tiempo real y modificar el detector de patrones en phyton para que detecte los patrones de las metricas de forma dinamica

Built With

  • claude-code
  • discord
  • gemini-api
  • git/github
  • pandas
  • python-3.13
  • vs-code
  • webhooks
Share this project:

Updates

Submission history