Monitorizar actividades en Microsoft Fabric

¿Qué te enseña este módulo?

Este módulo cubre cómo monitorizar, alertar y optimizar en Fabric — el Dominio 3 completo (30-35% del examen). Los objetivos oficiales:

1. Aplicar conceptos de monitorización a Microsoft Fabric.
2. Usar el Monitoring Hub en Microsoft Fabric.
3. Disparar acciones usando Activator en Microsoft Fabric.
4. Resolver fallos comunes.
5. Optimizar el rendimiento de los items y de la capacidad.

Peso en el examen DP-700

Este módulo cubre todo el Dominio 3 (30-35%):

Definición

Monitoring = ganar visibilidad sobre la salud de tus sistemas de datos. El monitoring de Fabric te permite:

• Seguir los jobs en ejecución y completados.
• Investigar fallos.
• Comparar el rendimiento a lo largo del tiempo.
• Configurar alertas para incidencias.
• Optimizar el uso de recursos.

Los pilares del monitoring en Fabric

1. Monitoring Hub — actividades entre workspaces.
2. Activator — alertas y acciones ante patrones o condiciones.
3. Capacity Metrics app — consumo de CU y throttling.
4. Admin monitoring workspace — gobernanza y analítica de uso.
5. Monitorización específica por item — Spark UI, historial de queries del warehouse, insights del Eventhouse.
6. Purview Audit — activity logs (visto en el Módulo 16).

¿Qué preguntas responde el monitoring?

1. ¿Cuál es el estado actual de un job — running, succeeded, failed?
2. ¿Dónde ha fallado y qué detalles de error hay disponibles?
3. ¿Ha fallado este job antes en los últimos 30 días?
4. ¿Qué items programados tienen notificaciones de fallo configuradas?
5. ¿Estoy excediendo mi capacidad?
6. ¿Está ocurriendo throttling?
7. ¿Qué usuarios consumen más recursos?

¿Qué es?

La feature Fabric Monitor abre el Monitoring Hub: una vista centralizada de la salud, el progreso y los resultados de la ejecución de los jobs. Permite identificar problemas rápidamente y actuar desde un solo sitio.

Cómo abrirlo

En el panel de navegación → seleccionar Monitor.

Las 2 páginas principales

A) Activities 📋 — seguir los jobs activos y recién completados entre workspaces. Muestra hasta 100 actividades de Fabric de los últimos 30 días, ordenadas por hora de inicio (las más recientes primero). La tabla muestra hasta 100 actividades por item de Fabric.

B) Schedule failures (Preview) ⚠️ — ver y gestionar las notificaciones de fallo de los items programados. Ubicación central para toda la gestión de fallos.

Key features

1. Estado del run actual — jobs activos y recién completados.
2. Historical runs — investigar fallos, comparar rendimiento, validar reruns.
3. Detalles y diagnóstico de la actividad — estado, tiempos, detalles de error.
4. Filtrado y búsqueda de actividades — acotar resultados.
5. Notificaciones de fallo de schedule — gestión centralizada.

Acciones desde el hub

Si tienes los permisos apropiados sobre un item de Fabric, puedes realizar acciones directamente desde el Monitoring Hub. Las acciones disponibles dependen del tipo de item: pipelines (rerun, cancel), notebooks (ver detalles, snapshot), semantic models (refresh, cancelar refresh), etc.

Lista completa

La página Activities muestra actividades para estos items de Fabric:

1. Copy Job
2. Dataflow Gen2
3. Dataflow Gen2 CI/CD
4. Datamart
5. Data Build Tool (dbt) Job
6. Digital Twin Builder Flow
7. Experiment (experimentos de ML)
8. Graph model
9. Lakehouse
10. Map
11. Notebook
12. Pipeline
13. Semantic model
14. Snowflake database
15. Spark job definition
16. User data function

Item types aún NO soportados

• Dataflow Gen1 (legacy).
• Eventstreams (usan su propia monitorización).
• KQL queries (usan su propia monitorización en el Eventhouse).
• Reports (usan usage metrics).

Estructura

La página principal de Activities tiene una tabla con las actividades, filtros arriba, una búsqueda por palabra clave, opciones de columna para personalizar y un panel de detalles al seleccionar una actividad.

Ver los detalles de una actividad

Para abrir el panel de detalles: apunta al nombre de la actividad y selecciona el símbolo View details (ⓘ).

El panel muestra el estado, la hora de inicio, la duración, los detalles del error (si ha fallado), la información del item, quién lo envió y la ubicación (workspace).

Estados

Cada item de Fabric tiene su propio conjunto de operaciones y estados. Para mostrar resultados consistentes, el Monitoring Hub puede mostrar una versión simplificada del estado. El estado exacto del item está en el panel de detalles.

Estados comunes: Succeeded ✅, Failed ❌, In Progress 🔄, Queued ⏸️, Cancelled 🚫 y Stopped ⏹️ (para notebook interactive runs terminados).

Cambiar columnas

Puedes personalizar las columnas con Column Options: añadir/quitar columnas, reordenarlas arrastrando y ordenar haciendo click en la cabecera (la flecha indica el orden).

Columnas típicas: nombre del item, tipo de item, estado, hora de inicio, duración, quién lo envió, ubicación (workspace) e intento de reintento.

Limitación de la vista principal

La página principal de Activities muestra solo las 100 actividades más recientes de los últimos 30 días. Los jobs que se ejecutan con frecuencia pueden no mostrar todas sus ejecuciones en la vista principal.

Historical runs

Para ver el historial completo de 30 días de una actividad concreta:

1. Apuntar al nombre de la actividad.
2. Seleccionar More options (...).
3. Seleccionar Historical runs.

La tabla muestra hasta 30 días de información histórica de esa actividad. Con Back to main view vuelves a la vista principal.

