Operations Agent für Fabric Pipelines

Eine Fabric Pipeline kann technisch erfolgreich sein und trotzdem ein Betriebsproblem verursachen: Sie benötigt plötzlich dreimal so lange, verarbeitet zu wenige Datensätze oder verzögert nachgelagerte Berichte. Ein reiner Status wie „Completed“ beantwortet nicht, ob der Prozess seine betrieblichen Anforderungen erfüllt.

Microsoft erweitert deshalb das Monitoring von Fabric Pipelines um KI-gestützte Analyse. Neben dem pipeline-spezifischen Operations Agent gehören inzwischen Fabric Observability Insights, ein überarbeitetes Workspace Monitoring und die Funktion „Investigate“ zum Bild. Der Operations Agent ist trotzdem kein selbstheilender Autopilot. Er ergänzt Telemetrie und definierte Regeln um Einordnung und Empfehlungen. Die Qualität der Ergebnisse hängt von Datenlage, Berechtigungen und dem Betriebsmodell ab.

Was ist der Operations Agent für Fabric Pipelines?

Der Operations Agent für Pipelines ist eine KI-gestützte Funktion in Microsoft Fabric Data Factory. Er lässt sich aus der Pipeline-Oberfläche heraus erstellen und auf eine Pipeline oder auf die Pipelines eines Workspaces ausrichten. Dafür erhält er Kontext zu Ausführungsläufen, Aktivitäten, Fehlern und Performance. Er kann Auffälligkeiten erkennen, mögliche Ursachen einordnen und Empfehlungen beispielsweise über Microsoft Teams bereitstellen.

Die pipeline-spezifische Integration unterstützt derzeit vor allem Health-Monitoring-Szenarien und befindet sich weiterhin in der Preview. Das ist von der allgemeinen Operations-Agent-Funktion in Fabric Real-Time Intelligence zu unterscheiden, die Microsoft bereits als allgemein verfügbar dokumentiert. Auch die neue Fabric-Observability-Untersuchung und weitere Investigator-Funktionen besitzen eigene Preview-Grenzen. Der Produktstatus einer Komponente darf daher nicht auf die gesamte Lösung übertragen werden.

Die Abgrenzung zu Fabric Data Agents ist ebenfalls wichtig: Data Agents helfen bei Fragen an unterstützte Datenquellen. Der Operations Agent bewertet dagegen betriebliche Zustände und schlägt Reaktionen auf erkannte Bedingungen vor. Das sind unterschiedliche Aufgaben, Datenzugriffe und Risikoprofile.

Warum erfolgreiche Pipelines trotzdem ein Problem sind

Klassisches Monitoring meldet fehlgeschlagene Läufe zuverlässig, übersieht aber ohne zusätzliche Regeln leicht schleichende Verschlechterungen. Eine tägliche Ladepipeline benötigt statt 20 plötzlich 70 Minuten. Ein Kopiervorgang verarbeitet ungewöhnlich wenige Datensätze. Eine Pipeline startet verspätet, obwohl alle Aktivitäten am Ende erfolgreich sind. Oder einzelne Aktivitäten werden mit jedem Lauf langsamer.

Pipeline Health bedeutet mehr als Erfolg oder Fehler. Entscheidend ist, ob der Datenprozess vollständig, rechtzeitig und innerhalb vereinbarter Betriebsparameter ausgeführt wird. Dafür braucht es eine Historie, nachvollziehbare Vergleichswerte und eine klare Definition, wann eine Abweichung relevant ist. Ein KI-Agent kann diese Einordnung unterstützen, aber er kann fehlende Qualitätsregeln nicht selbst ersetzen.

Fabric Observability Insights: Wie die Bausteine zusammenspielen

Mit Fabric Observability Insights hat Microsoft Ende September 2026 eine neue, noch in Public Preview befindliche Observability-Erfahrung vorgestellt. Sie verbindet mehrere Ebenen, die im Betrieb nicht verwechselt werden sollten.

Monitor Hub: Hier sieht das Betriebsteam Job-Läufe, ihren Status, Verlauf und ihre Ausführungshistorie. Der Hub beantwortet zunächst die Frage, welcher Lauf betroffen ist.

