Betrieb & Wartung

• 1: Logging & Telemetrie
• 1.1: Metriken
• 1.2: Performance & Laufzeiten
• 2: Monitoring & Alerts
• 3: Grafana-Dashboard
• 4: Updates & Upgrades

1 - Logging & Telemetrie

Die DataBridge steuert ihr Telemetrie-Volumen über zwei voneinander unabhängige Mechanismen:

• Gepuffertes Logging — Log-Einträge werden pro Funktionsausführung gesammelt und erst am Ende des Laufs, abhängig vom Ergebnis, selektiv gesendet.
• Sampling von Abhängigkeiten — ausgehende Aufrufe an Quell- und Zielsysteme werden nur anteilig gesendet, sofern sie erfolgreich und schnell waren.

Der zweite Mechanismus ist der eigentliche Kostenhebel: In einer Volumenanalyse über 90 Tage entfielen rund 78 % des gesamten Datenvolumens auf Abhängigkeiten und nur ein Bruchteil auf Log-Einträge.

Gepuffertes Logging — drei Lauf-Ergebnisse

Der Anteil der Information-Einträge im Normalbetrieb wird über TELEMETRY_INFO_SAMPLE_RATE gesteuert (Standard: 20 = 20 %). Die Stichprobe wird pro Eintrag gezogen — es entstehen also vereinzelte Traces aus allen Läufen, keine vollständigen Ketten. Lückenlose Ketten gibt es nur bei Warning- und Fehler-Läufen.

Trace-Level erreicht Application Insights nie

Sampling von Abhängigkeiten

Ausgehende Aufrufe an Quell- und Zielsysteme (D365 OData, SQL, Table Storage, Service Bus) werden von Application Insights automatisch als Dependencies erfasst. Ohne Filterung verursachen sie bei kurzem Polling-Intervall ein Vielfaches aller Log-Einträge zusammen.

Steuerung über TELEMETRY_CONTROL

Die Einstellung wirkt auf beide Mechanismen — Traces und Abhängigkeiten:

Eine leere Variable entspricht TRACE_SAMPLE. Details zu allen Telemetrie-Einstellungen stehen unter Umgebungsvariablen.

Auswirkung auf bestehende Auswertungen

Nicht betroffen sind:

• Fehleranzahlen und Fehlerursachen — fehlgeschlagene Aufrufe werden nie verworfen
• Auswertungen langsamer Aufrufe — ab dem Schwellwert immer vollständig
• Requests, Exceptions, Traces und Custom Metrics — unverändert

Wichtige Log-Felder in Application Insights

Automatisch erfasste Telemetrie

Neben den eigenen Log-Einträgen erfasst Application Insights selbstständig:

• Requests — je Funktionsausführung, mit Laufzeit und Erfolgskennzeichen
• Exceptions — jede aufgetretene Ausnahme mit Stack Trace
• Dependencies — jeder ausgehende Aufruf (unterliegt dem Sampling, siehe oben)

Auswertung im Azure Portal

Schnelle Übersicht — Performance Blade

Application Insights → Untersuchen → Leistung

Zeigt alle Funktionsausführungen mit Durchschnittslaufzeit und P50/P95/P99-Perzentilen. Ein hoher P95-Wert deutet auf gelegentliche Verzögerungen hin (langsames Zielsystem, Queue-Stau).

Fehlerdiagnose — Failures Blade

Application Insights → Untersuchen → Fehler

Fehlgeschlagene Aufrufe, gruppiert nach Fehlertyp, mit direktem Zugriff auf Stack Traces.

Einzelne Ausführung verfolgen — Transaction Search

Application Insights → Untersuchen → Transaktionssuche

Filter nach operation_Id, um alle Einträge einer einzigen Ausführung zu sehen.

Tipps für die Fehlersuche

1. operation_Id finden: Im Failures Blade auf einen fehlgeschlagenen Request klicken → End-to-End Transaction Details → operation_Id ist in der URL bzw. in den Details sichtbar.

2. Komplette Traces aktivieren: TELEMETRY_CONTROL = TRACE_ALL setzen, den problematischen Job über ExecuteJob manuell auslösen, anschließend zurücksetzen.

3. Zwischen Funktionen korrelieren: Schlägt eine der Process…QueueItems-Funktionen fehl, ist die operation_Id der ursprünglichen GetChanges-Ausführung in der Nachricht gespeichert — so lässt sich der vollständige Pfad eines Datensatzes nachvollziehen. Beachten Sie dabei die Einschränkung beim Dependency-Sampling (siehe oben).

1.1 - Metriken

Neben Traces und Requests sendet die dsyr.DataBridge eigene Custom Metrics an Application Insights. Metriken sind numerische Zeitreihen mit Dimensionen — sie eignen sich für Dashboards, Trend-Analysen und Metric Alerts, ohne dass dafür Log-Einträge durchsucht werden müssen.