Uso típico

• Depurar: ver si un job siempre falla o solo a veces.
• Análisis de tendencias: ¿el job tarda cada vez más?
• Validar reruns: verificar que los reruns funcionan tras un fix.
• Comparar duraciones: identificar regresiones de rendimiento.

Búsqueda por palabra clave

La caja Filter by keyword encuentra actividades o items por nombre o palabra clave. La búsqueda consulta solo los datos ya cargados, no todas las actividades de la base de datos.

Opciones de filtro

El filtro acota los resultados por propiedades:

1. Status — seleccionar el tipo de estado a mostrar. Ojo: cada item tiene estados únicos; el hub puede mostrarlos simplificados.
2. Item type — seleccionar los tipos de item de Fabric a mostrar. Se pueden seleccionar varios.
3. Start time — periodo predeterminado, o Customize para un rango custom. Opciones: última hora, últimas 24 horas, últimos 7 días, últimos 30 días, etc.
4. Submitted by — seleccionar el propietario del item de Fabric. Filtrar por usuario o grupo.
5. Location — seleccionar de qué workspaces ver actividades. Filtrado multi-workspace.

Ejemplo del examen

Escenario: quiero ver los jobs fallidos del workspace Production de las últimas 24 horas.

Filtro: Status = Failed, Location = Production, Start time = Last 24 hours. La tabla muestra solo esos jobs → click en cada uno para ver los detalles.

Feature

La página Schedule failures (Preview) del Monitoring Hub permite ver y gestionar las notificaciones de fallo de los items programados.

Cómo configurarlas

Opción A: desde la página Schedule failures — ir a Schedule failures, seleccionar el item y configurar los destinatarios.

Opción B: desde el panel de job scheduler del item — abrir el item, ir a los settings de Schedule y configurar las notificaciones.

Permisos

Visibilidad: puedes ver las notificaciones de fallo de cualquier item programado sobre el que tengas permiso de vista.

Edición: configurar nuevas notificaciones, editar destinatarios o eliminar notificaciones requiere al menos el rol Contributor en el workspace, o el permiso Write sobre el item.

Contenido de la notificación

El email de fallo incluye el nombre del item, los detalles del fallo, el timestamp y un enlace al Monitoring Hub para investigar.

Editar / eliminar

Edit recipients para cambiar la lista. Remove notifications para ese item si quieres dejar de recibirlas.

Definición

Fabric Activator = experiencia no-code y sin scripting que permite tomar acciones automáticas cuando se detectan patrones o condiciones en los datos (streaming o batch).

Uso típico

• Enviar emails de alerta cuando la temperatura de un congelador supera un umbral.
• Disparar un pipeline cuando llegan datos nuevos de ventas.
• Publicar un mensaje en Teams cuando un sensor detecta un fallo.
• Llamar a un flow de Power Automate para automatizaciones complejas.

Fuentes de datos

Activator puede monitorizar:

1. Eventstreams — datos de streaming en tiempo real.
2. KQL Querysets — queries KQL programadas en el Eventhouse.
3. Real-Time Dashboards — visualizaciones de datos KQL.
4. Queries SQL de Fabric Data Warehouse (preview) — queries SQL programadas.
5. Reports de Power BI (vía alertas en los visuals).

Acciones posibles

Cuando se cumple la condición: notificación por email, mensaje de Microsoft Teams (individuos, chat de grupo, canal), ejecutar actividades de Fabric (pipeline, dataflow, notebook, User Data Function, copy job), publicar un business event (preview) o una acción custom (flow de Power Automate).

Qué construye Activator

Activator crea inteligencia reactiva en tus data pipelines: sin scripting, sin montar infraestructura, totalmente gestionado y serverless — pagas por lo que usas vía consumo de CU.

Los 3 conceptos core

Activator gira en torno a 3 conceptos: Objects 📦, Rules 📏 y Actions 🎯.

Objects

Los business objects son las entidades que monitorizas. Pueden ser físicas (congeladores, vehículos, paquetes, usuarios) o conceptuales (campañas de publicidad, cuentas de cliente, sesiones de usuario).

Object instances

• Object = la definición general (ej: "freezer" como tipo).
• Object instance = un ejemplo concreto (ej: freezer FR-001, freezer FR-002).
• Population = el conjunto completo de instancias monitorizadas.

Cómo modela los objects Activator

Para modelar un business object:

1. Conectar uno o varios eventstreams.
2. Seleccionar una columna que actúe como object ID (la primary key de la entidad).
3. Especificar los campos que quieres tratar como propiedades del object.

La creación del object es implícita — Activator agrupa los eventos usando la object key designada. Las rules están acotadas a los objects: toda la lógica de evaluación es object-aware e independiente entre instancias.

Ejemplo: una rule que monitoriza bikepoint_id crea evaluaciones lógicas distintas para cada estación de bicis única.

Rules

Las rules definen las condiciones a detectar en tus objects y las acciones a tomar cuando se cumplen.

Ejemplo: una rule sobre el object freezer podría detectar cuándo la temperatura sube por encima del umbral seguro y enviar automáticamente un email de alerta al técnico asignado.

Los 2 tipos

A) Stateless rules 🎯 — evalúan cada evento de forma aislada, sin memoria de eventos anteriores. Ejemplo: value < 50.

B) Stateful rules 🧠 — mantienen memoria entre eventos por object y son conscientes del contexto temporal. Ejemplo: value DECREASES, value BECOMES, EXIT RANGE.

La evaluación stateful depende de 3 cosas

1. Delta detection — sigue los cambios entre el valor del evento anterior y el actual. Detecta "cuándo el valor pasó a ser", "cuándo el valor cayó".

2. Temporal sequencing — evalúa condiciones basadas en el tiempo, como la ausencia de eventos. Detección de heartbeat: "si no hay señal en 5 minutos → alerta".