Workspace Monitoring: Es sammelt unterstützte Logs und Metriken in einer Monitoring-Datenbank und macht sie beispielsweise per Kusto Query Language (KQL) auswertbar. Diese Ebene liefert die technischen Beobachtungen, nicht automatisch eine Diagnose.

Operations Agent: Er überwacht definierte Bedingungen fortlaufend, bewertet verfügbare Signale und kann Empfehlungen oder konfigurierte Aktionen anstoßen. Dafür erzeugt beziehungsweise verwendet er Regeln und KQL-Abfragen, die fachlich kontrolliert werden müssen.

Investigate und Investigator: Die neue Schaltfläche „Investigate“ im Monitor Hub startet eine gezielte, dialogbasierte Untersuchung eines fehlgeschlagenen Pipeline-Laufs. Davon zu unterscheiden sind die angekündigten Investigator Insights, die bei erkannten Anomalien zusätzliche Muster, mögliche Ursachen und Auswirkungen untersuchen. Beides erzeugt Hypothesen und nächste Prüfschritte, keinen garantierten technischen Ursachenbeweis.

Diese Schichten bilden zusammen einen sinnvollen Weg von der Feststellung einer Auffälligkeit bis zu einer kontrollierten Reaktion. Sie sind aber nicht austauschbar: Ein Dashboard erkennt nicht automatisch alle Qualitätsprobleme, und eine Agentenempfehlung ist noch keine operative Freigabe.

Fabric Observability: Monitoring, Telemetrie, agentische Empfehlungen und gezielte Untersuchung im Zusammenspiel.

So funktioniert Workspace Monitoring technisch

Beim überarbeiteten Workspace Monitoring wird ein Monitoring Item eingerichtet. Die Daten lassen sich in ein Eventhouse dieses Monitoring Items oder in ein Monitoring Item eines anderen Workspaces derselben Azure-Region übertragen. Unterstützte Fabric-Artefakte schreiben nach Aktivierung der Datensammlung ihre Telemetrie in eine schreibgeschützte KQL-Datenbank. Die frühere Variante des Workspace Monitorings erzeugte ein Monitoring Eventhouse nach einem anderen Modell; bestehende Umgebungen müssen deshalb ihre tatsächliche Konfiguration prüfen.

Für Pipelines sind insbesondere Job-Ereignisse und Protokolle einzelner Aktivitäten relevant. Sie können Status, Laufzeiten, Job-Instanzen und konkrete Fehlermeldungen sichtbar machen. Welche Tabellen tatsächlich bereitstehen, hängt von den unterstützten Workloads und der erzeugten Aktivität ab. Ein nicht vorhandener Logeintrag ist kein Beweis dafür, dass der Fehler nicht stattgefunden hat.

Wichtige Grenzen: Die Erfassung beginnt erst nach Aktivierung; frühere Läufe werden nicht rückwirkend eingefügt. Die Standardaufbewahrung beträgt 30 Tage und kann über Datenrichtlinien angepasst werden. Die Monitoring-Datenbank ist schreibgeschützt. Ein Workspace kann jeweils nur ein Monitoring Item für die Telemetrieerfassung nutzen, und das gewählte Eventhouse-Ziel lässt sich später nicht einfach umstellen.

Damit bleibt eine zentrale Betriebsaufgabe bestehen: Protokollierung, Aufbewahrungszeit, Verantwortlichkeiten und erwartete Datenqualität müssen vor dem produktiven Pilot feststehen. Für längerfristige Trends reicht die standardmäßige Historie möglicherweise nicht aus.

Vom auffälligen Lauf zur überprüfbaren Diagnose

Ein Operations Agent kann Abweichungen anhand seiner Regeln erkennen und mit historischen Signalen vergleichen. Wenn eine Bedingung zutrifft, kann ein Reasoning-Schritt eine Empfehlung erzeugen. Investigator-Funktionen ergänzen gegebenenfalls korrelierte Muster, die vermutete Auswirkung und weitere Untersuchungsmöglichkeiten.

