Fabric Monitor: ¿cómo vigilas los fallos de refresco de forma sistemática?

Los entornos de Fabric acumulan medios scripts: un notebook que revisa capacidades, un historial de shell que lista jobs fallidos, una página de wiki con capturas del trimestre pasado. Cada uno cuenta una historia distinta sobre la salud del sistema. La guardia elige su favorito. Los agentes de código heredan la contradicción.

Consolídalo todo en un solo skill operable. Los verbos claros ganan al historial de shell tribal. Los agentes que consumen herramientas de monitorización necesitan contratos de salida estables. Separa el diagnóstico de la remediación. Versiona los runbooks como código de producto. Muchos medios scripts generan señales contradictorias. Una sola interfaz crea una verdad compartida que puedes mejorar.

Figura 1. Un skill de monitorización operable. Verbos, contratos y un runbook sustituyen a los medios scripts contradictorios.

Contexto y restricción

Un fallo habitual: tres respuestas a "¿está sano Fabric?" se contradicen antes de comer. Ninguna es falsa desde su perspectiva limitada. Juntas enseñan a la gente a desconfiar de la automatización. Un único skill con verbos y contratos hace que personas y agentes se hagan las mismas preguntas.

Los scripts sin contratos derivan. Los contratos sin versiones se fosilizan. Mezclar diagnóstico y remediación hace que cada comprobación parezca peligrosa. Una interfaz con forma de skill, con los verbos de lectura primero, te da un sitio donde colgar pruebas, documentación y valores por defecto seguros.

La figura 2 muestra el centro de supervisión de Learn. Las tablas del portal son útiles, pero no son un skill versionado con contratos de salida estables para agentes.

Figura 2. La monitorización debería ser una interfaz operable con salidas estables, no un montón de scripts puntuales. Fuente: Microsoft Learn: centro de supervisión.

Diseño

1. Un skill, muchos verbos

Expón list-failures, capacity-snapshot, job-status y lineage-neighbors como verbos con nombre. Los operadores aprenden un menú. Los agentes llaman a herramientas sin hacer scraping del HTML de la wiki. Las comprobaciones nuevas se convierten en verbos nuevos, no en repos nuevos.

2. Contratos de salida estables

Devuelve campos estructurados: workspace, item, estado, ventana de tiempo y enlace. Las personas pueden leer tablas y los agentes pueden parsear JSON. El caos bien formateado no es un contrato. La versión del esquema va en la cabecera.

3. Diagnóstico antes que remediación

Los verbos de solo lectura son el comportamiento por defecto. Los verbos que modifican algo (reintentar, cancelar, pedir escalado) requieren un modo de confirmación explícito y registros de auditoría. Un monitor que arregla cosas en silencio es un agente de cambios sin responsable. La figura 3 es el control.

Figura 3. El diagnóstico es el camino por defecto. La remediación está protegida, auditada y nunca es un efecto secundario silencioso de una comprobación de salud.

4. Elimina los medios scripts contradictorios

Haz inventario de los scripts personales y retíralos, ya sea al skill o al archivo con una referencia. Dos fuentes de verdad sobre la salud siempre van a chocar. Consolidar es tanto un ejercicio de borrar como de construir.

5. Versiona los runbooks como código de producto

Guarda el markdown del runbook junto al skill. Etiqueta las releases. Cuando cambie la semántica de capacidad, sube la versión del skill y de la documentación a la vez. Las actualizaciones tribales en el chat no son control de versiones.

6. Diseña de forma explícita para agentes consumidores

Los agentes de código necesitan resultados de herramientas deterministas y valores por defecto no interactivos. Evita preguntas a mitad del proceso que solo una persona puede responder. Si un verbo necesita criterio, devuelve candidatos y motivos, no una pregunta que se queda colgada.

Cómo se siente un buen diseño de verbos

