Un sistema publicado solo protege la confianza si alguien lo observa. Monitorear Fabric no es abrir un tablero: es separar tres preguntas distintas (¿corrieron los trabajos?, ¿alcanza la capacidad?, ¿el usuario recibió lo esperado?) y asignar una señal, un responsable y una respuesta a cada una.
Tres preguntas distintas que suelen confundirse
El error más común es mirar una sola pantalla y creer que cubre todo. La operación de Fabric combina la salud de las ejecuciones, los registros, el consumo de capacidad, el gobierno, la calidad y la adopción. Ninguna vista aislada responde por las demás.
Conviene tratar el monitoreo como tres capas separadas:
Trabajos: ¿las actualizaciones y canalizaciones corrieron, en cuánto tiempo y con qué estado?
Capacidad: ¿el consumo de unidades y la sobrecarga están dentro de lo esperado?
Experiencia de usuario: ¿la persona que abre un informe, Excel conectado o un agente obtiene la respuesta correcta?
Una capacidad sana con un trabajo fallido sigue entregando datos viejos. Un trabajo exitoso sobre una capacidad saturada puede llegar tarde. Y ambas pueden estar bien mientras un usuario ve un informe roto por permisos. Por eso cada capa necesita su propia señal.
Qué herramienta responde cada pregunta
Fabric ofrece piezas distintas para preguntas distintas, y mezclarlas genera diagnósticos lentos.
Monitoring Hub da la vista rápida de ejecuciones, estados, fallos, duración y responsables cuando son visibles. Es el primer lugar donde mirar ante un fallo, según la .
Demo gratuita
Mira cómo construir tu sistema de datos e IA
Un recorrido práctico de principio a fin para unificar fuentes dispersas en un modelo semántico que alimenta Excel, Power BI, Copilot y tus agentes.
Workspace Monitoring envía los eventos de ejecución a un Eventhouse y una base KQL para investigar tendencias y construir alertas propias. Sirve cuando el diagnóstico puntual del Hub no alcanza y necesitas registros consultables.
Capacity Metrics muestra el consumo de unidades, la sobrecarga y los patrones que ayudan a optimizar o escalar. Es la referencia para entender el consumo y la limitación de recursos; la app de métricas de capacidad documenta cómo leer esas señales.
OneLake Catalog centraliza confianza, responsables, linaje, gobierno y acceso sobre los activos.
El mapa práctico: Monitoring Hub para el diagnóstico inicial, Workspace Monitoring para conservar historial consultable, Capacity Metrics para explicar el consumo y OneLake Catalog para gobierno. Las pruebas de calidad siguen siendo un contrato del producto de datos y deben emitir una señal accionable, no vivir solo en la cabeza de quien construyó el modelo.
Cada señal necesita un responsable, no solo un tablero
Un tablero sin dueño no es monitoreo, es decoración. La señal se vuelve útil cuando existe una cadencia y una persona que actúa.
El control de cargas es una revisión diaria o según criticidad: su objetivo es detectar fallos antes de que los usuarios pierdan confianza. La revisión de adopción es mensual y responde si el sistema realmente se usa en decisiones. La higiene del workspace se ejecuta según cambios grandes, para revisar carpetas, elementos temporales, modelos duplicados e informes reconectados.
Cada una de estas revisiones debe cerrar con la misma estructura mínima: qué se revisó, qué señal disparó una acción y quién la ejecutó. Sin ese cierre, el fallo se descubre cuando lo reporta un usuario, que es exactamente lo que el monitoreo intenta evitar.
Umbrales y decisiones alrededor de la capacidad
La capacidad es la capa donde las decisiones cuestan dinero, así que conviene tratarla con una guía operativa, no con reacciones improvisadas.
Antes y después de una demostración o una ventana de carga intensa, la operación consiste en encender o asignar capacidad cuando hace falta, retirar la asignación de una capacidad de pago o reasignar al terminar, pausar la capacidad de pago cuando corresponda y verificar el estado mediante API.
La guía mínima recomendable tiene un orden que importa:
Confirmar que la sesión de la CLI sigue activa y que el usuario cuenta con permisos para administrar o asignar esa capacidad.
Leer el workspace y las capacidades disponibles.
Asignar el workspace correcto.
Pausar o reanudar mediante Azure o Fabric API.
Volver a comprobar el estado.
Una condición crítica: pausar una capacidad puede dejar contenido no disponible, y la operación no termina hasta que el workspace y la capacidad muestran el estado esperado. La planificación de capacidad y despliegue conecta estas decisiones con el gobierno y el crecimiento, como detalla la guía de planificación de capacidad de Microsoft. Escalar sin observar el consumo previo suele ser más caro que ajustar lo que ya existe.
Monitorear la experiencia, no solo la infraestructura
La capa que más se olvida es la del usuario final. Un trabajo verde y una capacidad holgada no garantizan que la persona correcta vea el número correcto.
La prueba básica de consumo se ejecuta antes de publicar o mostrar, y su regla es concreta: probar Power BI, Excel, Copilot o Data Agent, Teams y la Fabric App con el usuario o rol esperado, no solo con quien creó la solución. Los permisos se validan con usuarios finales; los números, con DAX sobre el modelo publicado; las experiencias, con navegador, Teams o Excel según corresponda.
Esto conecta con una idea de fondo: un proyecto no está terminado porque el informe abre, sino cuando el sistema es fácil de usar, gobernable y valioso, y ya no depende de una demostración. El monitoreo de experiencia es lo que sostiene esa definición de terminado en el tiempo.
Cómo se sostiene esto cuando el sistema evoluciona
El monitoreo no es estático: cambia cuando el modelo semántico cambia. Por eso el comité de métricas (mensual o trimestral) existe para aprobar cambios de definición sin romper histórico ni consensos, y la lista de mejoras prioriza de forma continua nuevas preguntas, fuentes y automatizaciones.
Cuando esos cambios se mueven entre entornos, la observabilidad debe viajar con ellos. Ahí es donde una evolución controlada entre desarrollo, prueba y producción evita que una alerta funcione en un entorno y desaparezca en otro; el enfoque de deployment pipelines y ALM en Fabric trata esa continuidad. Si además estás moviéndote hacia Fabric desde otra plataforma, conviene revisar cómo se traslada la operación en una migración a Microsoft Fabric antes de dar por cerrado el monitoreo.
Definir señales, responsables, umbrales y respuesta es un trabajo de criterio operativo, no de configuración, y suele requerir mirar procesos y responsables antes que herramientas.
Empieza por una tabla de señales, no por una herramienta
Antes de activar Workspace Monitoring o comprar más capacidad, escribe en una sola página las tres capas (trabajos, capacidad, experiencia) y, para cada una, anota la señal concreta que la representa, el umbral que dispara una acción, el responsable que actúa y la respuesta esperada. Esa tabla, revisada en el control de cargas diario, convierte el monitoreo en una forma de trabajar en lugar de un tablero que nadie mira. Si quieres ver cómo se aplica este enfoque de señales, responsables y respuesta sobre un sistema real de datos e IA, mira la demo gratuita.
Preguntas frecuentes
¿Monitoring Hub reemplaza a Capacity Metrics?
No. Monitoring Hub responde por las ejecuciones (estados, fallos, duración) y sirve para el diagnóstico inicial, mientras Capacity Metrics explica el consumo de unidades y la sobrecarga. Son preguntas distintas y ninguna vista sustituye a la otra.
¿Cuándo conviene Workspace Monitoring en vez del Monitoring Hub?
Cuando el diagnóstico puntual del Hub no alcanza y necesitas historial consultable o alertas propias. Workspace Monitoring envía los eventos de ejecución a un Eventhouse y una base KQL, lo que permite investigar tendencias en el tiempo en lugar de mirar solo el estado actual.
¿Qué riesgo tiene pausar una capacidad de pago para ahorrar?
Pausar una capacidad puede dejar contenido no disponible para los usuarios. La operación no termina al enviar el comando: no está completa hasta verificar por API que el workspace y la capacidad muestran el estado esperado.
¿Basta con que las actualizaciones corran sin error para confiar en el sistema?
No. Un trabajo exitoso puede convivir con una capacidad saturada que entrega tarde, o con un usuario que ve un informe roto por permisos. Por eso la experiencia de consumo se prueba aparte, con el rol esperado y no solo con quien creó la solución.
¿Con qué frecuencia debería revisarse cada señal de operación?
El control de cargas es diario o según criticidad; la revisión de adopción, mensual; el comité de métricas, mensual o trimestral; y la higiene del workspace, según cambios grandes. Cada cadencia responde a un tipo de riesgo distinto.
