Fabric Capacity Metrics: Cómo leer los gráficos para encontrar al culpable

En Microsoft Fabric, la gestión de costes no es opcional ni se puede delegar totalmente en el sistema. A diferencia del modelo de Power BI Premium por usuario, donde el límite es el tamaño del modelo, en Fabric pagamos por potencia de cómputo: las Capacity Units (CU). El problema es que, si no monitorizas activamente, una consulta de SQL mal optimizada o un bucle infinito en un Notebook pueden consumir en minutos los recursos de todo un día.

La herramienta fundamental para no ir a ciegas es la Fabric Capacity Metrics app. No es solo un panel de control; es el único lugar donde podemos ver el impacto real de nuestras decisiones de arquitectura. Sin embargo, su lectura no es intuitiva. Conceptos como el Smoothing (suavizado) o el Carry forward (arrastre) pueden hacer que veas un consumo del 200% y que, sin embargo, los informes sigan funcionando, o que veas un 80% y el sistema empiece a rechazar peticiones.

En este artículo, como consultor que ha tenido que explicar más de una factura inesperada, te enseñaré a bajar al detalle de los datos para identificar qué ítem y qué usuario están agotando tu capacidad. Antes de empezar, recuerda que para que los datos tengan sentido, debes realizar pruebas de rendimiento en Fabric Warehouse de forma controlada.

El concepto de Smoothing: Por qué tu capacidad no se agota al instante

Fabric utiliza un mecanismo llamado Smoothing para evitar que los picos puntuales de computación interrumpan el servicio. Si lanzas un proceso pesado que consume 100 CUs durante 1 minuto, Fabric no te cobra esas 100 CUs en ese minuto. En su lugar, reparte ese esfuerzo a lo largo de un periodo de tiempo más largo.

• Operaciones interactivas: (como abrir un informe de Power BI o ejecutar una consulta en SQL) se suavizan en un periodo de 5 a 10 minutos.
• Operaciones en segundo plano (Background): (como refrescos de modelos semánticos, ejecución de Pipelines o Notebooks) se suavizan en un periodo de 24 horas.

Esto es una ventaja estratégica: te permite usar más potencia de la que tienes contratada durante periodos cortos. Pero tiene un riesgo: si saturas el promedio de 24 horas, entrarás en estado de Throttling (estrangulamiento). La app de métricas te permite ver esta diferencia entre el consumo actual y el consumo suavizado, que es el que realmente cuenta para los límites de tu F-SKU.

Identificando al culpable: La vista de ‘Compute Items’

Cuando abres la app, el gráfico principal muestra la utilización total. Sin embargo, para encontrar al culpable debemos ir a la tabla inferior y seleccionar el punto en el tiempo (Timepoint) donde se produjo el pico. Al hacer clic en un punto de la línea de tiempo, la tabla de abajo se filtra para mostrar qué procesos estaban activos en ese segundo exacto.

En mi experiencia, la columna más importante es CU (s). Aquí es donde ves el consumo bruto. Si ves un ítem llamado ‘Ventas_Lakehouse’ con un consumo disparado, ya tienes el primer hilo del que tirar. Pero no te quedes ahí. Debes distinguir entre el nombre del ítem y la operación específica. Por ejemplo, dentro de un Warehouse, podrías ver que el culpable no es la carga de datos, sino la fragmentación en Microsoft Fabric Warehouse que obliga al motor a realizar más esfuerzo de lectura del necesario.

Análisis de operaciones por tipo

Para sistematizar el análisis, es útil categorizar qué estamos viendo. La app divide las operaciones en grupos. Aquí tienes una comparativa de cómo impactan:

Uso de SQL para complementar la App de Métricas

Aunque la app es excelente para el historial, a veces necesitas saber qué está pasando ahora mismo en tu Warehouse de Fabric. La app tiene un retraso de unos minutos, por lo que combinarla con consultas a las vistas de sistema (DMVs) es la mejor práctica de consultoría. Si notas lentitud, ejecuta este script en el editor de SQL o a través de herramientas externas como vimos en la guía para conectar SSMS a Fabric:

-- Identificar consultas activas y su consumo de memoria/tiempo en el Warehouse
SELECT 
 request_id,
 status,
 command,
 submit_time,
 start_time,
 total_elapsed_time_ms / 1000 AS elapsed_seconds
FROM sys.dm_exec_requests
WHERE status = 'Running'
ORDER BY total_elapsed_time_ms DESC;

-- Consultar el historial reciente de ejecuciones para cruzar con la App de Métricas
SELECT TOP 20
 distributed_statement_id,
 operation_type,
 execution_polic_name,
 status,
 total_elapsed_time_ms
FROM sys.dm_exec_requests_history
ORDER BY start_time DESC;

Cruzar el distributed_statement_id con el Operation ID que aparece en la Capacity Metrics App es la única forma de tener una certeza del 100% sobre qué consulta SQL exacta quemó tus créditos.

El peligro del Throttling: Niveles de penalización

Si tu consumo suavizado supera el 100% de la capacidad contratada, Fabric no corta el servicio inmediatamente, pero activa mecanismos de defensa. Hay tres niveles que debes vigilar en la pestaña de ‘Throttling’ de la app:

