# Grafana-Dashboard > Das mitgelieferte Betriebsdashboard in Application Insights — Erfolgsraten, Queue-Stände, Laufzeiten, Ausführungen und Fehler je Job, mit Job- und Zeitraster-Filter. --- Site [llms.txt](/llms.txt) --- 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. ## 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-` 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: | Variable | Typ | Bedeutung | |---|---|---| | **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). | > **Nicht jedes Panel reagiert auf beide Filter** > > Die Kopfzeilen-Gauges sowie die beiden Service-Bus-Gauges kennen keine Job-Dimension > und reagieren daher nicht auf **Job Namen** — sie sind Aggregate über die jeweilige > Funktion bzw. Queue. Alle Panels in den drei aufklappbaren Zeilen unten reagieren auf > **Bin Size**; die job-bezogenen darunter zusätzlich auf **Job Namen**. ### Kopfzeile: Erfolgsraten und Queue-Stände Immer sichtbar, sieben Kacheln: | Kachel | Typ | Zeigt | |---|---|---| | **GetChanges SuccessRate** | Tacho (0–100 %) | Erfolgsquote der Änderungserkennung | | **ProcessQueueItems SuccessRate** | Tacho (0–100 %) | Erfolgsquote der Verarbeitung, **über alle drei Queues (Low/Standard/High) zusammengefasst** | | **Active Messages** | Tacho | Aktuell wartende Nachrichten, **summiert über alle drei Export-Queues** (`sbqexport`, `sbqhighexport`, `sbqlowexport`) | | **Deadletter** | Tacho | Nachrichten in den Dead-Letter-Queues, **summiert über alle drei Export-Queues** | | **Low** | Tacho (0–100 %) | Erfolgsquote der Verarbeitung niedriger Priorität | | **Standard** | Tacho (0–100 %) | Erfolgsquote der Verarbeitung mit Standard-Priorität | | **High** | Tacho (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). > **Frühere Einschränkung entfällt** > > Bis einschließlich v2.2 folgten die vier SuccessRate-Kacheln dem Dashboard-Zeitraum > **nicht** und zeigten stattdessen einen festen Wert. Das ist seit der Überarbeitung des > Dashboards behoben — alle Kopfzeilen-Kacheln sind jetzt zeitraum-sensitiv. ### 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](../logging/metriken/)): | Panel | Typ | Inhalt | |---|---|---| | **Ausführungen** | Balken | Erfolgreiche gegen fehlgeschlagene Läufe, gruppiert nach **Bin Size** | | **Laufzeiten** | Verlauf | Durchschnittliche, minimale und maximale Laufzeit in Millisekunden, gruppiert nach **Bin Size** | | **GetChanges per Jobs** | Verlauf | **Erkannte Ä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. > **Wichtige Grenze: keine Job-Erfolgsquote für GetChanges** > > `GetChanges Successes`/`Failures` zählen **Timer-Läufe**, nicht einzelne Jobs. Ein > Timer-Lauf verarbeitet üblicherweise mehrere Jobs in einer Schleife; solange dabei keine > unbehandelte Ausnahme bis zum Funktionsaufruf durchschlägt, gilt der Lauf als > „erfolgreich" — auch wenn ein einzelner Job innerhalb des Laufs intern gescheitert ist > (z. B. weil ein Connector den Fehler geloggt, aber nicht weitergeworfen hat). Für eine > job-genaue Aussage reicht diese Zeile aktuell **nicht** aus. ### Zeile „ProcessQueueItems" Aufklappbar, vier Panels. Anders als bei `GetChanges` gibt es hier bereits eine job-granulare Custom Metric (`MessagesProcessed`, siehe [Metriken](../logging/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: | Panel | Typ | Inhalt | |---|---|---| | **Ausführungen** | Balken | `MessagesProcessed` nach Ausgang (`Success`/`Failed`/`Transitive`), gruppiert nach **Bin Size**, gefiltert nach **Job Namen** | | **Laufzeiten** | Verlauf | Durchschnittliche, minimale und maximale Verarbeitungsdauer (`ProcessingDurationMs`) über alle gefilterten Jobs zusammengefasst, gruppiert nach **Bin Size** | | **ProcessItems Success per Job** | Verlauf | Erfolgreich verarbeitete Nachrichten je Job (`Outcome = Success`), gruppiert nach **Bin Size**, gefiltert nach **Job Namen** | | **ProcessItems Errors per Job** | Verlauf | Fehlgeschlagene (`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. > **Laufzeiten-Panel ist bewusst nicht nach Job aufgeschlüsselt** > > Das Panel „Laufzeiten" fasst Durchschnitt/Min/Max über **alle** durch **Job Namen** > ausgewählten Jobs zusammen, statt eine Linie pro Job zu zeichnen. Das hält das Panel bei > vielen aktiven Jobs lesbar. Wer die Laufzeit eines einzelnen Jobs braucht, wählt ihn über > **Job Namen** gezielt aus, statt „All" stehen zu lassen. ### Zeile „Fehler-Überblick" Aufklappbar, ein Panel: **Heatmap** — Anzahl der Ausnahmen (`exceptions`-Tabelle) je Zeitfenster (**Bin Size**), aufgeschlüsselt nach Exception-Typ. > **Keine Job-Filterung möglich** > > Exceptions werden ohne `JobName`-Property getrackt (`TelemetryClient.TrackException` > läuft ohne zusätzliche Properties). Die Variable **Job Namen** wirkt sich auf dieses > Panel **nicht** aus — es zeigt immer alle Exceptions im gewählten Zeitraum, unabhängig > von der Job-Auswahl oben. ## 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](../logging/) verwenden. - **Keine Alarmierung** — das Dashboard ist eine Ansicht, kein Alerting. Dafür sind die [Alerts](../monitoring/) zuständig. ## Eigene Anpassungen > **Manuelle Änderungen werden überschrieben** > > Änderungen, die direkt im Portal am Dashboard vorgenommen werden, gehen beim **nächsten > Deployment** verloren — das Deployment setzt die Dashboard-Definition unbedingt neu. > > Anpassungen, die dauerhaft erhalten bleiben sollen, müssen in die Deployment-Vorlage > zurückfließen. Wenden Sie sich dafür an WYSA; das Dashboard wird zentral gepflegt und > mit dem nächsten Release ausgeliefert. Wer eine rein persönliche Ansicht braucht, legt sich im Portal ein **eigenes, zusätzliches** Dashboard an — dieses bleibt vom Deployment unberührt.