Betrieb & Wartung on dsyr.DataBridge

Monitoring & Alerts

Mon, 01 Jan 0001 00:00:00 +0000

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

Grafana-Dashboard

Mon, 01 Jan 0001 00:00:00 +0000

Seit v2.1 liefert jede Installation ein vorkonfiguriertes Grafana-Dashboard mit. Es zeigt auf einen Blick, ob die DataBridge läuft, wie schnell sie arbeitet und wo Fehler auftreten — ohne dass dafür KQL-Abfragen geschrieben werden müssen.

Ohne Zutun vorhanden

Das Dashboard wird bei jedem Deployment automatisch angelegt. Es gibt keinen Schalter zum Abwählen und keine manuelle Einrichtung. Zusätzliche Kosten entstehen nicht — die Abfragen laufen gegen die ohnehin vorhandene Application-Insights- und Service-Bus-Instanz.

Updates & Upgrades

Mon, 01 Jan 0001 00:00:00 +0000

Diese Seite beschreibt das Vorgehen bei einem Update. Die vollständigen Änderungen und Installationshinweise je Release stehen in der Versionshistorie.

Vorgehen bei einem Update

Die Konfiguration in Table Storage bleibt bei einem Update unverändert — es sei denn, ein Breaking Change erfordert Anpassungen.

Schritte

Release Notes prüfen — Breaking Changes und Installationshinweise des Zielrelease und aller dazwischenliegenden Versionen lesen (Versionshistorie)
Wartungsfenster einplanen — GetChanges über ein App-Setting deaktivieren:
```
AzureWebJobs.GetChanges.Disabled = true
```
Bei Bedarf lassen sich die Verarbeiter analog abschalten (AzureWebJobs.ProcessStandardQueueItems.Disabled usw.)
Warten, bis alle Queue-Nachrichten verarbeitet wurden (Queue-Länge im Azure Portal prüfen)
Neue Version einspielen — je nach Betriebsart:
- Container: Image-Tag auf die neue Version setzen
- Marketplace: Assistenten erneut durchlaufen (bei unveränderten Standardwerten ergibt sich keine Änderung an bestehenden Einstellungen)
- Bicep / Pipeline: Deployment erneut ausführen
- Zip-Upload: Paket über die Pipeline oder manuell einspielen
Konfigurationsanpassungen aus den Installationshinweisen vornehmen

GetChanges wieder aktivieren:

AzureWebJobs.GetChanges.Disabled = false (oder Eintrag löschen)

Ersten Lauf beobachten — z. B. über die Custom Metric ChangesDetected je Job oder die Fehlerquoten-Abfrage unter Performance & Laufzeiten

App-Settings lösen einen Neustart aus

Jede Änderung an den App-Settings startet die Function App neu. Das ist beim Ein- und Ausschalten der Funktionen in Schritt 2 und 6 eingeplant.