3. State transitions — las rules solo se disparan al ENTRAR en un nuevo estado. Evita disparos repetidos en condiciones que no cambian. Ejemplo: la alerta de temperatura > 30 se dispara UNA vez, no en cada evento por encima de 30.

Comparativa

SQL query rules (preview)

Además del streaming, Activator soporta rules basadas en los resultados de queries SQL de Fabric Data Warehouse (preview). Puedes definir rules que evalúen una query SQL con una frecuencia configurable, comprobar condiciones contra el result set y disparar acciones cuando se cumplan.

Beneficio: monitorizar datos del warehouse sin necesitar fuentes de streaming.

Los 2 escenarios

Puedes configurar Activator para disparar notificaciones basadas en los resultados de un KQL Queryset en 2 escenarios:

1. Cuando las queries KQL programadas devuelven resultados.
2. Cuando las queries KQL programadas devuelven resultados con visualizaciones que cumplen condiciones específicas.

Escenarios de ejemplo

Monitorizar logs de aplicación en busca de errores: una KQL database que almacena los logs de aplicación, con una alerta si los registros de los últimos 5 minutos contienen authorization error en la columna message.

Seguir las bicicletas disponibles: datos en streaming de bicicletas disponibles por barrio, una query KQL que renderiza un gráfico de tarta con los barrios, y una alerta cuando el número de bicicletas de cualquier barrio cae por debajo de un umbral.

Setup: panel lateral Add Rule

1. Sección Details — introducir el nombre de la rule.

2. Sección Monitor — frecuencia temporal con la que se ejecuta la query (por defecto 5 minutos).

3. Sección Condition — especificar las condiciones de la alerta:

• On each event when — visualización sin dimensiones.
• Desplegable When — el valor a evaluar.
• Desplegable Condition — la condición a evaluar.
• Occurrence — cuántas veces debe cumplirse la condición antes de disparar.

4. Sección Action — elegir la acción (email, Teams, actividades de Fabric, custom).

5. Save location — dónde guardar la alerta. En un workspace existente, dentro de un activator existente o uno nuevo.

6. Create — la rule se crea y aparece en el panel Rules del KQL Queryset.

Feature

Poner una alerta en un Real-Time Dashboard usando el panel lateral no-code de Fabric Activator. Permite monitorizar tendencias de datos en vivo poniendo condiciones sobre las visualizaciones.

Pasos

1. En el Real-Time Dashboard, seleccionar el menú More [...] del tile deseado.
2. Set an alert.
3. Definir las condiciones de la alerta y crearla.
4. Opcionalmente, modificar después las condiciones y acciones en Activator.

Uso típico

Ejemplo: visualizar la distribución de ventas entre categorías de producto en un gráfico de tarta y poner una alerta si la cuota de cualquier categoría cae por debajo de cierto umbral. Ayuda a identificar y atender rápidamente los problemas de esa línea de producto.

Feature preview

Novedad (preview): Activator soporta rules basadas en los resultados de queries SQL de Fabric Data Warehouse.

Cómo funciona

Defines rules que evalúan una query SQL con una frecuencia configurable, comprueban condiciones contra el result set y disparan acciones cuando se cumplen.

Beneficio

Monitorizar datos del warehouse sin necesitar fuentes de streaming. Perfecto para datos orientados a batch que quieres vigilar.

Uso típico

• Comprobación de row count: alerta si la tabla de ventas diarias tiene menos de X filas.
• Calidad de datos: alerta si el número de nulos en una columna crítica supera un umbral.
• Métrica de negocio: alerta si el revenue del mes en curso cae por debajo del objetivo.
• Detección de anomalías: alerta ante patrones inusuales detectados por analítica SQL.

Setup

Similar al KQL Queryset: definir la query SQL, la frecuencia de ejecución, las condiciones sobre el resultado y las acciones (email, Teams, etc.).

Las 4 categorías de acciones que Activator puede disparar.

Enviar notificación por email

Configuración:

• To: dirección de email del receptor, o una propiedad dinámica (@BikepointID_email).
• Subject: asunto del email.
• Headline: titular del email.
• Notes: cuerpo de las notas.
• Context: valores de los datos a incluir.

Referencias a los datos: escribe @ para autocompletar las propiedades.

Enviar notificación de Microsoft Teams

3 sub-opciones:

• A) Mensaje a individuos — introducir las direcciones de email o una propiedad dinámica. El mensaje de Teams se envía a esas personas.
• B) Mensaje a un chat de grupo — seleccionar el chat en el desplegable. El mensaje se publica en el chat.
• C) Publicación en un canal — seleccionar el equipo y el canal en los desplegables. El mensaje se publica en el canal.

Configuración común: Headline, Notes y Context, igual que en el email.

Ejecutar actividades de Fabric

Disparar items de Fabric cuando se cumpla la condición. Items soportados: Pipeline, Dataflow, Spark job, Notebook, User Data Function, Copy job y Publish business event (preview).

Setup: seleccionar el tipo de item de Fabric, seleccionar el item a ejecutar de la lista y añadir parámetros (nombre y valor). Puedes pasar parámetros desde los datos de la alerta usando @.

Acciones custom (flows de Power Automate)

Disparar un flow custom de Power Automate cuando se cumpla la condición:

1. Seleccionar Create custom action.
2. Crear primero la rule.
3. Completar el setup de la acción custom siguiendo los pasos oficiales de Trigger custom actions (Power Automate flows).
4. Tras crear la acción custom, en el panel Definition de la rule, seleccionar la acción custom en el desplegable de acciones.

Uso: workflows complejos, integraciones con sistemas de terceros y lógica de negocio.

Gestión desde el panel Rules

Tras crear una rule, el panel Rules muestra la lista de rules. Puedes:

