Caso de estudio 12 / 17Visualización de datos
Observabilidad de producción con privacidad por diseño
Consola solo para administradores: 22 KPI de salud con umbrales, sesiones registradas en el servidor y analítica de uso privada.
Stack
- TypeScript
- React
- Next.js
- MongoDB
- InfluxDB
- SVG
- Headless Chrome
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
Una página solo para administradores en el cliente web de la plataforma de monitoreo, en el sitio de producción, que muestra cómo funciona el sistema y cómo lo usan las personas. Salud sigue 22 KPI con umbrales en servicios, flujos de datos, eventos y reinicios; Uso sigue pantallas, abandono y el tiempo entre una alarma y una decisión.
Leer más
La privacidad fue una restricción de diseño: la página responde 404 a quien no sea administrador y muestra nombres solo al superadministrador.
6 conexiones· elige un componente para ver su recorrido
- Cliente web a Verificación de acceso: consulta datos cada 1–4 s
- Verificación de acceso a Sesiones en memoria: registra cada solicitudmodificado
- Sesiones en memoria a Página de salud y uso: sesiones vistas en 2.5 min
- Cliente web a Campos de uso permitidos: eventos de uso por lotes
- Campos de uso permitidos a Almacén de eventos: guarda solo campos listados
- Almacén de eventos a Página de salud y uso: lee de 1 h a 180 d
02Resultados
- R01Cuanto más alto, mejor
Solicitudes de historial atendidas en vista 24 h/7 d (de 11)
Antes 3, después 11, 3.7× mayor. Cuanto más alto, mejor.AntesDespués - R02Cuanto más bajo, mejor
Paneles de uso con etiquetas solapadas o recortadas (de 16)
Antes 9, después 0, a cero. Cuanto más bajo, mejor.AntesDespués - R03Cuanto más bajo, mejor
Tiempo de hilo principal con la página en reposo, cada 30 s
Antes 5.5 s, después 0.19 s, 29× menor. Cuanto más bajo, mejor.AntesDespués
Qué logró
- Registro de sesiones: un latido del navegador que un error podía silenciar → derivado en el servidor de cada petición que la API ya autentica
- Historial de largo plazo: 3 de 11 consultas respondidas → 11 de 11
Leer más
- Paneles de uso: 9 de 16 con etiquetas cortadas → 0 de 16, protegidos por un control automático de maquetación
- Costo en reposo: 5.5 s → 0.19 s de hilo principal cada 30 s
- Una sesión nueva visible para los administradores: a los 60 s → en 1–4 s
El desafío
Una capa de observabilidad debe costar menos y ser más confiable que el sistema que observa. La primera versión no cumplía ninguna de las dos: en reposo, pasaba un sexto de su tiempo en el hilo principal repintando luces de estado, el mapa y cada celda.
Las vistas de largo plazo lanzaban once consultas de historial contra un límite de tasa que dejaba pasar tres, sin reintento.
Leer más
En producción, el conteo de sesiones marcaba cero con una pestaña abierta, porque un solo 404 había silenciado durante una hora el latido del navegador. Los reinicios no dejaban registro, la base de series temporales nunca expiraba datos y más de la mitad de los paneles de uso tenía etiquetas cortadas o superpuestas.
Qué aprendí
Medir lo que cuesta una página de monitoreo antes de agregarle más: la animación en reposo, no los datos, era el gasto principal. La privacidad definió la arquitectura tanto como el rendimiento. El SDK de uso pesa menos de 5 KB y solo encola eventos, así que registrar nunca vuelve a renderizar la página.
Leer más
Descarté una plataforma de analítica autoalojada que exigía cuatro servicios que el servidor no ejecuta, y una analítica alojada que sacaría los datos del sitio. Las etiquetas cortadas tuvieron una solución estructural: un componente único que trunca y un arnés que falla ante cualquier superposición en 54 diseños.
Stack
- TypeScript
- React
- Next.js
- MongoDB
- InfluxDB
- SVG
- Headless Chrome
Habilidades
- Diseño de observabilidad
- Privacidad por diseño
- Presupuestos de rendimiento
- Visualización de datos
- Pruebas visuales automatizadas
