Von ADF-Webhook-Alarmen zu KI-gestützten Incident Reports.

Viele Azure-Data-Factory-Umgebungen verwenden ein vertrautes Muster:

Pipeline schlägt fehl → Web Activity → Teams-Webhook

Das war einfach und für eine grundlegende Benachrichtigung oft ausreichend. Doch ein Alarm mit dem Inhalt „Pipeline failed“ lässt die eigentliche Arbeit beim Bereitschafts- oder Data-Platform-Team: Was ist fehlgeschlagen? Ist ein Retry sinnvoll? Wer sollte übernehmen?

Warum jetzt mehr als nur den Webhook ersetzen?

Microsoft hat die früheren Microsoft-365-Connectors in Teams im Mai 2026 endgültig eingestellt. Für Webhook-Szenarien führt der unterstützte Weg heute über Power-Automate-basierte Teams Workflows.

Das ist ein guter Zeitpunkt, nicht nur eine URL auszutauschen. Die Migration kann genutzt werden, um aus einer technischen Fehlermeldung einen konsistenten ersten Incident Report zu machen.

Die Zielidee lautet:

ADF-Fehler → Log Analytics → Azure Monitor Alert → Logic App oder Function → Azure OpenAI → Teams Adaptive Card

Dabei ist Azure OpenAI nicht die Quelle der Wahrheit. Das Modell formuliert und strukturiert. Maßgeblich bleiben die erfasste Telemetrie, definierte Ownership-Metadaten und etablierte Runbooks.

Was im Datenfluss tatsächlich passiert

1. Telemetrie erfassen. Diagnostic Settings senden relevante Pipeline-, Activity- und Trigger-Logs an Log Analytics. Im empfohlenen resource-specific Modus stehen dafür unter anderem ADFActivityRun, ADFPipelineRun und ADFTriggerRun bereit.

2. Fehler erkennen. Eine KQL-Abfrage identifiziert relevante fehlgeschlagene Läufe. Ein Azure Monitor Log Search Alert löst eine Action Group aus – Log Analytics ruft eine Logic App oder Function nicht selbstständig auf.

3. Kontext vorbereiten. Die Logic App oder Azure Function liest nur freigegebene Felder, entfernt sensible Inhalte und ergänzt bei Bedarf gepflegte Metadaten wie Service, Kritikalität, Owner und Runbook.

4. Strukturiert anreichern. Azure OpenAI erhält einen kontrollierten Prompt und soll ein festes JSON-Schema liefern: Kurzfassung, mögliche Ursache, empfohlene Schritte, Retry-Hinweis und vorgeschlagene Zuständigkeit. Die Antwort wird validiert, bevor sie weiterverarbeitet wird.

5. In Teams ausliefern. Ein Teams Workflow nimmt den HTTP-Request entgegen und veröffentlicht die Informationen als Adaptive Card im vorgesehenen Kanal oder Chat.

6. Fallback garantieren. Wenn die KI-Anreicherung ausfällt, wird trotzdem eine klassische Karte mit Pipeline, Activity, Fehlercode, Fehlermeldung, Run-ID und Runbook-Link gesendet.

Die ADF-Diagnosekonfiguration weist darauf hin, dass Logs mit Verzögerung in Log Analytics eintreffen können. Dieses Muster ist deshalb near-real-time und muss gegen die Reaktionsanforderungen der jeweiligen Umgebung geprüft werden.

Vom Signal zur nächsten sinnvollen Aktion

Eine klassische Meldung liefert häufig nur:

Pipeline failed.

Ein angereicherter Incident Report könnte dagegen so aussehen:

Kurzfassung

Die Kundenintegration ist während der Copy Activity fehlgeschlagen, nachdem die Quell-API ein Timeout gemeldet hat.

Empfohlener nächster Schritt

Lauf einmal wiederholen, Verfügbarkeit der Quell-API prüfen und bei erneutem Fehler an das Data-Platform-Team eskalieren.