1. Botón toggle para arrancar/parar la rule. Una rule parada no se ejecuta y no envía alertas. Al testear, párala tras ver alertas de muestra para no recibir demasiadas.
2. Opciones (...): Edit (modificar la rule sin salir de la página), Delete (eliminarla del item de Fabric y del activator) y View in Activator (abrirla en Activator para ver el historial y las alertas disparadas).
3. Add rule — añadir otra rule al item de Fabric y al Activator.

Feature

Puedes configurar notificaciones para los fallos de refresh de un semantic model desde los settings del propio semantic model. Es distinto de la página Schedule failures — los semantic models tienen su propio mecanismo.

Setup

En los settings del semantic model:

1. Sección Scheduled refresh.
2. Email notifications.
3. Elegir destinatarios y condiciones: al fallar o cuando el refresh tarda más de lo esperado.

Uso típico

• Propietarios del dataset notificados de refreshes fallidos.
• Data engineers al tanto de refreshes lentos.
• Managers al tanto de fallos críticos de negocio.

Combinar con Activator

Para un setup más avanzado puedes registrar los resultados de los refreshes en una KQL DB y crear una alerta en Activator sobre patrones (ej: 3 fallos en 24 h → email de escalado).

¿Qué es?

Workspace monitoring = feature para monitorizar todas las actividades dentro de un workspace concreto. Es distinto del Monitoring Hub global: el Monitoring Hub es cross-workspace y centrado en actividades; el workspace monitoring está acotado al workspace y centrado en los recursos.

Configuración

Se habilita en los settings del workspace: sección Workspace monitoring → Enable monitoring.

Al habilitarse, Fabric crea una base de datos de monitorización (un Eventhouse por detrás) y registra eventos de actividad de Fabric, eventos de items y métricas de rendimiento.

Beneficios

• Telemetría detallada del workspace.
• Queries KQL sobre los datos para investigaciones custom.
• Dashboards custom sobre la actividad del workspace.
• Retención larga (configurable, generalmente > 30 días).

Uso típico

Auditoría específica del workspace, troubleshooting granular de rendimiento, analítica de uso del workspace y dashboards de monitorización custom para stakeholders.

¿Qué es la Capacity Metrics app?

La Microsoft Fabric Capacity Metrics app es la app oficial que provee visibilidad completa del consumo de CU, los eventos de throttling, el desglose de uso por item y los insights de uso por usuario.

Instalación

El Fabric admin la instala desde AppSource o el admin portal. Una vez instalada, está disponible para los usuarios con permisos de capacity admin.

Fundamentos de las Capacity Units (CU)

Una Capacity Unit (CU) es la medida de potencia de cómputo disponible en cada SKU. Fabric mide el consumo en CUs: cada operación de Fabric consume algunas CUs, distintas operaciones tienen distintos costes, y se agregan en CU segundos para la facturación y el throttling.

Timepoints y CU-seconds

Fabric evalúa la capacidad en timepoints de 30 segundos. En cada timepoint, el cómputo disponible es CUs del SKU × 30 segundos.

Ejemplo: F8 tiene 8 CUs. Por timepoint: 8 × 30 = 240 CU segundos.

Categorías de operaciones

Operaciones interactivas 👤 — iniciadas por una acción del usuario (ver un report, query ad-hoc). Smoothing: al menos 5 minutos (o más). Impacto más inmediato.

Operaciones background ⏰ — programadas o iniciadas por el sistema (refreshes, pipelines). Smoothing: 24 horas. Impacto distribuido.

Esta distinción es fundamental para entender el bursting y el smoothing.

Tabla completa

Escalado

Los F SKUs pueden escalar hacia arriba y hacia abajo de forma dinámica. Cruzar la frontera F256/F512 puede provocar una experiencia más lenta temporalmente.

Precios

• F SKUs: pay-as-you-go, por hora.
• Pause/resume: sin coste cuando está pausada (dev/test).
• Reserved instances: descuentos a 1 o 3 años.

Concepto

Bursting = Fabric usa MÁS cómputo que el SKU aprovisionado de forma temporal. Beneficio: obtener resultados sin esperar. Una capacidad más pequeña puede ejecutar operaciones más grandes que normalmente requerirían una capacidad más cara.

Por qué existe

Fabric entrega rendimiento rápido: tareas que en otras plataformas tardan minutos, en Fabric tardan segundos. Las operaciones grandes se ejecutan a cualquier hora del día sin necesidad de planificación cuidadosa. El bursting + el smoothing lo hacen posible.

Ejemplo mental

F8 con 8 CUs de baseline: sin bursting, máximo 8 CUs simultáneas. Con bursting (factor 12x), temporalmente puede usar hasta 96 CUs, y una query compleja termina rápido en vez de esperar.

Coste

El bursting NO cuesta extra por separado — las CUs consumidas se contabilizan igual. Sin embargo, un bursting alto significa más CUs totales consumidas → más carryforward CUs.

Concepto

Smoothing = Fabric reparte la evaluación del cómputo a lo largo de un periodo más largo para que los jobs se ejecuten con suavidad. Beneficio: gestión de capacidad simplificada.

Los 2 tipos de smoothing

A) Jobs interactivos (usuarios) 👤 — smoothing durante al menos 5 minutos (o más). Reduce los picos temporales cortos.

B) Jobs programados o background ⏰ — smoothing durante 24 horas. Elimina la preocupación por la planificación de jobs y la contención.

Ejemplo concreto: operación background

Escenario: una operación background consume 1 CU hora.

Capacidad F2: F2 provee 2 CUs = 48 CU horas al día (2 × 24). El job contribuye 1/48 = ~2,1% a cada timepoint.

Cálculo detallado:

• 1 CU hora = 3.600 CU segundos.
• 24 horas = 2.880 timepoints (24 × 60 × 2).
• El smoothing reparte 3.600 / 2.880 = 1,25 CU segundos por timepoint.
• F2 en cada timepoint: 2 × 30 = 60 CU segundos disponibles.
• Contribución: 1,25 / 60 = ~2,1% de cada timepoint.

Resultado: aunque el job consumió 1 CU hora (más que 10 minutos de baseline de F2), la capacidad F2 NO hace throttling porque el smoothing distribuye el consumo a lo largo de 24 horas.

Beneficio para la empresa

El smoothing te permite dimensionar la capacidad según la MEDIA, no según el pico. Sin smoothing tendrías que comprar el SKU para el pico; con smoothing, un SKU más pequeño puede absorber picos temporales. Ahorros importantes en costes.

¿Qué es el throttling?

Throttling = ocurre cuando las operaciones consumen más CU segundos de los que permite el SKU de la capacidad. Demasiado throttling → experiencia degradada para el usuario final.

Se aplica a nivel de capacidad

Fabric aplica el throttling A NIVEL DE CAPACIDAD: una capacidad puede sufrir rendimiento reducido por sobrecarga mientras otras capacidades siguen normales.

Cross-capacity: si la capacidad A produce items en OneLake y la capacidad B los consume, el estado de throttling de la capacidad CONSUMIDORA determina si hay throttling en esas llamadas.

Overages, carryforward y burndown

Muy importante para entender el mecanismo:

Overage = cuando las operaciones usan más capacidad de la que soporta el SKU en un único timepoint. Se computa después del smoothing. Si los overages exceden la ventana de throttling de 10 minutos permitida → se convierten en carryforward CUs.

Overage protection: garantiza que la capacidad no haga throttling hasta que la ventana de throttling de 10 minutos esté llena. Reduce la frecuencia de retrasos interactivos por picos temporales.

Carryforward CUs: se aplican a cada timepoint posterior. Si un timepoint no está lleno, las CUs no usadas reducen el carryforward.

Burndown: la reducción del carryforward de CUs cuando la capacidad está infrautilizada. El throttling continúa hasta que la capacidad no usada salda todas las carryforward CUs.

Cómo detectar el throttling

Códigos de error cuando la capacidad rechaza peticiones:

1. Status code: CapacityLimitExceeded
2. Mensaje de error: "Your organization's Fabric compute capacity has exceeded its limits. Try again later".
3. Mensaje de error: "Cannot load model due to reaching capacity limits".

Capacity Metrics app: vistas de throttling

En la página Compute de la Capacity Metrics app: la tabla System events muestra el historial de eventos de throttling, y los gráficos de throttling muestran cuándo el uso suavizado supera los límites.

Right-sizing

Niveles de throttling consistentemente altos indican que hay que balancear la carga entre varias capacidades o aumentar el tamaño del SKU. Para los F SKUs, puedes escalar la capacidad dinámicamente.

⚠️ Escalar cruzando la frontera F256/F512 puede provocar una experiencia más lenta temporalmente.

Configurar alertas

Los capacity admins pueden configurar alertas por email para los umbrales de capacidad, vía Capacity Overview Events. Se disparan cuando el uso supera el umbral configurado.

Feature específica

El Warehouse y el SQL analytics endpoint proveen capacidad burstable que permite a los workloads usar más recursos para mejorar el rendimiento.

Cómo calcular el scale factor

Capacity Units (CU) / duración / Baseline CU = Scale factor

Ejemplo: capacidad F8, un workload que tarda 100 segundos y usa 1500 CU.

Scale factor = 1500 / 100 / 8 = 1,875.

Cuando el scale factor > 1 → se está usando capacidad burstable → se están tomando prestadas capacity units de un intervalo de tiempo futuro (smoothing).

Guardrails por SKU

Fronteras de aislamiento

El Warehouse aísla completamente la ingesta del procesamiento de queries, y el burstable scale factor se alcanza de forma independiente para cada uno.

Máximo scale factor agregado de la capacidad:

([Query burstable scale factor] + [Ingestion burstable scale factor]) × [número de workspaces]
= aggregate burstable scale factor

Consideraciones

1. Rechazo de queries: si la recuperación o el procesamiento de datos no puede ejecutarse físicamente dentro del burstable scale factor, aparece el error "This query was rejected due to current capacity constraints". Revisa las guías de rendimiento antes de escalar.

2. Tras redimensionar: los nuevos guardrails se aplican cuando se ejecuta la siguiente query. El rendimiento se estabiliza en pocos segundos.

3. Tamaño de capacidad no óptimo: puede provocar contención de recursos (spilling) y aumentar el uso de CU del workload.

Pipelines fallando

Errores comunes:

• Fallos de autenticación → verificar las credenciales en Connections.
• Timeout → máximo 7 días por defecto; ajustar el timeout de la actividad.
• Data source no disponible → firewall, VNet peering, estado del gateway.
• Schema mismatch → deriva de schema en el destino.

Investigación:

1. Monitoring Hub → Pipeline → Historical runs.
2. Detalle del run → la actividad que ha fallado.
3. Detalles del error en el panel de detalle.
4. Rerun de la actividad fallida desde el monitoring hub.

Dataflows Gen2

Errores comunes: el query folding no funciona (verificar el código M, mirar el icono en Power Query), timeout en el refresh (simplificar la query, añadir staging) y problemas de conexión al data source (comprobar gateway/credenciales).

Investigación: el refresh history del dataflow, los mensajes de error con el paso concreto que falló, y habilitar staging (por defecto en Dataflow Gen2) para dividir la lógica compleja.

Notebooks (Spark)

Errores comunes: out of memory (aumentar el Spark pool u optimizar las particiones), executor lost (node reclaim, reintentar) y rendimiento lento (revisar el skew de particiones y el spilling de datos).

