Fabric Monitor: Refresh-Fehler systematisch überwachen

In Fabric-Umgebungen sammeln sich halbe Skripte an: ein Notebook, das Kapazitäten prüft, eine Shell-History, die fehlgeschlagene Jobs auflistet, eine Wiki-Seite mit Screenshots aus dem letzten Quartal. Jedes davon erzählt eine andere Geschichte über den Zustand. Die Rufbereitschaft sucht sich einen Favoriten aus. Coding Agents erben den Widerspruch.

Führe alles in einem bedienbaren Skill zusammen. Klare Verben schlagen Stammeswissen in der Shell-History. Agents, die Monitoring-Tools nutzen, brauchen stabile Ausgabeverträge. Trenne Diagnose von Behebung. Versioniere Runbooks wie Produktcode. Viele halbe Skripte erzeugen widersprüchliche Signale. Eine Schnittstelle erzeugt eine gemeinsame Wahrheit, die du verbessern kannst.

Abbildung 1. Ein bedienbarer Monitoring-Skill. Verben, Verträge und ein Runbook ersetzen widersprüchliche halbe Skripte.

Kontext und Rahmenbedingung

Ein typischer Fehler: Drei Antworten auf "ist Fabric gesund?" widersprechen sich noch vor dem Mittagessen. Keine ist für ihren engen Blickwinkel falsch. Zusammen bringen sie den Leuten bei, der Automatisierung zu misstrauen. Ein einziger Skill mit Verben und Verträgen sorgt dafür, dass Menschen und Agents dieselben Fragen stellen.

Skripte ohne Verträge driften. Verträge ohne Versionierung versteinern. Wenn Diagnose und Behebung vermischt sind, fühlt sich jede Prüfung gefährlich an. Eine Schnittstelle in Form eines Skills, mit Lese-Verben zuerst, gibt dir einen Ort für Tests, Doku und sichere Standardwerte.

Abbildung 2 zeigt den Monitoring-Hub aus Learn. Tabellen im Portal sind nützlich. Sie sind aber kein versionierter Skill mit stabilen Ausgabeverträgen für Agents.

Abbildung 2. Monitoring sollte eine bedienbare Schnittstelle mit stabilen Ausgaben sein, kein Haufen einmaliger Skripte. Quelle: Microsoft Learn: Monitoring-Hub.

Design

1. Ein Skill, viele Verben

Stelle list-failures, capacity-snapshot, job-status und lineage-neighbors als benannte Verben bereit. Operatoren lernen ein Menü. Agents rufen Tools auf, ohne Wiki-HTML zu scrapen. Neue Prüfungen werden zu neuen Verben, nicht zu neuen Repos.

2. Stabile Ausgabeverträge

Gib strukturierte Felder zurück: Workspace, Item, Status, Zeitfenster, Link. Menschen lesen Tabellen, Agents parsen JSON. Hübsch formatiertes Chaos ist kein Vertrag. Schema-Versionen gehören in den Header.

3. Diagnose vor Behebung

Verben, die nur lesen, sind der Standard. Verben, die etwas ändern (Retry, Cancel, Anfrage zum Skalieren), brauchen einen ausdrücklichen Bestätigungsmodus und Audit-Logs. Ein Monitor, der still Dinge repariert, ist ein Änderungsagent ohne Verantwortlichen. Abbildung 3 zeigt die Schranke.

Abbildung 3. Diagnose ist der Standardweg. Behebung ist abgesichert, auditiert und nie ein stiller Nebeneffekt einer Zustandsprüfung.

4. Widersprüchliche halbe Skripte abschaffen

Erfasse persönliche Skripte und überführe sie in den Skill oder ins Archiv, mit einem Verweis. Zwei Quellen der Wahrheit über den Zustand werden immer streiten. Konsolidieren heißt genauso viel Löschen wie Bauen.

5. Runbooks wie Produktcode versionieren

Lege das Markdown des Runbooks neben den Skill. Tagge Releases. Wenn sich die Semantik der Kapazität ändert, hebe Skill und Doku gemeinsam an. Mündliche Updates im Chat sind keine Versionskontrolle.

6. Ausdrücklich für Agents als Nutzer entwerfen

Coding Agents brauchen deterministische Tool-Ergebnisse und nicht interaktive Standardwerte. Vermeide Rückfragen mitten im Ablauf, die nur Menschen beantworten können. Wenn ein Verb eine Abwägung braucht, gib Kandidaten und Gründe zurück, keine offene Frage, die hängen bleibt.

Wie sich gutes Verb-Design anfühlt