Un verbo nombra una intención del operador, no un souvenir de la API. Mejor "listar las ejecuciones de pipeline fallidas en la ventana" que "llamar a esta ruta REST no documentada". Envuelve las API de la plataforma detrás del skill para que los cambios de API afecten a un solo sitio. Documenta los límites de frecuencia y los permisos necesarios junto al verbo. Si dos verbos se solapan, fusiónalos antes de que los agentes aprendan los dos.

Separar la UX para personas y para agentes sin bifurcar la verdad

A las personas les gustan los resúmenes y los enlaces al portal de Fabric. A los agentes les gusta el JSON compacto. Sirve a los dos desde un mismo contrato: datos estructurados más una capa de presentación opcional. No mantengas un "script para personas" y un "script para agentes" que acaben divergiendo. El skill es compartido y solo cambia el renderizador. La figura 4 mantiene la bifurcación fuera de la capa de verdad.

Figura 4. Un contrato, dos renderizadores. Las personas reciben tablas y enlaces al portal. Los agentes reciben JSON compacto. El skill sigue siendo compartido.

Cómo migrar sin un big bang

Elige las cinco preguntas que más hace la guardia. Implementa esos verbos primero. Haz que la wiki apunte al skill. Borra o archiva los scripts antiguos en el mismo PR cuando sea posible. Añade pruebas de contrato que congelen salidas de ejemplo. Amplía los verbos solo cuando un incidente real muestre un hueco. La consolidación fracasa cuando intenta abarcarlo todo antes de la primera comprobación útil de la hora de comer.

Permisos y mínimo privilegio para los verbos de monitorización

Los skills de monitorización suelen empezar con una identidad de administrador amplia porque es fácil. Eso enseña un mal hábito a agentes y personas. Usa scopes de lectura para los verbos de diagnóstico e identidades separadas o caminos de elevación para la remediación. Documenta qué roles de workspace necesita cada verbo. Si un verbo pide más de lo que usa, recórtalo. El mínimo privilegio forma parte del contrato de salida: una herramienta que puede borrar pipelines en silencio no es un monitor.

Errores comunes

Museos de scripts. Cada uno tiene una verdad distinta.

Remediación disfrazada. Las comprobaciones modifican el estado.

stdout sin estructura. Los agentes se inventan el estado a partir de prosa.

Deriva de la wiki. Capturas más antiguas que la UI de la plataforma.

Sin auditoría al modificar. Reintentos sin rastro.

Verbos infinitos. Un cajón de sastre con un wrapper de CLI.

Úsalo tal cual o adáptalo

Úsalo tal cual

• La monitorización de Fabric converge en una única interfaz versionada de skill y runbook.
• Los verbos tienen nombre, están documentados y los cubren contratos de salida.
• Los verbos de diagnóstico son el comportamiento por defecto. Los de remediación son explícitos, auditados y protegidos.
• Los scripts personales contradictorios se retiran o se archivan con una referencia.
• Los runbooks se versionan con el skill. Un cambio de plataforma sube la versión de ambos.
• Los agentes son consumidores de primera clase: no interactivos, estructurados y deterministas.

Adáptalo antes de usarlo

Construir un skill cuesta empaquetado y responsabilidad. Vivir con museos de scripts cuesta en cada incidente. Los contratos de salida estrictos frenan el hackeo improvisado y aceleran la automatización. Separar diagnóstico y remediación añade un paso de confirmación. Mezclarlos añade sorpresas. Versionar los runbooks es ceremonia. Los runbooks sin versión son ficción.

Cierre

Referencias principales: el centro de supervisión de Fabric y la guía de métricas de capacidad en Microsoft Learn, además de tus convenciones internas de llamadas a herramientas para agentes. Acompaña el README del skill con las expectativas de la guardia para que personas y agentes compartan los mismos verbos.

Consolida los verbos. Congela los contratos. Diagnostica antes de modificar. Versiona el runbook. Diseña para agentes sin abandonar a las personas. Un skill operable gana a un museo de casi monitores.