Investigación:

1. Spark UI desde el notebook.
2. Vista Stages → identificar las stages lentas.
3. Vista Executors → comprobar el uso de memoria.
4. Tab SQL / DataFrame → planes de query.

Eventhouse

Errores comunes: latencia de ingesta alta (revisar la política de batch/streaming), timeouts de query (optimizar el KQL, añadir materialized views) y crecimiento del storage (revisar la política de retención).

Investigación: la página Insights del Eventhouse, las estadísticas de caché y las métricas de ingesta.

Eventstreams

Errores comunes: la fuente no conecta (auth, red), los datos no fluyen (revisar la lógica de transformación) y fallos de escritura en el destino (verificar los permisos del Lakehouse/KQL DB destino).

Investigación: la vista Runtime del Eventstream y el data preview en cada nodo.

T-SQL (Warehouse)

Errores comunes: query rechazada por restricciones de capacidad (optimizar o escalar), estadísticas obsoletas (CREATE/UPDATE STATISTICS) y conflictos de snapshot isolation (rediseñar el patrón).

Investigación: los DMVs de query insights (ver la siguiente sección), los planes de query con SHOWPLAN y los DMVs de waits stats.

Shortcuts

Errores comunes: shortcuts rotos (la fuente se movió, cambiaron los permisos), metadatos obsoletos (refrescar el shortcut) y problemas cross-tenant (verificar los settings de external sharing).

Investigación: el estado del shortcut en el Lakehouse y verificar que el item origen sigue existiendo y siendo accesible.

V-Order

V-Order = optimización en tiempo de escritura del formato de fichero Parquet que permite lecturas ultrarrápidas en los compute engines de Fabric (Power BI, SQL, Spark).

Beneficios: típicamente 50% más rápido en lecturas, mejor compresión y optimizado para el modo Direct Lake. Está habilitado POR DEFECTO en Fabric.

Cómo funciona: al escribir un fichero Parquet aplica sorting, distribución de row groups, dictionary encoding y compresión. Es compatible con el Parquet estándar y su único coste está en el tiempo de escritura (~15% de overhead).

Desactivarlo:

SET spark.sql.parquet.vorder.enabled = false

Cuándo desactivarlo: workloads write-heavy que no se leen con frecuencia, o cuando el tiempo de escritura es crítico.

OPTIMIZE (tablas Delta)

OPTIMIZE compacta los ficheros pequeños en otros más grandes. Beneficio: mejora el rendimiento de lectura, reduce el número de ficheros escaneados y mejora el ratio de compresión.

OPTIMIZE my_table

Con Z-ORDER (co-localizar datos relacionados):

OPTIMIZE my_table ZORDER BY (customer_id, order_date)

Z-ORDER ayuda con las queries que filtran por esas columnas.

VACUUM

VACUUM elimina los ficheros de datos que ya no referencia la tabla y que son más antiguos que el umbral de retención.

VACUUM my_table RETAIN 168 HOURS

Retención por defecto = 7 días (168 horas). Beneficio: reduce los costes de storage y limpia los ficheros borrados lógicamente (tras UPDATE/DELETE/MERGE).

Particionado

Particiona las tablas Delta por las columnas que filtras con frecuencia:

df.write.partitionBy("year", "month").format("delta").save(path)

Beneficios: partition pruning en las queries y lecturas más rápidas con filtros sobre las columnas de partición.

Table Maintenance

Fabric ofrece una UI de Table maintenance en el Lakehouse: ejecutar OPTIMIZE con un click, ejecutar VACUUM con retención configurable y programar jobs de mantenimiento.

Native Execution Engine (NEE)

El Native Execution Engine es un runtime de ejecución en C++ que provee mejoras de rendimiento significativas.

%%configure
{
    "conf": {
        "spark.native.enabled": "true"
    }
}

Beneficio: 2-4x más rápido en muchos workloads.

Autoscale y sizing

Los Spark pools de Fabric soportan autoscale (ajuste automático de executors), dynamic allocation (los recursos escalan con el workload) y tamaños de pool custom (small, medium, large, extra large).

Best practices: pools pequeños para dev/testing, medianos para la mayoría de workloads de producción, y large/XL solo si es realmente necesario.

Optimización de shuffle

Adaptive Query Execution (AQE) está habilitado por defecto: fusiona dinámicamente las particiones de shuffle, gestiona el skew automáticamente y elige las estrategias de join de forma adaptativa.

Caching

Cachea los datasets que reutilizas con frecuencia:

df.cache()
# o
df.persist(StorageLevel.MEMORY_AND_DISK)

Best practice: haz unpersist() cuando termines, para liberar memoria.

Data skew

Detectar el skew: algunas tasks tardan mucho más que otras; el Spark UI en stages muestra la distribución.

Mitigarlo: salt keys (añadir un sufijo aleatorio), broadcast join para tablas pequeñas y repartition por una key mejor.

Broadcast joins

Para tablas pequeñas (< 10 MB por defecto):

from pyspark.sql.functions import broadcast
result = large_df.join(broadcast(small_df), "key")

Elimina el shuffle.

Statistics

El Warehouse se apoya en las estadísticas para planificar las queries. La creación automática de estadísticas está habilitada por defecto, y puedes hacer una actualización manual para tablas que cambian con frecuencia:

UPDATE STATISTICS dbo.SalesFact WITH FULLSCAN;

Estadísticas obsoletas = malos planes de query = queries lentas.

Star schema

El Warehouse está optimizado para star schema: fact tables (grandes, transaccionales), dimension tables (más pequeñas, descriptivas) y foreign keys entre ellas. Evita modelos muy normalizados (muchos joins) y tablas anchas sin estructura.

Patrones de query