Eine belastbare Meldung sollte zwischen Beobachtung, Hypothese und Empfehlung unterscheiden. „Aktivität X lief 42 Minuten statt üblicherweise 12 Minuten“ ist eine Messung. „Möglicherweise liegt ein Engpass am Quellsystem vor“ ist eine Hypothese. „Prüfe die Quellabfragen und die Auslastung im betroffenen Zeitraum“ ist ein nachvollziehbarer nächster Schritt. Diese drei Aussagen dürfen nicht in eine scheinbar sichere Root-Cause-Diagnose zusammenfallen.

Bei „Investigate“ wird die Analyse derzeit gezielt für fehlgeschlagene Pipeline-Läufe im Monitor Hub gestartet. Sie läuft mit der Identität der angemeldeten Person, ist schreibgeschützt und löst keinen Neustart der Pipeline aus. Das Untersuchungsgespräch ist temporär: Nach dem Schließen oder Aktualisieren der Seite ist es nicht dauerhaft verfügbar. Wer betriebliche Nachweise benötigt, muss relevante Ergebnisse deshalb in den eigenen Incident-Prozess übernehmen und dort überprüfen.

Praxisbeispiel: Eine Pipeline läuft dreimal so lange

Eine täglich gestartete Pipeline lädt Daten aus einem operativen System in ein Lakehouse. Normalerweise benötigt sie 25 Minuten. Seit mehreren Tagen steigt die Laufzeit und überschreitet schließlich 60 Minuten. Eine klassische Fehlermeldung greift nicht, weil die Pipeline weiterhin erfolgreich abgeschlossen wird.

Der Operations Agent kann die erhöhte Laufzeit als definierte Abweichung erkennen und auffällige Aktivitäten benennen. Eine hilfreiche Nachricht enthält den Pipeline-Namen, die Run-ID, den Vergleich zur üblichen Laufzeit, die betroffenen Aktivitäten, die Entwicklung über mehrere Läufe und eine prüfbare Empfehlung. Die eigentliche Leistung liegt in der Verbindung von Signal, Kontext und Handlung – nicht in der Teams-Nachricht.

Fällt dieselbe Pipeline später vollständig aus, kann das Betriebsteam den betroffenen Lauf im Monitor Hub auswählen und „Investigate“ starten. Die interaktive Untersuchung kann Fehlerdetails mit der vorhandenen Historie verbinden. Ob der längere Vorlauf und der spätere Fehler dieselbe Ursache haben, muss anhand der technischen Evidenz geklärt werden. Der Agent darf hier keine nicht vorhandene Kausalität behaupten.

Wann reichen Alerts und Activator aus?

Nicht jedes Überwachungsszenario braucht ein Sprachmodell. Für bekannte Fehlerpfade ist eine feste Pipeline-Benachrichtigung oft die einfachste Lösung. Wenn ein eindeutiger Schwellwert oder eine KQL-Bedingung überwacht und eine vorher definierte Reaktion ausgelöst werden soll, eignet sich Fabric Activator. Ein Operations Agent gewinnt an Bedeutung, wenn mehrere Signale eingeordnet oder situationsabhängige Maßnahmen empfohlen werden sollen.

Die passende Entscheidung hängt vom Informationsbedarf ab: Feste Regel für bekannte Zustände, Operations Agent für kontextbezogene Bewertung, Investigate für die gezielte Analyse eines fehlgeschlagenen Laufs. Diese Komponenten lassen sich kombinieren, sollten aber nicht dieselbe Aufgabe dreifach ausführen. Eine zusätzliche KI-Ebene ist nur sinnvoll, wenn sie die Diagnosequalität oder Reaktionszeit tatsächlich verbessert.

Auch der Agent selbst braucht Observability

Ein Operations Agent kann falsch konfigurierte Bedingungen prüfen, übermäßig viele Empfehlungen erzeugen oder an fehlerhaften Aktionen scheitern. Deshalb hat Microsoft eine Performance-Ansicht für Operations Agents vorgestellt. Das dokumentierte Dashboard zeigt unter anderem Aktivitäten, ausgeführte Aktionen, Freigabeentscheidungen, Fehler und Fehlerraten. Zusätzlich kündigt Microsoft Transparenz über Monitoring- und Reasoning-Schritte sowie LLM-Nutzung an.

