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, pero dashboards adaptados a lo que realmente 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 tenían el mismo problema: eran reactivos. Los equipos de soporte se enteraban de los problemas por las quejas de usuarios. Los ingenieros descubrían los crashes horas después de que ocurrieran. La planificación de capacidad era pura intuición.

Los clientes bancarios tenían millones de usuarios en su app móvil pero ninguna visibilidad sobre patrones de fallos. Los equipos de infraestructura monitorizaban sistemas críticos pero no podían correlacionar métricas con el impacto real. Las aplicaciones de la administración servían a ciudadanos en períodos pico (campaña de la renta, plazos administrativos) pero no podían predecir 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, la lógica de reintentos y el encolado offline. Nosotros configurábamos qué capturar y Splunk hacía el resto.

Splunk era todo el backend. 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, construíamos pipelines, configurábamos alertas, entrenábamos modelos. Servicio gestionado completo. Ellos obtení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 capa 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 encargaba de las partes dinámicas: gráficos animados, actualizaciones en tiempo real y filtros interactivos. Embebíamos componentes React en los templates de Flask en lugar de construir una SPA separada. Esto mantenía el stack lo suficientemente simple para un equipo sin desarrolladores frontend dedicados.

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

Todo corría en Docker con Compose. Health checks, reinicios automáticos, despliegues 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. Product managers tenían funnels de comportamiento mostrando dónde abandonaban los usuarios.

El componente de ML predecía usuarios activos diarios con aproximadamente un 80% de acierto. Parece una 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 bajada, programaban mantenimientos.

Infraestructura crítica

Aquí lo importante 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 responder esas preguntas.

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

Aplicaciones de la administración

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

Construimos vistas por región porque diferentes comunidades autónomas tenían calendarios distintos. El modelo de predicción aprendía patrones estacionales para que operaciones pudiera solicitar capacidad antes de los picos en lugar de ir apagando fuegos durante ellos.

Detección y alertas

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

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

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 despliegue 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 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 de capacidad adicional.

Lo que aprendí

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

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

La otra lección fue sobre restricciones. Todos los clientes querían features personalizadas. Todos tenían presupuesto limitado. La disciplina estaba en encontrar 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 sirve a múltiples clientes.

Las predicciones me enseñaron que la precisión importa menos que la honestidad sobre la 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 confiar en el modelo y cuándo usar su criterio.