• Filtrar pronto (WHERE en las subqueries).
• Proyectar solo las columnas necesarias (evitar SELECT *).
• Usar CTEs para legibilidad y optimización del plan.
• Evitar cursores — operaciones basadas en conjuntos.

Workload management

El Warehouse tiene gestión autónoma del workload: gestiona los recursos automáticamente, aísla la ingesta del procesamiento de queries y normalmente no necesita tuning manual.

Custom SQL pools (preview): para workloads específicos que necesitan aislamiento, con guardrails acumulativos.

V-Order en Warehouse

El Warehouse usa V-Order automáticamente — beneficio implícito.

Materialized views

Las materialized views precomputan resultados: se actualizan automáticamente con los datos nuevos y dan queries rápidas para las agregaciones comunes.

.create materialized-view MyView on table Events
{
    Events
    | summarize count() by bin(Timestamp, 1h), Category
}

Update policies

Las update policies transforman en la ingesta: aplican una función a los datos cuando se ingestan y se disparan a la llegada de los datos (no por schedule).

Caching

Hot cache para los datos de acceso frecuente: configurable por tabla, y a mayor caché, queries más rápidas.

.alter table Events policy caching hot = 30d

Particionado

La política de particionado para datasets enormes divide los datos en particiones por el valor de una columna, mejorando el rendimiento de las queries con filtros.

Best practices de KQL

• where pronto: filtrar primero.
• project solo las columnas necesarias.
• Evitar operadores evaluate costosos cuando no son necesarios.
• take/top: limitar los resultados.
• materialize(): reutilizar subqueries.

Dynamic Management Views (DMVs)

El Warehouse expone DMVs para los query insights.

Ejecución de queries:

SELECT * FROM sys.dm_exec_requests;
SELECT * FROM sys.dm_exec_sessions;

Historial de queries:

SELECT * FROM queryinsights.exec_requests_history;

Estadísticas de queries:

SELECT * FROM queryinsights.frequently_run_queries;
SELECT * FROM queryinsights.long_running_queries;

Uso típico

Investigaciones: ¿cuáles son mis queries más lentas?, ¿qué queries se ejecutan más?, ¿cuánta CPU consume cada query?, ¿hay queries con malos planes?

Ejemplo: las 10 queries más largas de las últimas 24 horas:

SELECT TOP 10
    login_name,
    submit_time,
    total_elapsed_time_ms,
    command
FROM queryinsights.exec_requests_history
WHERE submit_time > DATEADD(hour, -24, GETDATE())
ORDER BY total_elapsed_time_ms DESC;

Spark query insights

Spark UI en los notebooks: vista Jobs, vista Stages, planes de query en SQL / DataFrame y memoria y CPU en Executors.

Eventhouse insights

La página Insights del Eventhouse: métricas de ingesta, patrones de query, estadísticas de caché y optimizaciones recomendadas.

¿Qué es?

El admin monitoring workspace es un workspace especial que provee capacidades de monitorización para toda la organización. Solo está disponible para los administradores de Fabric y los capacity admins.

Contenido

Reports disponibles:

1. Feature usage y adoption report — consumo en toda la organización, con el semantic model incluido para reports custom.
2. Purview hub (punto de integración).
3. Usage metrics reports a nivel workspace.

Uso típico

• Admins entendiendo qué features usan los usuarios.
• Análisis de gobernanza: quién crea qué y dónde.
• Seguimiento de adopción: crecimiento del uso de Fabric.
• Reporting custom: crear reports sobre el semantic model.

Complemento a la Capacity Metrics app

La Capacity Metrics app se centra en el consumo de CU; el admin monitoring workspace se centra en el uso y la adopción de features. Se complementan para tener la foto completa.

Monitoring general

1. Revisa el Monitoring Hub a diario durante los despliegues.
2. Configura notificaciones de fallo para los items programados críticos.
3. Historical runs: revisa las tendencias antes de escalar el problema.
4. Los filtros se recuerdan: configura las vistas que uses a menudo.

Activator

1. Para las rules durante las pruebas para evitar alertas de más.
2. Rules stateful para transiciones, no disparos repetidos.
3. Context en las acciones: incluye los datos relevantes en los emails/Teams.
4. Acciones custom solo cuando las básicas no sean suficientes.

Gestión de capacidad

1. Dimensiona la capacidad según la media, no el pico (el smoothing ayuda).
2. Alertas para los umbrales de capacidad antes de llegar al throttling.
3. Escalado dinámico del F SKU según las necesidades.
4. Investiga el diseño antes de escalar (lento ≠ throttling).
5. Pausa las capacidades de desarrollo cuando no se usan.

Optimización Lakehouse

1. V-Order habilitado por defecto — déjalo así.
2. OPTIMIZE con regularidad (semanal o cuando se acumulen ficheros pequeños).
3. VACUUM tras borrados o actualizaciones masivas.
4. Particiona con criterio — objetivo de 1 GB o más por partición.
5. Z-ORDER solo cuando las queries se beneficien.

Optimización Spark

1. Native Execution Engine para workloads intensivos.
2. Adaptive Query Execution (por defecto).
3. Broadcast joins para tablas pequeñas.
4. Cachear los datasets reutilizados.
5. Pools con autoscale.

Optimización Warehouse

1. Estadísticas actualizadas para las tablas que cambian.
2. Diseño en star schema.
3. Proyectar solo las columnas necesarias.
4. CTEs para la lógica compleja.
5. WLM autónomo — déjalo por defecto salvo casos específicos.

Optimización Eventhouse

1. Materialized views para las agregaciones comunes.
2. Update policies para las transformaciones.
3. Cachear los datos hot.
4. Best practices de KQL (filtrar pronto, proyectar menos).

