Grafana-Dashboard

Das mitgelieferte Betriebsdashboard in Application Insights — Erfolgsraten, Queue-Stände, Laufzeiten, Ausführungen und Fehler je Job, mit Job- und Zeitraster-Filter.

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:

VariableTypBedeutung
Bin Size (bin_size)Auswahl: 5m, 10m, 15m, 30m, 1h, 2h, 4h, 12h, 1d (Standard: 10m)Größe der Zeit-Fenster, in die die Zeitreihen-Panels ihre Werte gruppieren. Kleinerer Wert = feinere, aber unruhigere Kurven; größerer Wert = glattere Kurven über einen langen Zeitraum.
Job Namen (jobName)Mehrfachauswahl aus den tatsächlich aktiven Jobs, inkl. „All"Schränkt alle job-bezogenen Panels auf die gewählten Jobs ein. Die Liste wird live aus den letzten Metrik-Daten gezogen (Jobs, die aktuell nur 0 liefern, tauchen nicht auf — siehe unten).

Kopfzeile: Erfolgsraten und Queue-Stände

Immer sichtbar, sieben Kacheln:

KachelTypZeigt
GetChanges SuccessRateTacho (0–100 %)Erfolgsquote der Änderungserkennung
ProcessQueueItems SuccessRateTacho (0–100 %)Erfolgsquote der Verarbeitung, über alle drei Queues (Low/Standard/High) zusammengefasst
Active MessagesTachoAktuell wartende Nachrichten, summiert über alle drei Export-Queues (sbqexport, sbqhighexport, sbqlowexport)
DeadletterTachoNachrichten in den Dead-Letter-Queues, summiert über alle drei Export-Queues
LowTacho (0–100 %)Erfolgsquote der Verarbeitung niedriger Priorität
StandardTacho (0–100 %)Erfolgsquote der Verarbeitung mit Standard-Priorität
HighTacho (0–100 %)Erfolgsquote der Verarbeitung hoher Priorität

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

PanelTypInhalt
AusführungenBalkenErfolgreiche gegen fehlgeschlagene Läufe, gruppiert nach Bin Size
LaufzeitenVerlaufDurchschnittliche, minimale und maximale Laufzeit in Millisekunden, gruppiert nach Bin Size
GetChanges per JobsVerlaufErkannte Änderungen je Job — basiert auf der Custom Metric ChangesDetected mit der Dimension JobName; reagiert auf Job Namen

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:

PanelTypInhalt
AusführungenBalkenMessagesProcessed nach Ausgang (Success/Failed/Transitive), gruppiert nach Bin Size, gefiltert nach Job Namen
LaufzeitenVerlaufDurchschnittliche, minimale und maximale Verarbeitungsdauer (ProcessingDurationMs) über alle gefilterten Jobs zusammengefasst, gruppiert nach Bin Size
ProcessItems Success per JobVerlaufErfolgreich verarbeitete Nachrichten je Job (Outcome = Success), gruppiert nach Bin Size, gefiltert nach Job Namen
ProcessItems Errors per JobVerlaufFehlgeschlagene (Failed) und in eine Retry-Queue umgeleitete (Transitive) Nachrichten je Job, als getrennte Linien pro Job und Ausgang, gefiltert nach Job Namen

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.