Monitoring¶
Das Monitoring ist auf zwei Ebenen aufgeteilt: Das Plattform-Team überwacht die Plattform-Komponenten, das Workload-Team überwacht seine eigenen Workloads. Optionale Grafana-Dashboards geben beiden einen Blick auf die Gesundheit der pipelines.
Referenzdesign, dein Deployment kann abweichen
Wer Alerts erhält und welche optionalen Teile (Grafana, Purview) deployt sind, wird pro Plattform festgelegt. Frag dein Plattform-Team. Das generische Plattform-Monitoring ist unter Monitoring beschrieben.
Plattform-Monitoring (Plattform-Team)¶
| Komponente | Was überwacht wird |
|---|---|
| Fabric capacity | Verbrauch an capacity units, Throttling-Ereignisse und Auslastung, über das Fabric Admin Portal. So kann das Plattform-Team hochskalieren, bevor die Last die capacity erreicht. |
| VNet data gateway | Verfügbarkeit, Anzahl der Verbindungen und Latenz. Das Gateway schläft nach Inaktivität ein und wacht bei einer neuen Anfrage auf, deshalb zählt der Aktivierungszyklus, wenn du die Verbindungsperformance beurteilst. |
| Storage Account | Verfügbarkeit, Latenz und Kapazitätsnutzung |
| Verbindungen | Verfügbarkeit der Verbindungen zu ADLS, SQL, Oracle Cloud Storage und von workspace zu workspace |
| Alerts | Abweichungen werden den Administratoren gemeldet. Diagnose- und Logdaten werden zentral für Analysen gespeichert. |
Baseline-pipelines¶
Das Plattform-Team überwacht die Baseline-pipelines der Plattform. Schlägt eine pipeline fehl, führt das Plattform-Team einen Retry aus. Die Ursache liegt meist an der Quelle, und ein Retry löst das Problem in den meisten Fällen. Hilft der Retry nicht, meldet das Plattform-Team es dem Team, dem die pipeline gehört.
Workload-Monitoring (Workload-Team)¶
| Bereich | Was du tust |
|---|---|
| Pipeline-Ausführung | Data pipelines liefern Laufstatus, Dauer und Fehlermeldungen. Wenn ein Retry des Plattform-Teams den Fehler nicht löst, löst das Data-Team des Workloads das Datenproblem. |
| Query-Performance | Dauer, Ressourcenverbrauch und Timeouts auf Lakehouses und Warehouses |
| Datenqualität und Aktualität | Rechtzeitigkeit der Ladevorgänge, Anzahl verarbeiteter Datensätze, Validierungsfehler |
| Natives Monitoring | Jeder workspace hat eingebautes Monitoring für die Ausführung von Items, die Ressourcennutzung und Fehler. Nutze es als Ausgangspunkt und ergänze eigene Alerts auf workload-spezifische Schwellenwerte. |
Siehe auch Deinen Workload betreiben.
Pipeline-Observability mit Grafana (optional)¶
Wenn der Observability Tier deployt ist, bekommst du eine Azure Managed Grafana-Instanz mit einem Dashboard und einem Alert auf fehlgeschlagene Fabric-pipeline-Läufe. Wie sie deployt wird, steht unter Observability.
flowchart LR
p["Fabric pipelines"] --> lh["pipeline_logs Lakehouse"]
lh -->|"log ingestion pipeline (your team)"| law["Log Analytics: FabricPipelineRuns"]
law --> g["Managed Grafana: dashboards"]
law --> a["Alert rule: pipeline failures"]
a --> ag["Action group: email"]Die Dashboards bleiben leer, bis dein Team sie befüllt
Die Dashboards lesen die Tabelle FabricPipelineRuns in Log Analytics. Das Grafana-Deployment erstellt oder befüllt sie nicht.
Dein Data-Engineering-Team baut die Log-Ingestion-pipeline. Bis sie läuft, zeigen die Panels „No data“.
Zugriff¶
Melde dich mit deinem Entra-ID-Konto an (MFA gilt). Es gibt standardmäßig keine lokalen Grafana-Konten und keine API Keys. Die URL
nennt das Plattform-Team, sie hat die Form https://grafana-<workload>-<env>-<region>.<id>.grafana.azure.com. Im privaten
Modus brauchst du VPN oder ExpressRoute.
Der Zugriff läuft über drei eigene Entra-ID-Gruppen, getrennt von den Fabric-workspace-Gruppen:
| Rolle | Für | Kann |
|---|---|---|
| Viewer | Business Stakeholder, Management | Dashboards und Alerts ansehen, Zeitbereich, Filter und Drill-down nutzen |
| Editor | Data Engineers und Analysten | Alles, was ein Viewer kann, plus Dashboards erstellen und bearbeiten und Alert-Regeln verwalten |
| Admin | Das Plattform-Team | Alles, was ein Editor kann, plus Data Sources, Plugins, Benachrichtigungskanäle, Nutzer und Organisationseinstellungen |
Ein Nutzer hat eine Grafana-Rolle. Beantrage den Zugriff über Anfragen und Änderungen: Nenne die Person und die Rolle. Das Plattform-Team fügt die Person der Gruppe hinzu, und der Zugriff gilt, nachdem sich die Gruppenmitgliedschaft verbreitet hat (die Quelle nennt 5 bis 10 Minuten). Um den Zugriff zu entfernen, beantrage das Entfernen aus der Gruppe.
Das Standard-Dashboard¶
Fabric Pipeline Observability hat diese Panels:
| Panel | Zeigt |
|---|---|
| Pipeline failures (last 24 h) | Anzahl fehlgeschlagener Läufe. Grün bei 0, gelb bei 1 bis 4, rot ab 5. |
| Pipeline runs by status | Anteil erfolgreicher, fehlgeschlagener, laufender und abgebrochener Läufe |
| Pipeline execution timeline | Läufe pro 15 Minuten, nach Status aufgeteilt |
| Recent failed pipelines | Die letzten 50 fehlgeschlagenen Läufe mit Zeit, pipeline, Run-ID, Dauer und Fehlermeldung |
| Average pipeline duration (7 days) | Stündlicher Durchschnitt pro pipeline, um langsamere pipelines zu erkennen |
| Pipeline success rate (7 days) | Gauge. Grün ab 95%, gelb ab 80%, rot unter 80%. |
Dashboards aktualisieren sich alle 30 Sekunden. Dashboards, die aus Code deployt werden, lassen sich in der Grafana-Oberfläche nicht bearbeiten: Ändere den Code. Dashboards, die ein Editor in der Oberfläche erstellt, sind nicht im Code und überstehen ein erneutes Deployment nicht.
Eigene Dashboards¶
In der Oberfläche: Füge eine Visualisierung hinzu, wähle die Data Source Azure Monitor, den Query-Typ Logs, wähle den Log-Analytics-workspace und schreibe die KQL. Speichere es in einem Ordner.
Als Code (bevorzugt für Dashboards, die bleiben sollen): Exportiere das Dashboard-JSON, ersetze die Log-Analytics-Resource-ID durch die
Template-Variable ${LAW_RESOURCE_ID}, maskiere Grafana-Template-Variablen wie ${DS_AZURE_MONITOR} als
$${DS_AZURE_MONITOR} und lege die Datei in einem Unterordner des Dashboards-Verzeichnisses deines Konfigurations-Repositorys ab. Jeder
Unterordner wird zu einem Grafana-Ordner und jede .json-Datei zu einem Dashboard. Führe die pipeline aus.
Beispiel-Queries:
// Runs per day by status
FabricPipelineRuns
| where TimeGenerated >= ago(30d)
| summarize Count = count() by bin(TimeGenerated, 1d), Status
| order by TimeGenerated asc
// Ten slowest successful pipelines
FabricPipelineRuns
| where TimeGenerated >= ago(7d) and Status == "Succeeded"
| extend DurationSeconds = datetime_diff('second', EndTime, StartTime)
| summarize AvgDuration = avg(DurationSeconds), MaxDuration = max(DurationSeconds) by PipelineName
| top 10 by AvgDuration desc
Alerts¶
Der Standard-Alert löst aus, wenn ein pipeline-Lauf fehlgeschlagen ist.
| Einstellung | Default | Konfigurierbar |
|---|---|---|
| Auswertungsintervall | alle 5 Minuten | ja |
| Lookback-Fenster | 1 Stunde | ja |
| Bedingung | jeder fehlgeschlagene pipeline-Lauf | nein |
| Severity | 1 (Error) | nein |
| Auto-Mitigation | der Alert löst sich, wenn das nächste Fenster keine Fehler hat | nein |
| Benachrichtigung | E-Mail über eine Azure-Monitor-Action-Group | ja (Adressen) |
Ohne E-Mail-Adressen löst der Alert trotzdem aus und ist in Azure Monitor sichtbar, aber niemand erhält eine E-Mail. Andere Empfänger als E-Mail (SMS, Webhook, Logic App) setzt die Konfiguration nicht: Das Plattform-Team ergänzt sie in der Action Group im Portal. Editoren können in der Grafana-Oberfläche weitere Alert-Regeln erstellen.
Grenzen, die du kennen solltest¶
- Eine Rolle pro Nutzer und keine Berechtigungen auf Ordnerebene: Jeder Nutzer mit einer Rolle sieht alle Dashboards, und Editoren können alle bearbeiten. Ordner dienen nur der Organisation. Wenn du Trennung brauchst, frag nach einer eigenen Grafana-Instanz für dieses Team.
- Das Standard-Dashboard nutzt den ersten Log-Analytics-workspace der Liste. Bei Dashboards über mehrere workspaces muss das Dashboard-JSON angepasst werden.
- Nach dem ersten Deployment brauchen die Rollen der managed identity bis zu 10 Minuten, bis sie sich verbreiten. Queries können in dieser Zeit mit „Insufficient permissions“ fehlschlagen.
Verwandte Themen¶
- Observability (Plattform-Team)
- Servicebeschreibung