Cinco minutos al día para dejar de reaccionar a ciegas en Microsoft Fabric
Guía práctica de la Microsoft Fabric Capacity Metrics App para diagnosticar rendimiento, throttling y consumo de CUs
En Microsoft Fabric, el consumo de recursos se suaviza, se acumula y, a veces, se convierte en throttling antes de que nadie lo haya visto venir. Los informes tardan más, los refrescos empiezan a fallar y aparecen mensajes de throttling sin previo aviso. Y la pregunta inevitable es siempre la misma:
¿Qué está consumiendo realmente mi capacidad?
La respuesta no está en la intuición, ni en señalar a Spark “porque sí”, ni en mirar mal al informe más usado. Está en los datos de consumo de tu propia capacidad. Y ahí es donde entra la Capacity Metrics App.
¿Qué es Microsoft Fabric Capacity Metrics App?
La Capacity Metrics App es una aplicación oficial de Microsoft que recopila y visualiza todas las operaciones que consumen CUs dentro de una capacidad de Fabric. Te ayuda a responder tres preguntas clave: quién está consumiendo, cuándo lo está haciendo y cómo ese consumo impacta en el rendimiento global.
Ajustemos expectativas:
- Te dirá qué informe, qué pipeline o qué notebook consume.
- No te dirá qué medida DAX o qué línea de código Spark es la culpable.
Esta es la linterna, no el bisturí.
Cómo instalar Capacity Metrics App
Necesitas el rol de Administrador de capacidad en Fabric. Sin él, no verás los datos que necesitas.
- Ve a AppSource y busca “Microsoft Fabric Capacity Metrics”.
- Haz clic en Get it now e instala la app en tu tenant.
- Al abrirla por primera vez, conéctala introduciendo el Capacity ID (lo encuentras en el portal de administración de Fabric).
La app tiene una retención máxima de 14 días y no es monitorización en tiempo real, pero es más que suficiente para el análisis de patrones que necesitas.
Mi rutina de los 5 minutos con el café
Antes de que entre el primer ticket de “esto va lento”, ya sé cómo está la capacidad. No porque tenga superpoderes, sino porque tengo una ruta fija que tarda lo que dura el primer café.
Un consejo antes de empezar: no empieces por el detalle. Analiza siempre 7–14 días completos. Entrar directamente a un pit de 30 segundos sin contexto es como intentar diagnosticar una enfermedad mirando solo una analítica suelta.
Parada 1 — Health page de Capacity Metrics App: el semáforo general
Lo primero que abro es la Health page. Dos vistas: Last 24 hours para ver qué pasó anoche, Last 1 hour si ya hay alguien reportando problemas.
Las cards de cabecera me dicen el estado real sin que tenga que interpretar nada. Lo más importante: si hay alguna capacidad en # Throttled capacities, # Interactive rejected o # Background rejected. Si esos contadores están a cero, respiro. Si no, ese café lo voy a necesitar.
En el Capacity breakdown, la columna Health no deja margen a la ambigüedad:
- Healthy → todo bien, sigo con el café
- At Risk of Throttling → el 10 min interactive ya supera el 90 %, hay que vigilar
- Throttling → el freno ya está puesto, alguien lo va a notar
- Interactive / Background Rejection → esto ya no es café, esto es reunión
También le echo un ojo a Usage variance. Una varianza alta con deuda acumulada es la firma de una capacidad que lleva días al límite aunque no haya ningún pico espectacular.
Si todo está verde, cierro la Health page y termino el café tranquila. Si no, sigo bajando.
Todo ok, ese día me tomé el café tranquila. Total tenía Trial nueva.
Parada 2 — Compute page: el electrocardiograma de tu capacidad Fabric
Desde la Health page: right-click sobre la capacidad → Drill through → Compute.
Pestaña de Compute
Tres pestañas por orden:
Utilization. Barras apiladas rojas (interactive) y azules (background). La línea gris al 100 % es el límite real del SKU. Si hay columnas que lo superan de forma recurrente, tengo un problema estructural, no un incidente aislado.
Claramente esa semana monté pocas demos…
Throttling. Me dice cuánto me queda antes de que Fabric empiece a frenar:
- Interactive delay → cuando el 10 min interactive supera el 100 %
- Interactive rejection → cuando el 60 min interactive supera el 100 %
- Background rejection → cuando el 24h background supera el 100 %
Si veo barras en interactive delay a la misma hora todas las mañanas, hay algo solapándose que no debería. Alguien planificó refrescos en el peor momento posible.
Ni a interactive delay me acerco, en el resto puede pasar un estepicursor
Overages → Carryforward. Si la línea roja de Cumulative % no baja en las horas valle, la capacidad nunca descansa. Es el indicador más silencioso y más peligroso a la vez.
En la parte baja, el Matrix by item and operation: ordeno por CU (s) de mayor a menor y veo qué workspace y qué item se lleva la mayor parte. Naranja es degradación moderada, rojo es que algo ha empeorado más de un 25 % respecto a la semana anterior.
💡 Truco: pasa el ratón sobre cualquier fila del matrix para ver el desglose por tipo de operación. Es uno de los pocos sitios donde puedes ver esa granularidad sin hacer drill-through.
Detalle de las operaciones y su coste
Parada 3 — Timepoint Detail: la sala de interrogatorios
Right-click sobre el pico → Drill through → Timepoint detail.
Lo primero: el Heartbeat chart, una ventana de 60 minutos centrada en el timepoint. Me dice si ese pico fue un disparo aislado o una meseta sostenida. Esa diferencia cambia completamente el diagnóstico.
Después, las tablas:
Si el problema es interactivo: la columna User me dice exactamente quién lanzó la query, en qué workspace y sobre qué item. Ordeno por Timepoint CU (s) y en cinco segundos sé si hay un usuario ejecutando un informe pesado a primera hora, una consulta SQL sin filtro o un notebook que alguien olvidó parar antes de irse a comer. Si hay valor en Throttling (s), ese usuario ya lo notó en su pantalla, aunque no haya dicho nada todavía.
Y ahí salgo yo revisando FUAM
Si el problema es background: un pipeline solapado con el inicio de jornada, un refresco semántico mal planificado, un Spark job nocturno que sigue consumiendo en el smoothing del día siguiente. Cuando lo identifico, la decisión es sencilla: ¿lo replanificamos? ¿Lo optimizamos? ¿Lo paramos?
He ido a hacer pantallazos justo del FUAM para que os empiece a sonar esta otra MARAVILLA de herramienta
Y la columna que más me gusta de toda la app: Minutes to burndown. Me dice cuánto tiempo queda antes de que el carryforward acumulado se disipe. Si son más de 60 minutos con carga interactiva encima, el throttling es casi seguro. No como sospecha: como dato.
Esa columna es muy clave
El paseo final: buscar lo que nadie te va a reportar
Cuando no hay incidentes, me tomo los últimos minutos del café para pasearme por el matrix con la vista de 14 días:
- Items con Performance delta naranja o rojo de forma recurrente → el rendimiento lleva tiempo degradándose y nadie lo ha notado porque “más o menos va”
- Workspaces con Overloaded minutes altos → están pagando el precio del bursting de otros
- Picos que se repiten exactamente a la misma hora todos los días → planificación mal diseñada, casi siempre evitable
Café terminado. Ya sabes qué está pasando, quién lo está causando y si tienes margen para que el día siga bien.
Dos casos que verás más de una vez
Refrescos solapados en hora punta. El síntoma: barras rojas y azules al mismo tiempo, justo a las 8:00 o las 9:00. La causa: alguien programó los refrescos semánticos sin tener en cuenta que esa es la hora de mayor carga interactiva. La solución pasa por escalonar los refrescos a ventanas de bajo tráfico, o convertir los refrescos full en incrementales donde sea posible.
Informes con visuales o DAX “con esteroides”. El síntoma: un único item interactivo que monopoliza el consumo del timepoint y aparece en rojo en el Performance delta. La causa: un informe con demasiadas visualizaciones complejas, medidas DAX sin optimizar o un modelo que fuerza un full scan en cada interacción. Capacity Metrics App te señala el culpable; DAX Studio o el Analizador de rendimiento te dirán el por qué.
Menos throttling, más control
La Capacity Metrics App no arregla los problemas por sí sola. Pero hace algo mucho más importante: te dice exactamente dónde mirar.
Cuando la dominas, dejas de reaccionar a ciegas y empiezas a gestionar tu capacidad con datos, criterio y tranquilidad. Cinco minutos al día, una ruta clara y el café todavía caliente.
Menos microinfartos. Más control. Y una capacidad Fabric que, por fin, juega en tu equipo.
Enlaces de interés
- Ricardo Rincón habla en ADN Fabric sobre Capacity Metrics → https://www.youtube.com/watch?v=ETgvOeCHU9c&t=7616s
- ¿Qué es la Capacity Metrics App?
- Instalar la Capacity Metrics App
- Entender la Health page
- Entender la Compute page
- Entender el Timepoint detail
- Cómo funciona el throttling en Fabric
- Evaluar y optimizar tu capacidad
¿Te ha servido? Aplaude, sin cuenta. Puedes hacerlo varias veces.
Comentarios