Diese Informationen sollten im Pilot nicht nur technisch betrachtet werden. Betriebsverantwortliche müssen erkennen können, ob Empfehlungen nützlich, wiederholbar und angemessen teuer sind. Dazu gehört der Vergleich von korrekten Warnungen mit Fehlalarmen, die Nachvollziehbarkeit der verwendeten Daten und die Frage, wie viele Empfehlungen menschlich korrigiert werden mussten.

Die neue Performance-Sicht ersetzt weder die Fabric Capacity Metrics App noch ein eigenes Incident-Protokoll. Für die laufende Bewertung braucht es sowohl Agentenverhalten als auch fachliche Ergebnisqualität und Capacity-Verbrauch.

Berechtigungen, Human Approval und sichere Aktionen

Beim fortlaufenden Operations Agent ist zwischen Agentenidentität und Ausführungsberechtigung zu unterscheiden. Microsoft weist jedem Agenten eine eigene Entra-Agent-ID zu; die Datenabfragen und Aktionen nutzen jedoch die delegierte Identität und Berechtigungen des Erstellers. Ändert sich nur der Empfänger einer Teams-Meldung, ändert sich diese Berechtigungsgrundlage nicht. Bei der interaktiven Fabric-Observability-Untersuchung wird dagegen die angemeldete Person verwendet, die mindestens Contributor-Zugriff auf den Workspace benötigt.

Ein Agent kann neben Nachrichten beispielsweise Fabric-Jobs oder Power-Automate-Prozesse anstoßen. Daraus entsteht ein anderes Risikoprofil als bei einer reinen Diagnose. Für produktionsnahe Szenarien sollten Datenzugriff, KQL-Abfragen, erlaubte Aktionen und die verantwortliche Person explizit festgelegt werden. Eine genehmigte Empfehlung ist nicht automatisch eine allgemein zulässige Änderung an produktiven Pipelines.

Workspace Outbound Access Protection kann zusätzlich den Versand an Teams sowie externe beziehungsweise workspaceübergreifende Aktionen einschränken. Der allgemeine Operations Agent ist zwar allgemein verfügbar, seine Unterstützung in Workspaces mit Outbound Access Protection hat jedoch eigene Preview-Grenzen. Power Automate und workspaceübergreifende Aktionen sind dort aktuell besonders eingeschränkt.

Für den Start empfiehlt sich ein Read-only-Pilot mit menschlicher Entscheidung über jede operative Maßnahme. Erst nach wiederholt belastbaren Ergebnissen können ausdrücklich freigegebene, risikoarme Reaktionen automatisiert werden. Wie wichtig die Trennung von Identität und wirksamer Berechtigung ist, zeigt auch die Governance-Perspektive bei OneLake Security.

Preview-Grenzen, Sprache und Fünf-Minuten-Takt

Die bestehenden Einschränkungen gelten nicht automatisch für alle neuen Funktionen gleichermaßen. Für den fortlaufend aktiven Operations Agent dokumentiert Microsoft weiterhin einen Abfragezyklus von fünf Minuten. Außerdem werden Geschäftsziele und Anweisungen derzeit auf Englisch formuliert. Seine Datenquelle benötigt geeignete Zeitinformationen, und das System unterstützt für den einzelnen Agenten nur eine Datenquelle zur gleichen Zeit.

Diese Aussagen betreffen das kontinuierliche Agent-Monitoring. Eine manuell gestartete Untersuchung eines fehlgeschlagenen Pipeline-Laufs ist kein regelmäßiger Fünf-Minuten-Poll. Auch ihre Voraussetzungen unterscheiden sich: Workspace Monitoring muss bereits aktiv sein, die Logdaten müssen vorliegen und die untersuchende Person benötigt die erforderlichen Berechtigungen.

Vor einem Piloten sind darüber hinaus Kapazität, Tenant-Einstellungen, Copilot- und Azure-OpenAI-Freigaben, Region sowie gegebenenfalls Verschlüsselungs- und Outbound-Vorgaben zu prüfen. Die Preview ist keine Zusage für vollständige Verfügbarkeit, Produktions-SLA oder fehlerfreie Empfehlungen.

Welche Kosten entstehen?