Das Operations-Team erhält damit einen Ausgangspunkt für die Analyse statt eines isolierten Signals. Ursache und Handlungsempfehlung bleiben KI-generierte Einschätzungen und müssen als solche erkennbar sein.

Welche Daten sind wirklich vorhanden?

Die beiden wichtigsten resource-specific Tabellen ergänzen sich:

• ADFActivityRun kann unter anderem PipelineName, ActivityName, Status, ErrorCode, ErrorMessage, PipelineRunId und ActivityRunId enthalten.
• ADFPipelineRun stellt unter anderem PipelineName, Status, ErrorCode, ErrorMessage und RunId bereit.

Geschäftliche Auswirkung und zuständiges Team lassen sich daraus nicht zuverlässig ableiten. Diese Felder sollten nur ausgegeben werden, wenn zusätzlich gepflegte Business- und Ownership-Metadaten verfügbar sind. Sonst lautet eine ehrliche Antwort: „nicht aus der vorhandenen Telemetrie bestimmbar“.

Leitplanken für einen kontrollierten Einsatz

• Allowlist statt vollständigem Logdump: Nur notwendige und bereinigte Telemetriefelder an das Modell senden.
• Fehlertext als nicht vertrauenswürdig behandeln: Externe Inhalte strikt von Systemanweisungen trennen und auf indirekte Prompt Injection vorbereiten.
• Keine Secrets oder Tokens: Identitäten und Zugriffe möglichst über Managed Identity und Least Privilege absichern.
• Striktes Ausgabeformat: Structured Outputs beziehungsweise ein validiertes JSON-Schema nutzen.
• Fakten und Einschätzungen trennen: Telemetriewerte unverändert anzeigen; mögliche Ursache und Empfehlung deutlich kennzeichnen.
• Deterministischer Fallback: Timeouts, Throttling, Content Filter oder Schemafehler dürfen den eigentlichen Alarm nie unterdrücken.
• Begrenzte Retries: Wiederholungen mit Backoff und klarer Obergrenze ausführen.
• Betriebsfähigkeit sicherstellen: Teams Workflows haben konkrete Owner. Mindestens ein Co-Owner verhindert, dass ein produktiver Flow beim Ausscheiden einer Person verwaist.

Microsoft dokumentiert sowohl die verfügbaren Action-Group-Ziele als auch Sicherheitsleitplanken für AI-Workloads. Beides gehört zur Architektur – nicht erst in eine spätere Härtungsphase.

Pragmatisch starten

Ein sinnvoller Proof of Concept muss nicht sofort jeden Fehler erklären:

1. Eine relevante Pipeline und ein klar definiertes Fehlerbild auswählen.
2. Zuerst den nicht KI-basierten Alerting- und Fallback-Pfad stabil aufbauen.
3. Erlaubte Telemetriefelder, Owner und Runbook vertraglich definieren.
4. Die KI-Ausgabe auf wenige strukturierte Felder begrenzen.
5. Ergebnisse mit dem Operations-Team bewerten und Fehlklassifikationen dokumentieren.
6. Erst danach weitere Pipelines, Fehlerklassen oder automatische Aktionen ergänzen.

Der eigentliche Mehrwert

Die Chance liegt nicht nur darin, einen alten Webhook zu ersetzen. Richtig umgesetzt, kann das Muster die erste Einordnung beschleunigen, Meldungen vereinheitlichen und den Weg zum zuständigen Team verkürzen.

Es ersetzt weder Monitoring noch erfahrene Operations-Teams. Es macht vorhandene Telemetrie schneller nutzbar – und aus einer Meldung eher eine nächste sinnvolle Aktion.

Quellen und weiterführende Dokumentation

• Retirement of Office 365 connectors within Microsoft Teams
• Create Incoming Webhooks with Teams Workflows
• Configure diagnostic settings for Azure Data Factory
• Create Azure Monitor log search alert rules
• Create and manage Azure Monitor action groups
• Structured Outputs with Azure OpenAI
• Azure AI security best practices
• Transient fault handling