Monitoring & Alerts
Ein funktionierendes Monitoring erkennt Probleme, bevor sie auffallen. Die DataBridge kann über Azure Monitor Alert Rules so konfiguriert werden, dass bei Fehlern, Queue-Staus oder Dead-Letter-Einträgen automatisch Benachrichtigungen ausgelöst werden.
Aufbau des Alert-Systems
Das Azure-Alert-System besteht aus zwei Komponenten:
Alert Rule Action Group
────────────────── ──────────────────────────
Bedingung definieren → Wer wird benachrichtigt?
Scope: Ressource E-Mail, SMS, Webhook, Azure Role
Condition: KQL / Metric
Schwellwert festlegen
Empfohlene Reihenfolge:
- Zuerst die Action Group anlegen (Empfänger)
- Dann die Alert Rules darauf zeigen lassen
Action Group anlegen
Azure Portal → Monitor → Warnungen → Action Groups → Erstellen
| Einstellung | Empfehlung |
|---|---|
| Name | z. B. databridge-ops-team |
| Anzeigename | kurz (max. 12 Zeichen), erscheint in Alert-E-Mails |
| Aktionstyp | E-Mail/SMS/Push/Voice oder Azure-Rolle (z. B. alle „Contributor") |
Mitgeliefertes Dashboard
Unabhängig von Alerts liefert jede Installation ein vorkonfiguriertes Grafana-Dashboard mit — es zeigt Erfolgsraten je Funktion, Queue-Stände (aktive und Dead-Letter-Nachrichten, siehe unten) über alle drei Prioritäts-Queues, Laufzeiten, Ausführungen und erkannte Änderungen je Job sowie Exceptions. Es lässt sich zusätzlich nach Job und Zeitraster filtern. Es wird automatisch angelegt und erfordert keine Einrichtung.
Vorkonfigurierte Alerts (per Bicep)
Das Deployment kann Alert Rules für die Dead-Letter-Queue und die Queue-Länge mit anlegen. Sie sind standardmäßig deaktiviert:
Die Alerts entstehen nur, wenn beim Deployment enableAlerts = true gesetzt und eine
notificationEmail angegeben wird. Im Marketplace-Assistenten stehen beide unter
Product Settings → Alert. Ohne diese Angaben wird kein Alert angelegt.
Das Deployment erzeugt dabei auch die zugehörige Action Group (ag-<name>,
Kurzname DLQAlert) — eine handangelegte Gruppe ist dafür nicht nötig.
| Trigger | Standard-Schwellwert | Parameter | Prüfintervall | Severity |
|---|---|---|---|---|
| DLQ ≥ 1 | 1 Nachricht | dlqLowThreshold | 5 Minuten | 3 — Informational |
| DLQ > 50 | 50 Nachrichten | dlqMediumThreshold | 15 Minuten | 2 — Warning |
| DLQ > 200 | 200 Nachrichten | dlqHighThreshold | 30 Minuten | 1 — Error |
| DLQ > 500 | 500 Nachrichten | dlqCriticalThreshold | 5 Minuten | 0 — Critical |
| Queue-Länge > 300.000 | 300.000 Nachrichten | — | 15 Minuten | 2 — Warning |
Ausgewertet werden die Service-Bus-Metriken DeadletteredMessages bzw. ActiveMessages
über die Dimension EntityName = *, also je Queue einzeln. Alle Schwellwerte sind
beim Deployment als Parameter überschreibbar.
Die Regeln sind normale Metric Alerts mit aktiviertem Auto-Mitigate: Sie lösen bei Unterschreiten des Schwellwerts wieder auf („Entwarnung") und können danach erneut feuern.
Eigene Alert Rule anlegen
Azure Portal → Monitor → Warnungen → Warnungsregel erstellen
Beispiel: Fehler in GetChanges-Funktion
Scope: Application Insights-Ressource der DataBridge
Condition: Custom log search (KQL)
requests
| where operation_Name == "GetChanges"
| where success == false
| summarize FailedCalls = count() by bin(timestamp, 1h)
Alert-Logik:
| Einstellung | Wert |
|---|---|
| Messgröße | FailedCalls |
| Aggregationstyp | Maximum |
| Granularität | 1 Stunde |
| Operator | Größer oder gleich |
| Schwellwert | 1 (sofort bei erstem Fehler) oder 5 (bei mehreren Fehlern) |
| Prüfhäufigkeit | 1 Stunde |
Action Group: hier die zuvor angelegte Gruppe auswählen.
Empfohlene Alert Rules
| Rule | Scope | Bedingung | Schwellwert | Priorität |
|---|---|---|---|---|
| DLQ-Nachrichten vorhanden | Service Bus | DLQ Count > 0 | 1 | 🔴 Kritisch |
| Fehler in GetChanges | App Insights | Fehlgeschlagene Requests | 1/h | 🔴 Kritisch |
| GetChanges arbeitet nicht mehr | App Insights | Ausführungen pro Stunde kleiner als 1 | 1 | 🔴 Kritisch |
| Fehler in ProcessStandardQueueItems | App Insights | Fehlgeschlagene Requests | 5/h | 🟡 Warnung |
| Queue wächst unkontrolliert | Service Bus | Queue Length | 10.000 | 🟡 Warnung |
| Hohe Laufzeit | App Insights | P95 > 30.000 ms | 30 Sekunden | 🔵 Info |
Der wichtigste Alert ist derjenige auf ausbleibende Läufe — ein stehengebliebener Timer erzeugt keine Fehler und fällt sonst nicht auf:
requests
| where name == "GetChanges"
| summarize Executions = count() by bin(timestamp, 1h)
Operator Kleiner als, Schwellwert 1.
Alternativ metrikbasiert über die Custom Metric ChangesDetected: Da auch Läufe ohne
Änderungen den Wert 0 schreiben, bedeutet eine Lücke in der Serie, dass der Job
nicht gelaufen ist — siehe Metriken.
Der Schwellwert für die Queue-Länge ist hier bewusst strenger gewählt als der Deployment-Standard (300.000) — er schlägt an, lange bevor sich ein Rückstau aufbaut.
Fehlerquoten der Form countif(success == false) / count() über dependencies sind
seit v2.1 stark überhöht, weil erfolgreiche Aufrufe gesampelt werden, fehlgeschlagene
aber vollständig ankommen. Solche Alerts auf die Tabelle requests umstellen — sie
unterliegt keinem Sampling. Details unter
Logging.
Budget-Überwachung (empfohlen)
Zusätzlich zum operativen Monitoring empfiehlt sich eine Budget-Warnung auf Abonnement-Ebene:
Azure Portal → Cost Management → Budgets → Erstellen
- Budget für die Ressourcengruppe der DataBridge festlegen
- Alert bei 80 % und 100 % des Budgets
- Empfänger: gleiche Action Group wie operative Alerts
So werden unerwartete Kostensteigerungen (z. B. durch Queue-Stau und erhöhte Service Bus-Operationen) frühzeitig erkannt.