Microsoft Fabric ya puede hacer accesibles los datos de Azure Monitor Log Analytics en OneLake sin exportarlos ni crear una segunda copia. La capacidad está en vista previa pública desde el 29 de julio de 2026 y admite los niveles Analytics, Basic y Auxiliary Logs. El dato permanece en el almacenamiento de Log Analytics; Fabric conecta con las mismas tablas Delta Parquet que utiliza internamente Azure Monitor.
La diferencia frente a otros tipos de mirroring es importante: aquí no existe una réplica que tenga que sincronizarse. El mirrored item conserva la conexión y los metadatos de los shortcuts. Al crearlo, Fabric añade un endpoint de Eventhouse y permite exponer las tablas seleccionadas a Real-Time Intelligence, KQL, Lakehouse, Spark o modelos de Power BI.
Qué problema evita
Para analizar telemetría fuera de Azure Monitor era habitual diseñar una exportación, mantener un pipeline y pagar almacenamiento duplicado. Este enfoque elimina esos tres componentes. Los datos nuevos aparecen en Fabric con una latencia similar a Azure Monitor y las tablas suelen tardar unos quince minutos en estar visibles tras crear el item.
El escenario más interesante no es copiar un dashboard operativo. Es combinar señales técnicas con contexto de negocio: relacionar una degradación con pedidos afectados, estudiar tendencias largas con Spark o construir un modelo de Power BI que mezcle disponibilidad y actividad comercial. Las políticas de retención y ciclo de vida siguen gobernándose en Azure Monitor.
Los permisos no viajan con el shortcut
Este es el punto que yo revisaría antes de cualquier prueba. Azure RBAC y los permisos del workspace de Fabric son sistemas independientes. Un usuario sin acceso directo a una tabla de Log Analytics podría leerla desde el mirrored item si sus permisos de Fabric se lo permiten. La protección por tabla, fila o columna configurada en Azure Monitor no se hereda automáticamente.
Para producción en el mismo tenant, Microsoft recomienda usar la identidad del workspace; para escenarios entre tenants se utiliza un service principal. La cuenta organizativa mediante OAuth encaja mejor en pruebas, porque la conexión deja de funcionar si esa persona abandona el tenant o pierde acceso. El tutorial oficial de configuración ayuda a validar roles y autenticación antes de exponer las tablas.
Límites y costes de la vista previa
No hay backfill histórico: solo aparecen los datos que llegan después de incorporar cada tabla. El acceso desde Fabric es de solo lectura, el límite orientativo es de unas quinientas tablas por mirrored item y algunas columnas de sistema no están disponibles. Las operaciones de purga requieren tratar Azure Monitor y el almacenamiento accesible desde OneLake por separado. La disponibilidad se limita a las regiones compatibles con Microsoft Fabric.
El mirroring no añade coste de pipeline ni almacenamiento duplicado. Azure Monitor sigue cobrando ingestión y retención; Fabric cobra el cómputo consumido por Eventhouse, Spark, Power BI y el resto de experiencias. Las lecturas entre regiones pueden generar egress, por lo que región y patrón de consulta forman parte del diseño económico.
Empezaría con un workspace no sensible, una identidad de workspace y un conjunto pequeño de tablas. Después comprobaría quién puede leer el mirrored item desde Fabric, mediría consumo y validaría el proceso de borrado. Mi valoración es que la arquitectura simplifica mucho el movimiento de datos, pero desplaza el esfuerzo hacia gobierno, identidad y coste de consulta. Que no exista una segunda copia no significa que no exista una segunda superficie de acceso.