Für den allgemeinen Operations Agent fallen Fabric Capacity Units für Hintergrundverarbeitung, Copilot-gestützte Konfiguration und autonomes Reasoning an. Eventhouse-Abfragen, OneLake-Speicher und gegebenenfalls angebundene Power-Automate-Prozesse können weitere Kosten verursachen. Häufigkeit, Regelanzahl, Datenmenge und tatsächliche Auslösungen beeinflussen den Verbrauch. Ein zusätzlicher Agent verursacht nicht nur Implementierungs-, sondern laufende Betriebs- und Kontrollkosten.

Davon zu unterscheiden ist die On-Demand-Untersuchung in Fabric Observability Insights: Microsoft dokumentiert aktuell, dass für diese Untersuchung die Abrechnung noch nicht aktiviert ist. Das ist keine dauerhafte Kostenlos-Garantie; die Billing-Regeln können sich während der Preview ändern. Monitoring-Infrastruktur und andere Agentenaktivitäten können unabhängig davon Kapazität verbrauchen.

Ein Pilot sollte deshalb Agentenverbrauch und Infrastrukturkosten mit der Fabric Capacity Metrics App beobachten. Für die Gesamtbewertung der Plattformkosten müssen zusätzlich die üblichen Compute-, Storage- und Lizenzierungsfaktoren aus Microsoft Fabric Kosten verstehen berücksichtigt werden.

Vier Stufen für agentisches Pipeline Monitoring

Ein kontrollierter Einstieg lässt sich in vier Stufen organisieren. Beobachten: Das Team definiert relevante Betriebsbedingungen, sammelt Telemetrie und verifiziert Warnsignale. Erklären: Agentenanalysen ergänzen nachvollziehbare Hinweise zu betroffenen Aktivitäten, Veränderungen und möglichen Ursachen. Empfehlen: Der Agent schlägt einen begrenzten nächsten Schritt vor; die fachliche Entscheidung bleibt bei der zuständigen Person. Ausführen: Erst wiederholt geprüfte, risikoarme Aktionen werden technisch automatisiert und überwacht.

Die Übergänge sind bewusst nicht zeitgesteuert. Die nächste Stufe wird nur erreicht, wenn die vorherige zuverlässig funktioniert. Eine funktionierende agentische Schnittstelle ist noch keine belastbare Produktionslösung – derselbe Grundsatz gilt für die Integration des Remote Power BI MCP Servers in produktive Abläufe.

Vier Reifestufen für agentisches Pipeline Monitoring – Ausführung nur nach kontrollierter Freigabe.

So sollte ein Pilot aufgebaut sein

Beginne mit zwei oder drei Pipelines, deren Ausführungen regelmäßig stattfinden und deren historische Laufzeiten bekannt sind. Geeignet sind beispielsweise ein täglich laufender Datenimport, eine mehrstufige Transformation und eine besonders geschäftskritische Versorgung nachgelagerter Berichte. Für jede Pipeline müssen die erwarteten Ergebnisse, Zeitfenster und verantwortlichen Personen bekannt sein.

Definiere danach getrennte Testfälle für einen technischen Fehler, eine ungewöhnlich lange Ausführung, einen verspäteten Start und eine auffällige Datenmenge. Ein Fehlerfall prüft die interaktive „Investigate“-Funktion; schleichende Laufzeitänderungen prüfen das kontinuierliche Monitoring. So wird verhindert, dass eine einzelne erfolgreiche Demo als Beweis für die gesamte Architektur gilt.

Bewerte den Pilot anhand weniger harter Kriterien: Zeit bis zur Erkennung, Anteil zutreffender Hinweise, Fehlalarmquote, Dauer bis zur überprüften Diagnose, Nachvollziehbarkeit der Empfehlungen, zusätzlicher Capacity-Verbrauch und Pflegeaufwand für Regeln. Vergleiche die Ergebnisse mit dem bisherigen Ablauf ohne Agent. Der Pilot ist erfolgreich, wenn die Betriebsarbeit messbar besser wird – nicht wenn die KI besonders überzeugend formuliert.

Fehlen klare Zuständigkeiten, einheitliche Workspace-Strukturen oder belastbare Betriebskennzahlen, ist zunächst die technische und organisatorische Ausgangslage zu klären. Ein Data Strategy Check kann dabei helfen, Architektur, Governance und Betriebsprozesse gemeinsam einzuordnen.

Für wen lohnt sich der Operations Agent?