Ein Verb benennt die Absicht eines Operators, kein API-Souvenir. "Fehlgeschlagene Pipeline-Läufe im Zeitfenster auflisten" ist besser als "diesen undokumentierten REST-Pfad aufrufen". Kapsle Plattform-APIs hinter dem Skill, damit Änderungen an der API nur eine Stelle treffen. Dokumentiere Rate Limits und nötige Berechtigungen direkt beim Verb. Wenn sich zwei Verben überschneiden, führe sie zusammen, bevor Agents beide lernen.

UX für Menschen und Agents trennen, ohne die Wahrheit aufzuspalten

Menschen mögen Zusammenfassungen und Links ins Fabric-Portal. Agents mögen kompaktes JSON. Bediene beide aus einem Vertrag: strukturierte Daten plus eine optionale Darstellungsschicht. Pflege kein "Skript für Menschen" und kein "Skript für Agents", die auseinanderlaufen. Der Skill ist gemeinsam, nur der Renderer unterscheidet sich. Abbildung 4 hält die Abzweigung aus der Wahrheitsschicht heraus.

Abbildung 4. Ein Vertrag, zwei Renderer. Menschen bekommen Tabellen und Links ins Portal. Agents bekommen kompaktes JSON. Der Skill bleibt gemeinsam.

Migrieren ohne Big Bang

Nimm die fünf häufigsten Fragen der Rufbereitschaft. Setze diese Verben zuerst um. Lass das Wiki auf den Skill verweisen. Lösche oder archiviere die alten Skripte nach Möglichkeit im selben PR. Ergänze Vertragstests, die Beispielausgaben einfrieren. Erweitere die Verben nur, wenn ein echter Incident eine Lücke zeigt. Konsolidierung scheitert, wenn sie den Ozean kochen will, bevor die erste nützliche Prüfung zur Mittagszeit läuft.

Berechtigungen und Least Privilege für Monitoring-Verben

Monitoring-Skills starten oft mit einer breiten Admin-Identität, weil das einfach ist. Das bringt Agents und Menschen die falsche Gewohnheit bei. Nutze für Diagnose-Verben Lese-Scopes und für die Behebung getrennte Identitäten oder Wege zur Rechteerhöhung. Dokumentiere, welche Workspace-Rollen jedes Verb braucht. Wenn ein Verb mehr verlangt, als es nutzt, schränke es ein. Least Privilege gehört zum Ausgabevertrag: Ein Tool, das still Pipelines löschen kann, ist kein Monitor.

Häufige Fehler

Skript-Museen. Alle haben eine andere Wahrheit.

Getarnte Behebung. Prüfungen verändern den Zustand.

Unstrukturiertes stdout. Agents halluzinieren den Status aus Fließtext.

Wiki-Drift. Screenshots, die älter sind als die Oberfläche der Plattform.

Kein Audit bei Änderungen. Retries ohne Spur.

Endlos viele Verben. Eine Krimskrams-Schublade mit CLI-Wrapper.

So übernehmen oder anpassen

So übernehmen

• Das Fabric Monitoring läuft auf einer einzigen, versionierten Skill- und Runbook-Schnittstelle zusammen.
• Verben haben Namen, sind dokumentiert und durch Ausgabeverträge abgesichert.
• Diagnose-Verben sind der Standard. Verben zur Behebung sind ausdrücklich, auditiert und abgesichert.
• Widersprüchliche persönliche Skripte werden stillgelegt oder mit Verweis archiviert.
• Runbooks werden mit dem Skill versioniert. Plattformänderungen heben beide an.
• Agents sind vollwertige Nutzer: nicht interaktiv, strukturiert, deterministisch.

Vor dem Einsatz anpassen

Einen Skill zu bauen kostet Packaging und Verantwortung. Mit Skript-Museen zu leben kostet bei jedem Incident. Strenge Ausgabeverträge bremsen spontanes Hacken und beschleunigen Automatisierung. Diagnose von Behebung zu trennen fügt einen Bestätigungsschritt hinzu. Beides zu vermischen fügt Überraschungen hinzu. Runbooks zu versionieren ist Zeremonie. Unversionierte Runbooks sind Fiktion.

Fazit

Wichtigste Quellen: der Fabric Monitoring-Hub und die Hinweise zu Kapazitätsmetriken auf Microsoft Learn, dazu deine internen Konventionen für Tool-Aufrufe durch Agents. Verbinde die README des Skills mit den Erwartungen an die Rufbereitschaft, damit Menschen und Agents dieselben Verben teilen.

Verben zusammenführen. Verträge einfrieren. Erst diagnostizieren, dann ändern. Das Runbook versionieren. Für Agents entwerfen, ohne die Menschen aufzugeben. Ein bedienbarer Skill schlägt ein Museum aus Fast-Monitoren.