• Trampa 1: "El Monitoring Hub muestra TODOS los items" ❌ Dataflow Gen1 NO está soportado. Y los NotebookInteractiveRun tienen limitaciones con el estado "Stopped".
• Trampa 2: "El Monitoring Hub muestra todas las actividades de los últimos 30 días" ❌ Solo las 100 más recientes. Para el historial completo de 30 días usa Historical runs.
• Trampa 3: "Cualquier usuario puede ver todas las actividades" ❌ Solo las actividades de los items sobre los que el usuario tenga permiso de vista.
• Trampa 4: "Las notificaciones de fallo funcionan para los semantic models" ❌ Los semantic models aún NO están soportados en la página Schedule failures (usan su propio mecanismo en los settings del dataset).
• Trampa 5: "Las notificaciones de fallo se disparan para todos los runs" ❌ Solo para los runs PROGRAMADOS. Los disparados manualmente NO generan notificaciones.
• Trampa 6: "Activator solo soporta datos en streaming" ❌ También KQL Querysets, Real-Time Dashboards y queries SQL de Warehouse (preview). También datos batch.
• Trampa 7: "Las rules stateful se disparan en cada evento que cumple la condición" ❌ Solo se disparan al ENTRAR en un nuevo estado. Evita los disparos repetidos.
• Trampa 8: "Los copy jobs aceptan parámetros en Activator" ❌ NO. Los copy jobs NO aceptan parámetros.
• Trampa 9: "El bursting cuesta extra" ❌ NO cuesta por separado. Las CUs se contabilizan igual, aunque pueden generar más carryforward.
• Trampa 10: "El smoothing hace que los jobs tarden más" ❌ El smoothing NO afecta al tiempo de ejecución. Solo distribuye la contabilización de las CUs.
• Trampa 11: "El smoothing interactivo es de 24 horas" ❌ Interactivo = mínimo 5 minutos. Background = 24 horas.
• Trampa 12: "F64 y P1 son diferentes" ❌ F64 ≡ P1 en cómputo. Es el umbral para el consumo gratuito de contenido de Power BI.
• Trampa 13: "El rendimiento lento siempre es throttling" ❌ Muchas veces es el diseño del item. Solo a veces es throttling.
• Trampa 14: "F2 tiene el burstable factor más pequeño" ❌ F2 tiene el MÁS GRANDE (32x). F8192 tiene el más pequeño (3x).
• Trampa 15: "V-Order requiere activación manual" ❌ Está habilitado POR DEFECTO en Fabric.
• Trampa 16: "VACUUM sin retención es seguro" ❌ VACUUM sin retención usa el default de 7 días. Bajar de ahí requiere un cambio de configuración y rompe el time travel.
• Trampa 17: "El Native Execution Engine está habilitado por defecto" ❌ NO. Requiere activación con %%configure.
• Trampa 18: "El texto del error de throttling es siempre el mismo" ❌ Hay 3 patrones: CapacityLimitExceeded, "has exceeded its limits" y "Cannot load model due to reaching capacity limits".
• Trampa 19: "El burstable scale factor del Warehouse es igual en todos los SKUs" ❌ Varía: F2 = 1x-32x, F8-F2048 = 1x-12x, F4096 = 1x-6x, F8192 = 1x-3x.
• Trampa 20: "La ingesta y el procesamiento de queries comparten el burstable en Warehouse" ❌ Están completamente aislados. Cada uno puede hacer burst de forma independiente.
• Trampa 21: "OPTIMIZE ZORDER siempre mejora el rendimiento" ❌ Solo cuando las queries filtran por esas columnas. Si no, puede añadir overhead.
• Trampa 22: "Las rules paradas siguen ejecutándose en silencio" ❌ Una rule parada no se ejecuta. No se envían alertas.
• Trampa 23: "Las acciones custom son necesarias en la mayoría de casos" ❌ Las acciones básicas (email, Teams, actividades de Fabric) cubren la mayoría. Las custom, solo para casos específicos.
• Trampa 24: "La Capacity Metrics app viene incluida por defecto" ❌ Requiere instalación desde AppSource o el admin portal.
• Trampa 25: "La selección de filtros del Monitoring Hub se pierde entre sesiones" ❌ El Monitoring Hub recuerda tu selección de filtros para la siguiente visita.

Monitoring Hub vs Workspace monitoring

Operaciones interactivas vs background (smoothing)

Stateless vs Stateful rules (Activator)

Bursting vs Smoothing vs Throttling

Fabric SKUs y burstable factor

Acciones posibles en Activator

Herramientas de optimización del Lakehouse

DMVs útiles del Warehouse

Fuentes de datos para Activator

Herramientas de monitorización según el uso

• Módulo Learn: monitor-fabric-items
• Monitoring Hub: monitoring-hub
• Activator introduction: activator-introduction
• Activator alerts KQL Queryset: activator-alert-queryset
• Activator conditions: activator-detection-conditions
• Activator custom actions: activator-trigger-power-automate-flows
• Set alert Real-Time Dashboard: user-flow-6
• Set alerts warehouse SQL query: set-alerts-warehouse-sql-query
• Fabric admin overview: admin-overview
• Capacity Metrics app: metrics-app
• Plan capacity: plan-capacity
• Throttling policy: throttling
• Optimize capacity: optimize-capacity
• Scale capacity: scale-capacity
• Pause resume capacity: pause-resume
• Burstable capacity Warehouse: burstable-capacity
• Compute capacity smoothing throttling: compute-capacity-smoothing-throttling
• Capacity planning plan deployment: capacity-planning-plan-deployment
• Track user activities: track-user-activities
• Admin monitoring workspace: monitoring-workspace
• Feature usage adoption: feature-usage-adoption
• Notifications capacity threshold: tutorial-monitor-capacity-threshold
• Warehouse guidelines performance: guidelines-warehouse-performance
• Delta Lake table optimization: delta-optimization-and-v-order