# Monitoring & Alerts

> Azure Alert Rules und Action Groups für die automatische Überwachung der DataBridge.

---

Site [llms.txt](/llms.txt)

---

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:**
1. Zuerst die **Action Group** anlegen (Empfänger)
2. 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](../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**:

> **Alerts müssen aktiviert werden**
>
> 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.

> **Auto-Mitigate statt einmaliger Meldung**
>
> 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)

```kusto
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 |

> **Stillstand erkennen**
>
> Der wichtigste Alert ist derjenige auf **ausbleibende** Läufe — ein stehengebliebener
> Timer erzeugt keine Fehler und fällt sonst nicht auf:
> 
> ```kusto
> 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](../logging/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.

> **Keine Alerts auf die Tabelle `dependencies`**
>
> 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](../logging/#auswirkung-auf-bestehende-auswertungen).



---

## 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.