Ein Dashboard ist eine visuelle Sammlung von Panels wie Zeitreihendiagrammen, Heatmaps, Tabellen und Einzelwerten, die jeweils auf einer Abfrage über Telemetriedaten beruhen. In der Observability fassen Dashboards den Zustand von Services und Infrastruktur auf einen Blick zusammen und sind Ausgangspunkt für den Drill-down in Traces, Logs und Profile.
Was ein Dashboard ist
Ein Dashboard ordnet mehrere Panels auf einer Ansicht an, damit Menschen den aktuellen und jüngsten Zustand eines Systems sehen, ohne selbst Abfragen zu schreiben. Jedes Panel ist eine gespeicherte Abfrage, etwa die Request-Rate eines Service, seine p99-Latenz oder der Speicherverbrauch seiner Pods, dargestellt als Diagramm, Heatmap, Tabelle oder Einzelwert. Template-Variablen wie Umgebung, Cluster oder Service machen ein Dashboard für viele Ziele nutzbar. Gute Dashboards zeigen außerdem Annotationen, etwa Deployments, Feature-Flag-Änderungen oder Wartungsfenster, damit sich Veränderungen in den Kurven sofort einem Ereignis zuordnen lassen. Im Incident sind sie so oft der erste Ort, an dem das Team eine Hypothese bildet.
Dashboards sind der sichtbarste Teil des Monitorings, beantworten aber nur Fragen, an die vorher jemand gedacht hat. Genau das ist der Kern des Unterschieds zwischen Monitoring und Observability: Ein gutes Dashboard zeigt, dass etwas nicht stimmt und ungefähr wo. Warum, erfahren Sie erst, wenn Sie Daten frei aufschlüsseln und in Traces und Logs springen können.
Arten von Dashboards
| Typ | Zielgruppe | Typischer Inhalt |
|---|---|---|
| Service-Übersicht | Verantwortliches Team, Rufbereitschaft | Rate, Fehler, Dauer, Sättigung, SLO-Status, letzte Deployments |
| Infrastruktur | Plattform-Team | Nodes, Pods, CPU, Speicher, Platte, Netzwerk, Autoscaling-Ereignisse |
| Abhängigkeit / Datenbank | Service-Owner, DBAs | Abfragelatenz, Verbindungen, Locks, Replikationsverzug |
| Business / Management | Produkt, Führung | Bestellungen, Registrierungen, umsatzrelevante Conversion, SLO-Einhaltung |
| Incident / Analyse | Incident-Team | Ad-hoc-Panels aus dem Incident, oft danach verworfen |
Was auf ein Service-Dashboard gehört
Bewährte Methoden geben Struktur. Die RED-Methode (Rate, Errors, Duration) passt zu request-getriebenen Services, die USE-Methode (Utilization, Saturation, Errors) zu Ressourcen wie CPUs, Platten oder Queues, und die vier Golden Signals verbinden beide Sichten. Bewährt ist eine Anordnung mit nutzerbezogenen Signalen oben, dann Abhängigkeiten, dann Ressourcen:
- SLO-Status und verbleibendes Error Budget.
- Request-Rate, Fehlerrate und Latenz-Perzentile (p50, p95, p99) oder eine Latenz-Heatmap.
- Aufrufe nachgelagerter Abhängigkeiten mit Latenz und Fehlern.
- Sättigung: CPU-Throttling, Speicher, Connection Pools, Queue-Tiefe.
- Markierungen für Deployments und Konfigurationsänderungen auf jedem Zeitreihendiagramm.
Gestaltungsprinzipien
- Mit einer Frage beginnen. „Ist der Checkout gerade gesund?“ führt zu einem besseren Dashboard als „alle Checkout-Metriken anzeigen“.
- Perzentile und Heatmaps statt Mittelwerte. Eine durchschnittliche Latenz kann gut aussehen, während das langsamste Prozent der Nutzer Sekunden wartet.
- Einheiten und Achsen konsistent halten. Raten pro Sekunde, Dauern in derselben Einheit, Fehlerdiagramme mit Nullpunkt.
- Panels klickbar machen. Von einer Latenzspitze zu Beispiel-Traces verlinken, idealerweise über Exemplars, und von Fehlern zu den passenden Logs.
- Dashboards als Code behandeln. Definitionen versioniert ablegen (etwa als JSON, Jsonnet oder Terraform), Änderungen reviewen und Standard-Dashboards pro Service aus Vorlagen erzeugen.
Die passende Visualisierung wählen
- Zeitreihen für Raten, Fehlerquoten und Ressourcenverbrauch im Zeitverlauf; der Standard für fast alles, was sich verändert.
- Heatmaps für Latenzverteilungen. Sie zeigen bimodales Verhalten, etwa Cache-Treffer gegenüber Cache-Fehlschlägen, das eine einzelne Perzentil-Linie verdeckt.
- Einzelwerte mit Schwellen für SLO-Einhaltung oder verbleibendes Error Budget, wenn eine Zahl die Frage beantwortet.
- Tabellen für Top-N-Listen wie die langsamsten Endpunkte oder die auffälligsten Pods, sortiert nach Auswirkung.
- Service-Maps für Abhängigkeiten, damit das Incident-Team sieht, welcher vor- oder nachgelagerte Service betroffen ist.
Verzichten Sie bei Betriebsdaten auf Tortendiagramme und bei Werten, die sich nicht sinnvoll addieren lassen, etwa Perzentilen, auf gestapelte Diagramme.
Beispiel: eine RED-Abfrage
Eine beispielhafte PromQL-Abfrage für ein p99-Latenz-Panel pro Route, basierend auf einem nach Prometheus exportierten OpenTelemetry-HTTP-Server-Histogramm:
histogram_quantile(0.99,
sum by (le, http_route) (
rate(http_server_request_duration_seconds_bucket{service_name="checkout"}[5m])
)
)Wichtig: Das Quantil wird erst nach dem Summieren der Buckets über alle Instanzen berechnet. Den Mittelwert der p99-Werte einzelner Instanzen zu bilden, ist eine verbreitete und irreführende Abkürzung.
Typische Fehler
Dashboard-Wildwuchs ist das häufigste Problem: Hunderte Dashboards, viele kopiert, die Hälfte defekt, keines klar zugeordnet. Im Incident weiß niemand, welchem man trauen kann. Weitere Fehler sind Panels mit Dutzenden überlagerter Linien, Abfragen, die nach Labels mit hoher Kardinalität wie Nutzer-IDs gruppieren und Dashboards ausbremsen, sowie Dashboards als primärer Alarmierungsmechanismus. Das funktioniert nur, solange jemand hinschaut.
Löschen Sie regelmäßig Dashboards, die seit Monaten niemand geöffnet hat, weisen Sie jedem verbleibenden einen Owner zu und pflegen Sie pro Team wenige kuratierte, verlinkte Einstiegspunkte. Ein einfaches Namensschema mit Team, Service und Zweck hilft zusätzlich, das Richtige schnell zu finden.
Wie Obseria unterstützt
Obseria erzeugt Service-Dashboards automatisch aus OpenTelemetry-Daten und der Topologie von Obseria TopoGraph, und jedes Panel lässt sich mit OQL, PromQL oder SQL bearbeiten. Dashboards sind in allen Tarifen ohne Nutzerlimits enthalten und lassen sich über API und CLI als Code verwalten. Von jedem Diagramm aus gelangen Sie in Traces, Logs und Profile; der Service-Katalog ordnet jedes Dashboard seinem Team zu.