Die Kombination eignet sich besonders für Teams, die viele wiederkehrende Fabric Pipelines betreiben, bereits Workspace Monitoring eingerichtet haben und Ausfälle sowie schleichende Verschlechterungen anhand konkreter Ziele bewerten können. Mit wachsender Zahl an Workloads steigt der mögliche Nutzen einer konsistenten Diagnose- und Reaktionslogik.

Weniger sinnvoll ist sie bei wenigen einfachen Pipelines, fehlender historischer Telemetrie oder unklaren Verantwortlichkeiten. Wenn eine feste Regel den Sachverhalt ausreichend beschreibt, ist ein klassischer Alert oft günstiger und leichter zu kontrollieren. Je unreifer das Betriebsmodell, desto kleiner der Nutzen zusätzlicher Agentenlogik.

Häufige Fragen zum Operations Agent für Pipelines

Ist der Operations Agent allgemein verfügbar? Der allgemeine Operations Agent in Real-Time Intelligence ist allgemein verfügbar. Der pipeline-spezifische Operations Agent und die Fabric-Observability-Untersuchung werden weiterhin als Preview dokumentiert.

Kann der Agent eine fehlgeschlagene Pipeline automatisch reparieren? Er kann mögliche Ursachen aufzeigen und je nach Konfiguration Aktionen auslösen. Die interaktive „Investigate“-Funktion selbst ist jedoch schreibgeschützt und startet keine Jobs neu. Eine generelle, zuverlässige Selbstreparatur ist nicht zugesagt.

Benötige ich Workspace Monitoring? Die neuen Observability-Untersuchungen setzen aktiviertes Workspace Monitoring und verfügbare Logdaten voraus. Für die beschriebenen workspaceweiten Pipeline-Szenarien bildet die Monitoring-Datenbank die zentrale Telemetriegrundlage.

Ersetzt der Operations Agent Fabric Activator? Nein. Activator bleibt sinnvoll für fest definierte Regeln und Aktionen; der Agent ergänzt kontextbezogene Analysen und Empfehlungen.

Reagiert der Agent in Echtzeit? Das kontinuierliche Agent-Monitoring führt Abfragen laut aktueller Dokumentation alle fünf Minuten aus. Die interaktive Untersuchung eines fehlgeschlagenen Laufs wird dagegen gezielt gestartet.

Welche Sprache wird unterstützt? Für Geschäftsziele und Konfigurationsanweisungen des fortlaufenden Operations Agent dokumentiert Microsoft derzeit Englisch.

---

Fazit: Mehr Kontext, aber kein automatischer Betrieb

Der Operations Agent für Fabric Pipelines entwickelt sich von einer intelligenten Monitoring-Erweiterung zu einem Bestandteil einer breiteren Observability-Architektur. Monitor Hub, Workspace Monitoring, laufende Agentenüberwachung und gezielte Untersuchungen leisten dabei unterschiedliche Aufgaben. Gemeinsam können sie die Zeit zwischen einer Auffälligkeit, einer überprüften Diagnose und einer angemessenen Reaktion verkürzen.

Die Verantwortung für korrekte Diagnosen, Berechtigungen und produktive Aktionen bleibt beim Betriebsteam. Nur mit nachvollziehbarer Telemetrie, sauberen Regeln, begrenzten Aktionsrechten und überprüften Pilotkennzahlen wird aus einer interessanten Preview ein tragfähiger Baustein des Fabric-Betriebs.

---

Nächste Schritte

Wenn du den Betrieb deiner Fabric Pipelines stabilisieren willst, solltest du zuerst Monitoring-Daten, Verantwortlichkeiten und wiederkehrende Fehlerbilder gemeinsam bewerten. Die Microsoft-Fabric-Beratung der Daten-WG hilft dabei, einen passenden Pilotumfang zu definieren, die Sicherheits- und Capacity-Grenzen zu prüfen und technische Empfehlungen in kontrollierbare Betriebsprozesse zu übersetzen.

Für eine strukturierte Standortbestimmung eignet sich der Data Strategy Check. Wenn eure Fabric-Umgebung bereits läuft und kontinuierlich weiterentwickelt werden soll, kann das Consulting Abo die laufende technische Begleitung abdecken.