1. Background Rejection: Se empiezan a cancelar refrescos programados o tareas de segundo plano. Es la primera señal de alerta.
2. Interactive Delay: Las consultas de los informes de Power BI empiezan a tardar unos segundos más de lo normal de forma artificial. El sistema te está «frenando» para que bajes el ritmo.
3. Interactive Rejection: El nivel crítico. Los usuarios empiezan a recibir errores de «Capacidad excedida» al intentar ver sus datos.

Si llegas al nivel 3, no intentes optimizar el DAX en ese momento; la única solución rápida es escalar la capacidad (por ejemplo, de F2 a F4) en el portal de Azure para absorber la deuda acumulada y luego bajarla cuando la situación se estabilice.

Optimizando procesos de Spark (Notebooks)

Los Notebooks son los grandes devoradores de CUs en segundo plano. A menudo, el problema no es la cantidad de datos, sino una mala gestión de las zonas horarias o tipos de datos complejos que obligan a Spark a hacer conversiones costosas en cada fila. Si ves que un Notebook consume demasiado, revisa la conversión de fechas y zonas horarias en PySpark, ya que es un error común que dispara el uso de CPU.

Aquí tienes un patrón de código para medir cuánto tiempo tarda una operación específica dentro de tu Notebook, lo cual te ayudará a correlacionar con la app de métricas:

import time

# Inicio de la medición
start_time = time.time()

# Operación costosa: p.ej. carga de ventas desde el Lakehouse
df_ventas = spark.read.format("delta").load("Tables/Ventas")
df_resumen = df_ventas.groupBy("ProductoID").sum("Importe")
df_resumen.write.mode("overwrite").saveAsTable("ResumenVentas")

# Fin de la medición
end_time = time.time()
print(f"Operación completada en {end_time - start_time:.2f} segundos")

Errores frecuentes al interpretar las métricas

• Confundir picos de Interactive con Background: Si un informe va lento, no siempre es culpa del DAX. Mira si hay un refresco de Lakehouse (Background) saturando la capacidad total.
• Ignorar el ‘Carry Forward’: Pensar que como hoy no hay procesos activos la capacidad debería estar al 0%. La deuda de ayer se paga hoy si no hubo capacidad sobrante.
• No filtrar por Workspace: En capacidades compartidas por varios departamentos, es vital usar los filtros de la app para no culpar al equipo de Finanzas de lo que está haciendo el equipo de Logística.
• Confiar ciegamente en el promedio: El promedio diario puede ocultar picos brutales de 10 minutos que están degradando la experiencia del usuario.
• No vigilar la latencia: A veces la capacidad está bien, pero la latencia en el Lakehouse es alta por falta de mantenimiento en los archivos Delta.

Checklist para una sesión de monitorización efectiva

• [ ] Identifica si el estado de la capacidad es ‘Healthy’, ‘Scaling’ o ‘Throttled’.
• [ ] Localiza el ítem con mayor CU (s) en las últimas 24 horas.
• [ ] Compara el consumo interactivo vs. segundo plano para decidir si el problema es de diseño de informes o de procesos ETL.
• [ ] Revisa la pestaña de ‘Top Operations’ para ver si es un usuario concreto el que lanza consultas ineficientes.
• [ ] Si hay sobrecarga, verifica si coincide con el horario de refresco de los modelos semánticos más grandes.

Preguntas frecuentes

¿Por qué la app de métricas muestra datos con retraso?

El motor de telemetría de Fabric procesa los eventos en lotes. Por lo general, hay un retraso de entre 15 y 30 minutos desde que ocurre la operación hasta que aparece reflejada con detalle en la app. Para monitorización en tiempo real, usa las DMVs de SQL o el Spark UI.

¿Qué significa el valor ‘Overages’ en el gráfico?

Indica la cantidad de unidades de capacidad que has consumido por encima de tu límite contratado y que aún no han sido compensadas. Es, básicamente, la «deuda» que tu capacidad tendrá que pagar en los próximos periodos de tiempo mediante el suavizado.

¿Puedo recibir alertas automáticas si el consumo es alto?

Directamente la app no envía alertas, pero puedes usar Data Activator sobre el dataset que alimenta la Capacity Metrics App para configurar disparadores que te envíen un correo o un mensaje de Teams cuando el uso suavizado supere el 90%.

¿Influye el escalado automático de Azure en estas métricas?

Si tienes activado el escalado automático en Azure (Autoscale), la app mostrará cómo el límite de CUs disponibles sube dinámicamente para absorber el pico. Es útil para evitar el throttling, pero recuerda que cada salto de escala aumenta el coste operativo por hora.

Conclusión

La Fabric Capacity Metrics app es el único juez de paz en un ecosistema tan complejo como Microsoft Fabric. Como consultores, nuestra labor es pasar de la queja del usuario («el informe va lento») a la evidencia técnica («esta operación de Spark consumió 500 CU/s debido a un join ineficiente»). Dominar esta herramienta no solo ahorra dinero, sino que garantiza que la arquitectura de datos sea sostenible a largo plazo.