Die Metriken werden über TelemetryClient.GetMetric() vorab aggregiert: Das SDK sammelt die Werte lokal in 1-Minuten-Intervallen und sendet pro Intervall und Dimensionskombination einen aggregierten Datenpunkt (Summe, Anzahl, Min, Max).

Verfügbare Metriken

Alle Metriken verwenden den Namespace DataBridge.

Anzeige in Azure

Metrics Explorer

Application Insights → Metriken → Namespace DataBridge auswählen → Metrik ChangesDetected. Als Aggregation eignet sich Summe (Anzahl Datensätze) oder Anzahl (Anzahl Läufe).

KQL (Logs)

Jeder aggregierte Datenpunkt landet zusätzlich in der Tabelle customMetrics:

customMetrics
| where name == "ChangesDetected"
| extend job = tostring(customDimensions["JobName"])
| summarize sum(valueSum) by bin(timestamp, 2m), job
| render timechart

Host-generierte Metriken (Functions-Runtime)

Zusätzlich zu den oben aufgeführten, selbst erzeugten Metriken schreibt die Azure-Functions-Runtime automatisch pro Funktion aggregierte Kennzahlen ebenfalls in die Tabelle customMetrics — ohne dass die DataBridge dafür Code enthält:

<FunctionName> Successes
<FunctionName> Failures
<FunctionName> SuccessRate
<FunctionName> AvgDurationMs
<FunctionName> MinDurationMs
<FunctionName> MaxDurationMs

<FunctionName> ist z. B. GetChanges, ProcessStandardQueueItems, ProcessLowPriorityQueueItems oder ProcessHighPriorityQueueItems. Diese Metriken sind Standardverhalten des Functions-Hosts (WebJobs SDK Function Result Aggregator) und daher in jeder Azure-Functions-App vorhanden, unabhängig von der DataBridge selbst. Das Grafana-Dashboard nutzt sie für die Kopfzeilen-Tachos und die Ausführungen/Laufzeiten-Panels der Zeile „GetChanges".

Limits

Konsequenz: Dimensionswerte müssen niedrig-kardinal sein — Job-Namen, Queue-Namen und Status-Codes sind geeignet; IDs, Zeitstempel oder Datensatz-Schlüssel nicht.

1.2 - Performance & Laufzeiten

Die folgenden Abfragen können direkt im Logs-Bereich von Application Insights (Kusto Query Language) ausgeführt werden.

Laufzeiten und Fehler

Laufzeiten aller Funktionen (letzte 24 Stunden)

requests
| where timestamp > ago(24h)
| summarize
    Aufrufe        = count(),
    DurchschnittMs = avg(duration),
    P95Ms          = percentile(duration, 95),
    Fehler         = countif(success == false)
  by name
| order by DurchschnittMs desc

Verlauf einer einzelnen Funktion (letzte 7 Tage)

requests
| where timestamp > ago(7d)
| where name == "GetChanges"
| summarize
    P50Ms  = percentile(duration, 50),
    P95Ms  = percentile(duration, 95),
    Fehler = countif(success == false),
    Läufe  = count()
  by bin(timestamp, 1h)
| order by timestamp asc

Durchschnittliche Laufzeit der letzten 30 Tage (täglich)

requests
| where timestamp > ago(30d)
| summarize
    DurchschnittMs = avg(duration),
    P95Ms          = percentile(duration, 95)
  by name, bin(timestamp, 1d)
| order by name asc, timestamp asc

Fehlerquote je Funktion (letzte 7 Tage)

requests
| where timestamp > ago(7d)
| summarize
    Gesamt    = count(),
    Fehler    = countif(success == false),
    FehlerPct = round(100.0 * countif(success == false) / count(), 1)
  by name
| order by FehlerPct desc

Warnungen und Fehler im Zeitverlauf

traces
| where timestamp > ago(7d)
| where severityLevel >= 2  // 2 = Warning, 3 = Error
| summarize Anzahl = count() by severityLevel, bin(timestamp, 1h), operation_Name
| order by timestamp asc

Top-10 häufigste Fehlermeldungen

exceptions
| where timestamp > ago(7d)
| summarize Anzahl = count() by outerMessage
| top 10 by Anzahl desc

Einzelne Ausführung nachvollziehen

Alle Einträge einer Ausführung (per operation_Id)

union requests, traces, exceptions
| where operation_Id == "<operation_Id hier einfügen>"
| project timestamp, itemType, severityLevel, message, outerMessage, operation_Name
| order by timestamp asc

Fehlerläufe mit allen zugehörigen Traces (letzte 24 Stunden)

let fehlgeschlagene =
    requests
    | where timestamp > ago(24h)
    | where success == false
    | project operation_Id, FunktionsName = name, Startzeit = timestamp;
