Subscribe
Share
Share
Embed
Real-Time Dashboard pone un botón de alerta en cada tile y confirma el guardado cada vez. Recorremos cómo funciona realmente la capa de monitoreo nativa de Kusto, cómo su modelo de permisos separa ver de consultar, y dónde el pipeline de alertas deja de evaluar en silencio.
Episode 19 • 2026-05-08 Duration: 11:14
Real-Time Dashboard pone un botón de alerta en cada tile y confirma el guardado cada vez. Rastreamos cómo la superficie de monitoreo nativa de Kusto realmente consulta, cómo su modelo de permisos separa ver de consultar, y dónde el pipeline de alertas deja de evaluar en silencio.
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
Este podcast fue generado por inteligencia artificial. Ambas voces son sintéticas: la de Matthias es una voz clonada y Fabia es una co-presentadora de IA.
Brand design based on fabricperiodictable.com.
Decisiones de arquitectura para Microsoft Fabric. Escenarios reales anonimizados, realismo de costos, contraargumentos incluidos. Episodios semanales alineados con las grabaciones de Fabric Friday. Generado por inteligencia artificial.
La alerta que se guardó sin problemas
Episode 19 | 2026-05-08
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Matthias: En Fabric hay tres cosas que hacen de dashboard. Solo una refresca cada diez segundos.
[00:13] Fabia: Y esa pone un botón de alerta en cada tile.
[00:16] Matthias: Entonces uno pensaría que las alertas simplemente funcionan.
[00:20] Fabia: Hoy desarmamos Real-Time Dashboard — la superficie de monitoreo nativa de Kusto que por fuera parece Power BI y por dentro se comporta como un producto completamente distinto. Cómo consulta realmente, cómo su modelo de permisos separa ver de consultar, y dónde la historia de alertas se desmorona en silencio.
[00:41] Fabia: Un tile de Real-Time Dashboard es una consulta KQL conectada a un visual. Sin Semantic Model, sin DAX, sin capa de Power Query entre tú y los datos. Escribes KQL, el motor Kusto la ejecuta contra tu Eventhouse o KQL Database, y el resultado se renderiza. Cada tile es independiente — cada uno golpea la base de datos en su propio ciclo de refresco.
[01:04] Matthias: O sea, no hay caché de modelo que te ayude. Cada tile es una consulta en vivo.
[01:09] Fabia: Y ya ni siquiera es polling a intervalo fijo. El refresco en vivo observa la marca de agua de ingesta y solo re-consulta un tile cuando llegan datos nuevos. El editor configura un límite de frecuencia de refresco — un piso para que una avalancha de ingesta no dispare una tormenta de queries — más un intervalo de respaldo para tiles que no pueden detectar la ingesta directamente. Los espectadores pueden pausarlo o reanudarlo, pero no ajustan la granularidad ellos mismos.
[01:41] Matthias: Suena rápido hasta que estás en una planta industrial.
[01:44] Fabia: Así es. Para bucles de control genuinamente sub-segundo — sistemas autónomos, trading de alta frecuencia — irías directo a la API de queries KQL o leerías desde un endpoint de Eventstream. Pero la pregunta honesta es si un humano realmente actúa sobre señales sub-segundo. Si el tiempo de reacción de alguien se mide en segundos de todos modos, recortar la latencia de detección no cambia el resultado. Optimiza la velocidad de acción de la alerta, no el mecanismo de refresco.
[02:16] Matthias: La parte que sigue tomando a la gente desprevenida es el modelo de permisos. Todo el mundo asume que compartir un dashboard significa compartir acceso a la base de datos.
[02:28] Fabia: Dos modos. Identidad pass-through — el espectador se autentica contra la KQL Database. Sin acceso, sin datos, el tile muestra error. Ese es el predeterminado, coincide con lo que la gente de Power BI espera. Pero el segundo modo es el que sorprende a los arquitectos. Identidad del editor del dashboard. El editor registra una cloud connection OAuth, y el dashboard consulta usando esa credencial para todos los espectadores. Cualquiera con acceso de vista ve los datos, incluso sin permisos en la KQL Database.
[03:02] Matthias: Ese es exactamente el caso del dashboard ejecutivo. La dirección observa el panorama operativo sin que nadie les dé acceso de consulta a los datos de producción.
[03:13] Fabia: O portales de clientes. Dashboards de proveedores. Cualquier audiencia que deba ver la vista de monitoreo sin ejecutar KQL arbitrario.
[03:22] Matthias: Y entonces nadie documenta quién es dueño de la cloud connection, y —
[03:26] Fabia: Noventa días. Eso es lo que sobrevive una cloud connection sin uso. Una mañana, todos los espectadores de ese dashboard ejecutivo ven errores, y quien esté de guardia pierde una hora descubriendo que una conexión que nadie recuerda haber creado expiró. Sin advertencia documentada, sin periodo de gracia documentado. Anota quién es dueño de la conexión y pon tu propio recordatorio — la plataforma no lo hará. Solo tiles que dejan de cargar.
[03:56] Fabia: Un oyente nos escribió con algo que encaja justo aquí. 'Configuré una regla de Activator desde un tile de Real-Time Dashboard. Se guardó con éxito. La condición se está cumpliendo en los datos — puedo ver el pico en el dashboard. Pero la alerta nunca se dispara. ¿Qué me estoy perdiendo?'
[04:16] Matthias: Me topo con este patrón una y otra vez. El dashboard se ve perfecto. El pico está ahí en el tile. La alerta se guardó sin quejarse. Y simplemente... no existe.
[04:26] Fabia: Porque el guardado fue exitoso. Eso es lo que lo hace peligroso. Activator te deja crear la regla, la confirma, la almacena — y nunca la evalúa. Sin advertencia, sin estado de error, sin indicación de que algo anda mal.
[04:41] Matthias: Espera — ¿guarda una regla que sabe que no puede evaluar?
[04:45] Fabia: La guarda. La brecha de validación es real. Causa más común: el tipo de tile. Activator solo evalúa ocho tipos de visual — los gráficos estándar más stat y multi stat. Si construiste un tile de mapa o una tabla, la regla se guarda y nunca se dispara. En silencio.
[05:02] Matthias: Fallo silencioso en una herramienta de monitoreo.
[05:06] Fabia: Y luego viene el caso traicionero — make-series en la consulta. Es una limitación explícita y documentada: Activator no evalúa tiles construidos sobre la salida de make-series. Se guarda sin problema, nunca se dispara, sin error. La solución es reescribir con summarize y bin — mismo resultado visual en pantalla, diferente forma de datos por debajo, y ahora el evaluador sí puede disparar.
[05:32] Matthias: Mismo gráfico. Diferente query. Comportamiento de alertas completamente distinto.
[05:37] Fabia: Después están los rangos de tiempo personalizados — Activator solo soporta las opciones predefinidas. Una ventana personalizada se guarda sin problema, nunca se dispara. Lo mismo con los destinatarios. Las direcciones de correo externas o de invitados fallan en silencio — solo funcionan direcciones internas del tenant de Entra. Y por encima de diez mil eventos por segundo en una sola regla, Activator la mata directamente.
[06:05] Matthias: Esto es lo que yo le diría a un equipo que arranca su primer Real-Time Dashboard. Empiecen con tiles de tipo Stat para sus KPIs. Son compatibles con alertas por defecto, no hay trampa de make-series esperándoles, y son el tipo de tile más legible en una pared de NOC a cinco metros de distancia. Confirmen que el pipeline de alertas funciona antes de tocar tiles de mapa o visuales elaborados. El dashboard más bonito del mundo no sirve de nada si la alerta que debería despertar a alguien a las tres de la mañana nunca se dispara.
[06:41] Fabia: Sobre el costo — Real-Time Dashboard requiere capacidad de Fabric. Un F-SKU. Las licencias Pro solas no cubren. Y si quieres que Copilot genere tiles a partir de lenguaje natural, eso necesita F2 o superior en un SKU de pago. Los SKU de prueba no aplican. Para equipos fuera de EE.UU. y la UE, el administrador del tenant también necesita activar la opción de procesamiento cross-region de Azure OpenAI, o Copilot simplemente no aparece en el editor de tiles.
[07:12] Matthias: Entonces la ruta de evaluación ya está rota antes de empezar. Levantas una prueba, Real-Time Dashboard funciona de maravilla. Pruebas Copilot — no aparece nada. Asumes que es un bug. Es una restricción de SKU que nadie te mostró.
[07:27] Fabia: Y el costo de capacidad se acumula, pero solo en el escenario que realmente te muerde — la ruta de respaldo. Si un tile no puede detectar la ingesta y cae a un intervalo fijo, veinte tiles con un respaldo de diez segundos son dos queries por segundo, sostenidas. Con Live refresh normal, los tiles solo consultan cuando llegan datos nuevos — los periodos tranquilos casi no te cuestan nada. Configura el intervalo de respaldo y el límite de frecuencia de refresco de forma conservadora, y deja que Live refresh haga el trabajo de ahorro para el que fue diseñado.
[08:05] Fabia: Y hay que ser honestos con el alcance. Real-Time Dashboard no puede leer tablas Delta de Lakehouse — para eso está Power BI con Direct Lake. Si necesitas medidas DAX o seguridad a nivel de fila, eso es Power BI Report. PDFs imprimibles, layouts optimizados para móvil — Power BI otra vez. Real-Time Dashboard hace una sola cosa: monitoreo operativo sobre datos respaldados por Kusto con refresco rápido.
[08:32] Matthias: La prueba que yo uso es una sola pregunta. Si alguien pregunta '¿qué está pasando ahora mismo?', es Real-Time Dashboard. Si pregunta '¿qué pasó el trimestre pasado?', es Power BI. Y en la práctica, la mayoría de las organizaciones terminan usando los dos en paralelo. La misma KQL Database alimenta un Real-Time Dashboard para el equipo de operaciones y un reporte Power BI vía DirectQuery para los analistas. Reparten el trabajo. La colisión de nombres solo hace que la gente piense que compiten.
[09:05] Fabia: Y el equipo que intenta forzar una herramienta en el trabajo de la otra pierde más tiempo que el equipo que mantiene dos dashboards.
[09:14] Fabia: El riesgo que no va a aparecer en ningún demo es la expiración de cloud connections a los noventa días. Pon un recordatorio en el calendario a los sesenta días desde que creas esa conexión. El patrón dicta la plataforma — y esta plataforma exige un calendario de mantenimiento que no aparece en ninguna lista de funcionalidades.
[09:36] Matthias: La lección más grande aquí va más allá de este dashboard. El éxito silencioso es peor que el fallo ruidoso. Una regla que se guarda y nunca se evalúa. Una cloud connection que muere sin notificación. Un botón de Copilot que simplemente no está. Cada uno de esos es un equipo perdiendo medio día en algo que debería haber sido un banner rojo en el diálogo de guardado.
[10:01] Fabia: En este momento, en algún lugar, hay un dashboard con un pico claro en pantalla y una regla de Activator guardada debajo — confirmada, almacenada, sin hacer absolutamente nada.
[10:12] Matthias: Y alguien durmiendo tranquilamente.
[10:15] Fabia: Si te has topado con alguno de esos fallos silenciosos, o encontraste un workaround que no cubrimos —
[10:21] Matthias: Escríbeme por DM en LinkedIn — búscame como Matthias Falland.
---
End of episode. ~10:25 estimated.