Dashboards

Construí una plataforma de monitorización que desplegamos en tres tipos de cliente: aplicaciones bancarias, infraestructura crítica y aplicaciones de la administración pública. La misma arquitectura base, con dashboards adaptados a lo que de verdad le importaba a cada uno. Al final procesábamos más de 50 millones de eventos diarios con analítica en tiempo real, detección de fallos y predicciones de uso con un 80% de acierto.

El problema

Los tres tipos de cliente compartían el mismo problema: eran reactivos. Los equipos de soporte se enteraban de los problemas por las quejas de los usuarios. Los ingenieros descubrían crashes horas después de que ocurrieran. La planificación de capacidad era puro ojo.

Los clientes bancarios tenían millones de usuarios en su app móvil pero cero visibilidad sobre patrones de fallos. Los equipos de infraestructura monitorizaban sistemas críticos pero no sabían correlacionar métricas con impacto real. Las aplicaciones de la administración servían a ciudadanos en picos (campaña de la renta, plazos administrativos) pero no podían predecir cuándo llegarían los picos de carga.

La arquitectura

Más sencilla de lo que parece. El SDK de Splunk se integraba directamente en las apps cliente (móvil, web, agentes de infraestructura) y enviaba eventos en streaming a Splunk. Sin pipeline de ingesta personalizado. El SDK gestionaba el batching, los reintentos y el encolado offline. Nosotros configurábamos qué capturar y Splunk hacía el resto.

Splunk era el backend entero. Base de datos, motor de consultas, plataforma de ML. Los clientes compraban las licencias; nosotros hacíamos todo lo demás. Manteníamos el data warehouse, optimizábamos queries, montábamos pipelines, configurábamos alertas, entrenábamos modelos. Servicio gestionado completo. Ellos conseguían monitorización enterprise sin contratar un equipo de datos; nosotros ganábamos experiencia profunda en múltiples entornos de producción.

Flask era la capa de aplicación. El backend gestionaba autenticación y control de acceso por roles, actuando como barrera de seguridad entre usuarios y Splunk. Los clientes nunca tocaban Splunk directamente. Cada consulta pasaba por nuestra API, lo que nos permitía aplicar permisos y auditar accesos. El frontend eran templates de Flask.

React se ocupaba de lo dinámico: gráficos animados, actualizaciones en tiempo real y filtros interactivos. Embebíamos componentes React en los templates de Flask en vez de montar una SPA separada. Así el stack se mantenía lo bastante simple para un equipo sin desarrolladores frontend dedicados.

Las predicciones y la detección de anomalías corrían en el ML Toolkit de Splunk. Los modelos vivían junto a los datos. Sin ETL a otra plataforma, sin jobs batch moviendo datos de un sitio a otro. Consultas a Splunk, predicciones de vuelta.

Todo corría en Docker con Compose. Health checks, reinicios automáticos, deploys sin downtime. La plataforma tenía que ser más fiable que los sistemas que monitorizaba.

Dashboards por tipo de cliente

La infraestructura core era la misma, pero los dashboards eran completamente distintos. Cada cliente tenía preguntas diferentes.

Aplicaciones bancarias

A los bancos les importaba la experiencia de usuario y las señales de fraude. Los dashboards mostraban usuarios activos en tiempo real, tasas de crash por versión de app, patrones de transacciones. Soporte tenía una interfaz de clustering de crashes que agrupaba problemas similares por impacto. Los product managers tenían funnels de comportamiento que mostraban dónde abandonaban los usuarios.

El componente de ML predecía usuarios activos diarios con un 80% de acierto aproximado. Suena a métrica de vanidad, pero movía decisiones reales. Cuando el modelo predecía un pico por un featuring en la app store o una campaña de marketing, operaciones pre-escalaba infraestructura. Cuando predecía una caída, aprovechaban para programar mantenimientos.

Infraestructura crítica

Aquí lo clave era la correlación. Cuando la latencia de base de datos se disparaba, ¿qué pasaba aguas abajo? Cuando se desplegaba algo, ¿cambiaban las tasas de error? El dashboard conectaba métricas entre sistemas para dar respuesta a esas preguntas.

Las alertas eran más estrictas. Las apps bancarias podían tolerar unos minutos de degradación. La infraestructura, no. Bajamos los umbrales y añadimos rutas de escalado. ¿Alerta sin reconocer tras 5 minutos? Pasa al backup. ¿Sigue sin respuesta? Aviso a dirección.

Aplicaciones de la administración

Estas tenían un patrón muy marcado: largos períodos de calma seguidos de picos extremos. Plazos fiscales. Períodos de trámites. Anuncios públicos. El dashboard se centraba en predicción de capacidad y distribución geográfica.

Montamos vistas por región porque cada comunidad autónoma tenía su propio calendario. El modelo de predicción aprendía patrones estacionales para que operaciones pidiera capacidad antes de los picos en vez de ir apagando fuegos durante ellos.

Detección y alertas

Las métricas en bruto no sirven de nada. Los equipos no necesitan saber que la tasa de error es del 0,3%. Necesitan saber si eso es normal. Monté reglas de detección en el ML Toolkit de Splunk que aprendían líneas base y alertaban ante desviaciones.

Las alertas por rol costaron trabajo. Soporte necesitaba notificaciones de crash con contexto de usuario. Ingeniería necesitaba stack traces y correlación con deploys. Dirección necesitaba resúmenes, no ruido. Construimos vistas distintas para cada perfil.

Cada alerta incluía contexto. No "pico de crashes detectado" sino "tasa de crash x3 en los últimos 15 minutos, usuarios iOS 17.2, empezó tras el deploy abc123, 847 usuarios afectados." Ese contexto convierte una investigación de 30 minutos en una decisión de 30 segundos.

Resultados

En los tres tipos de cliente:

• 50M+ eventos diarios con rendimiento consistente
• Detección de crashes pasó de horas a menos de 1 minuto
• 70% menos incidencias reportadas por usuarios (las pillábamos antes)
• Resolución 3x más rápida con alertas enriquecidas
• ~80% de acierto en predicciones de uso
• Consultas en menos de un segundo sobre 90 días de datos
• 99.9% de uptime

Los clientes bancarios lo expandieron a toda su suite de productos. Los equipos de infraestructura lo integraron en su flujo de incidentes. Los clientes de la administración usaron las predicciones para justificar presupuesto para capacidad adicional.

Lo que aprendí

Lo técnico era directo. Flask, Splunk, Docker. Lo que lo hizo útil fue entender qué necesitaba ver de verdad cada cliente.

Los ingenieros quieren stack traces. Soporte quiere impacto en usuarios. Dirección quiere tendencias. Los mismos datos, preguntas distintas. Aprendí a empezar los dashboards preguntando "¿qué decisión te ayuda a tomar esto?" en vez de "¿qué datos quieres ver?"

La otra lección fue sobre restricciones. Todos los clientes querían features a medida. Todos tenían presupuesto limitado. La disciplina estaba en dar con el 20% de personalización que entregaba el 80% del valor. Infraestructura común, vistas específicas por cliente. Así es como un equipo pequeño atiende a múltiples clientes.

Las predicciones me enseñaron que la precisión importa menos que la honestidad sobre el grado de confianza. Una predicción del 80% con intervalos claros vale más que una del 90% presentada como certeza. La gente necesita saber cuándo fiarse del modelo y cuándo tirar de criterio propio.