traces
| where timestamp > ago(24h)
| join kind=inner fehlgeschlagene on operation_Id
| project Startzeit, FunktionsName, severityLevel, message
| order by Startzeit desc, severityLevel desc

Abhängigkeiten

Langsamste Abhängigkeiten (letzte 24 Stunden)

Zeigt die ausgehenden Aufrufe an Quell- und Zielsysteme mit den höchsten Laufzeiten:

dependencies
| where timestamp > ago(24h)
| summarize
    Aufrufe        = count(),
    DurchschnittMs = avg(duration),
    P95Ms          = percentile(duration, 95),
    Fehler         = countif(success == false)
  by type, target, name
| order by P95Ms desc
| take 20

Fehlgeschlagene Abhängigkeiten nach Zielsystem (letzte 7 Tage)

dependencies
| where timestamp > ago(7d)
| where success == false
| summarize Fehler = count() by type, target, resultCode
| order by Fehler desc

Datenvolumen und Kosten

Datenvolumen pro Tabelle

Wenn das tägliche Datenvolumen die konfigurierte Obergrenze (Daily Cap) erreicht, zeigt diese Abfrage, welche Tabelle den Verbrauch verursacht:

union withsource = Tabelle *
| where TimeGenerated > ago(7d)
| summarize VolumenMB = round(sum(_BilledSize) / 1024.0 / 1024.0, 1) by Tabelle, bin(TimeGenerated, 1d)
| order by TimeGenerated desc, VolumenMB desc

Hinweise zur Interpretation

Warum fehlen manche Traces bei erfolgreichen Läufen?

Das Buffering sendet bei erfolgreichen Läufen nur einen Teil der Information-Einträge und keine Debug-Einträge. Die Stichprobe wird pro Eintrag gezogen: Jede einzelne Information-Zeile hat unabhängig eine Chance von 20 % (konfigurierbar via TELEMETRY_INFO_SAMPLE_RATE), gesendet zu werden. Das führt zu einem gleichmäßigen Strom vereinzelter Traces — vollständige, lückenlose Ketten gibt es nur bei Warning- und Fehler-Läufen.

Trace-Einträge erreichen Application Insights grundsätzlich nie — sie sind nur live in der Konsole bzw. im Log Stream sichtbar.

Warum fehlen manche Abhängigkeiten?

Fehlgeschlagene und langsame Aufrufe kommen immer vollständig an, erfolgreiche und schnelle nur zu einem Anteil von 10 % (konfigurierbar via TELEMETRY_DEPENDENCY_SAMPLE_RATE).

Anders als bei den Log-Einträgen wird diese Entscheidung pro Aufruf getroffen — in dem Moment, in dem der Aufruf endet, also bevor das Ergebnis der Ausführung bekannt ist. In der End-to-End-Transaktionsansicht sind daher auch bei einem fehlgeschlagenen Lauf nicht zwangsläufig alle ausgehenden Aufrufe zu sehen. Für eine lückenlose Kette ist temporär TELEMETRY_CONTROL=TRACE_ALL zu setzen.

Requests vs. Traces vs. Dependencies

Für Laufzeit-Analysen der Funktionen immer die requests-Tabelle verwenden, für Laufzeiten einzelner Fremdsystem-Aufrufe die dependencies-Tabelle, für inhaltliche Diagnose die traces-Tabelle. Für belastbare Mengenangaben ausschließlich die Custom Metrics, da diese nicht gesampelt werden.

Korrelation über operation_Id

Jede Funktionsausführung erhält eine eindeutige operation_Id. Alle Traces, Requests und Exceptions dieser Invocation tragen dieselbe ID. Das erlaubt es, in KQL alle zusammengehörenden Einträge mit einem einzigen Filter zu finden.

2 - 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:

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

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:

Das Deployment erzeugt dabei auch die zugehörige Action Group (ag-<name>, Kurzname DLQAlert) — eine handangelegte Gruppe ist dafür nicht nötig.

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.

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:

Action Group: hier die zuvor angelegte Gruppe auswählen.

Empfohlene Alert Rules

requests
| where name == "GetChanges"
| summarize Executions = count() by bin(timestamp, 1h)

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.

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.

3 - Grafana-Dashboard

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.

Wo finde ich es?

Azure Portal → Application Insights-Ressource der DataBridge → Bereich „Dashboards with Grafana". Das Dashboard ist außerdem direkt von der Function App aus verlinkt.

Die Dashboard-Ressource selbst liegt als dash-<name> in derselben Ressourcengruppe. Es handelt sich nicht um eine eigene Azure-Managed-Grafana-Instanz, sondern um das in Application Insights integrierte Grafana-Feature.

Aufbau

Das Dashboard heißt DataBridge Dashboard und zeigt standardmäßig die letzten 7 Tage. Ein automatischer Refresh ist nicht eingestellt — die Aktualisierung erfolgt über den Refresh-Knopf bzw. beim Neuladen.

Filter (Dashboard-Variablen)

Oben im Dashboard stehen zwei Variablen zur Verfügung, die für (fast) alle Panels gelten:

Kopfzeile: Erfolgsraten und Queue-Stände

Immer sichtbar, sieben Kacheln:

Farbschwellen der vier SuccessRate-Tachos: rot ab 0 %, gelb ab 80 %, grün ab 95 %. Die beiden Service-Bus-Tachos (Active Messages, Deadletter) färben relativ zum aktuellen Wertebereich (grün → orange ab 70 % → rot ab 85 %), nicht anhand fester Nachrichtenzahlen — bei sehr wenigen Nachrichten insgesamt kann die Einfärbung daher empfindlicher wirken als bei einer großen Queue.

Alle sieben Kopfzeilen-Kacheln werten den im Dashboard gewählten Zeitraum aus (die SuccessRate-Kacheln über dashboardTime, die Service-Bus-Kacheln, weil Azure-Monitor- Platform-Metriken grundsätzlich immer an den Zeitraum gebunden sind).

Zeile „GetChanges"

Aufklappbar, drei Panels — Datenquelle sind hier weiterhin die von der Functions-Runtime automatisch erzeugten Host-Metriken (GetChanges Successes/Failures/AvgDurationMs/…), da GetChanges als Ganzes noch keine Job-granulare Erfolg/Fehler-Metrik im eigenen Code erzeugt (siehe Metriken):

Das Panel GetChanges per Jobs ist im Alltag das aussagekräftigste: Es zeigt pro Job, wie viele Änderungen erkannt wurden. Da auch Läufe ohne Änderungen den Wert 0 schreiben, bedeutet eine Lücke in der Kurve, dass der Job gar nicht gelaufen ist — nicht, dass es nichts zu tun gab.

Zeile „ProcessQueueItems"

Aufklappbar, vier Panels. Anders als bei GetChanges gibt es hier bereits eine job-granulare Custom Metric (MessagesProcessed, siehe Metriken), die zudem queue-übergreifend ist — alle drei Queues (Low/Standard/High) laufen durch denselben Verarbeitungscode und tauchen deshalb gemeinsam in einer Sicht auf, statt wie früher pro Queue getrennt zu sein:

Transitive bedeutet: die Nachricht wurde nicht endgültig verworfen, sondern in eine Retry-Queue (TransitiveLow/TransitiveStandard/TransitiveHigh) umgeleitet, weil eine TransitiveException aufgetreten ist — kein finaler Fehler, aber auch kein abgeschlossener Erfolg.

Zeile „Fehler-Überblick"

Aufklappbar, ein Panel: Heatmap — Anzahl der Ausnahmen (exceptions-Tabelle) je Zeitfenster (Bin Size), aufgeschlüsselt nach Exception-Typ.

Was das Dashboard nicht abdeckt

Damit klar ist, wofür weiterhin andere Werkzeuge nötig sind:

• Keine Job-genaue Fehlerursache für GetChanges — nur Timer-Lauf-Ebene, siehe Warnung oben. Für Details bleibt das Log (traces/exceptions) nötig.
• Keine Fehlerquoten über requests oder dependencies — hierfür die KQL-Abfragen verwenden.
• Keine Alarmierung — das Dashboard ist eine Ansicht, kein Alerting. Dafür sind die Alerts zuständig.

Eigene Anpassungen

Wer eine rein persönliche Ansicht braucht, legt sich im Portal ein eigenes, zusätzliches Dashboard an — dieses bleibt vom Deployment unberührt.

4 - Updates & Upgrades

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

1. Release Notes prüfen — Breaking Changes und Installationshinweise des Zielrelease und aller dazwischenliegenden Versionen lesen (Versionshistorie)
2. Wartungsfenster einplanen — GetChanges über ein App-Setting deaktivieren:

   AzureWebJobs.GetChanges.Disabled = true
   

   Bei Bedarf lassen sich die Verarbeiter analog abschalten (AzureWebJobs.ProcessStandardQueueItems.Disabled usw.)
3. Warten, bis alle Queue-Nachrichten verarbeitet wurden (Queue-Länge im Azure Portal prüfen)
4. 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
5. Konfigurationsanpassungen aus den Installationshinweisen vornehmen
6. GetChanges wieder aktivieren:

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

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

Breaking Changes je Version

Die vollständigen Breaking Changes und Installationshinweise stehen ausschließlich in den Release Notes der jeweiligen Version — hier nur der Überblick, ob ein Übergang überhaupt einen Breaking Change enthält:

Beim Überspringen von Versionen sind die Release Notes aller dazwischenliegenden Versionen zu beachten, nicht nur die des Zielrelease.