Prometheus-Grafana-Integration, die Probleme erkennt

Veröffentlicht am 6. Oktober 2026

Die Integration von Prometheus und Grafana sorgt dafür, dass Ihre Servermetriken einen konkreten Nutzen haben: Sie zeigen, was sich verändert, warnen Sie, bevor ein Grenzwertüberschreitung zum Ausfall führt, und liefern Belege, wenn ein Dienst langsam wirkt. Prometheus erfasst und speichert die Messwerte. Grafana verwandelt sie in Dashboards und Warnmeldungen, die Ihr Team auf einen Blick versteht. Zusammen ersetzen sie Vermutungen durch einen klareren Überblick über den Betrieb.

Ob VPS, dedizierter Server, SaaS-Plattform oder stark frequentierter Onlineshop – am wertvollsten ist diese Einrichtung, bevor etwas ausfällt. Eine volle Festplatte, erschöpfter Arbeitsspeicher, steigende Antwortzeiten oder ein Datenbankverbindungspool nahe seiner Kapazitätsgrenze hinterlassen in der Regel zuerst Spuren in den Metriken. Der Dienst funktioniert vielleicht gerade noch, aber das Diagramm erzählt bereits, wie es weitergeht.

Die jeweiligen Aufgaben von Prometheus und Grafana

Prometheus ist ein Zeitreihen-Überwachungssystem. Es ruft in regelmäßigen Abständen Metriken von Zielen ab, versieht diese Messwerte mit Labels und hält sie für Abfragen bereit. Es eignet sich besonders gut für die Überwachung von Servern und Anwendungen, da Metriken wie CPU-Auslastung, Speicherauslastung, Anfrageraten, Latenz und Dateisystemkapazität ganz natürlich in sein Modell passen.

Grafana ist die Visualisierungs- und Warnmeldungs-Ebene. Es bindet Prometheus als Datenquelle ein, ermöglicht das Erstellen von Panels anhand von PromQL-Abfragen und fasst diese Panels in Dashboards zusammen. Ein gutes Grafana-Dashboard muss nicht dekorativ sein. Es soll schnell praktische Fragen beantworten: Ist der Server gesund? Welcher Dienst nutzt Ressourcen? Verschlechtert sich die Leistung? Hat die Bereitstellung um 14:00 etwas verändert?

Prometheus kann Warnmeldungsregeln selbst auswerten, während Alertmanager Benachrichtigungen gruppiert, weiterleitet und unterdrückt. Grafana kann Warnmeldungen auch anhand von Dashboard-Abfragen erstellen. Beide Ansätze können funktionieren. Für infrastrukturweite, codeverwaltete Warnmeldungen lassen sich Prometheus-Regeln zusammen mit Alertmanager oft leichter standardisieren. Für ein gezieltes Dienst-Dashboard können von Grafana verwaltete Warnmeldungen praktisch sein. Vermeiden Sie, beide für exakt dieselbe Bedingung auszuführen, es sei denn, doppelte Benachrichtigungen um 3 Uhr morgens sind gewünscht. Teil des Plans.

Prometheus-Grafana-Integration: eine praktische Architektur

Eine sinnvolle Einstiegsarchitektur ist überschaubar. Betreiben Sie Prometheus und Grafana nach Möglichkeit auf einem Überwachungs-VPS, getrennt von dem Server oder der Anwendung, die überwacht wird. Installieren Sie Exporter auf den überwachten Systemen. Exporter stellen Metriken über einen HTTP-Endpunkt bereit, die Prometheus nach einem Zeitplan abruft.

Für Linux-Server ist Node Exporter normalerweise die erste Wahl. Es stellt Messwerte auf Hostebene bereit, darunter CPU, Arbeitsspeicher, Load Average, Festplattennutzung, Netzwerkverkehr und Dateisystemstatistiken. Datenbank-Exporter können zusätzliche Einblicke in MySQL, PostgreSQL, Redis und andere Dienste liefern. Anwendungsmetriken können von einem nativen Prometheus-Endpunkt, einer Framework-Bibliothek oder einem sorgfältig ausgewählten Exporter stammen.

Der grundlegende Datenfluss ist einfach:

• Ein Exporter stellt Metriken von einem Server, einer Datenbank oder einer Anwendung bereit.
• Prometheus ruft den Endpunkt ab und speichert die Zeitreihendaten.
• Grafana fragt Prometheus ab und zeigt die Ergebnisse an.
• Warnmeldungsregeln werten Schwellenwerte oder ungewöhnliches Verhalten aus und senden Benachrichtigungen über den ausgewählten Kanal.

Diese einfache Darstellung ist wichtig, weil sie auch die Fehlerbehebung vereinfacht. Wenn ein Grafana-Panel leer ist, prüfen Sie, ob Grafana Prometheus abfragen kann. Wenn Prometheus keine Daten hat, prüfen Sie die Zielseite und den Exporter-Endpunkt. Wenn das Ziel nicht erreichbar ist, prüfen Sie den Netzwerkzugriff, die Firewallregeln, den Dienststatus und die Exporter-Konfiguration. Die Protokolle erzählen nun meist dieselbe Geschichte.

Beginnen Sie mit Metriken, die zu Maßnahmen führen

Alle verfügbaren Metriken zu erfassen, erzeugt Rauschen, verbraucht Speicherplatz und führt zu Dashboards, die niemand öffnet. Beginnen Sie mit Metriken, die eine klare betriebliche Entscheidung unterstützen. Bei den meisten Servern sind das CPU-Auslastung und Load, verfügbarer Arbeitsspeicher, Swap-Aktivität, Festplattenplatz und Inode-Nutzung, Festplatten-E/A-Latenz, Netzwerkfehler, Prozessverfügbarkeit und Systemverfügbarkeit.

Ergänzen Sie bei Webanwendungen die HTTP-Anfragerate, Fehlerrate, Anfragedauer, aktiven Verbindungen und – sofern relevant – die Warteschlangentiefe. Erfassen Sie bei Datenbanken die Anzahl der Verbindungen, langsame Abfragen, den Replikationsstatus, die Cache-Effizienz, Sperren und das Speicherplatzwachstum. Für eine E-Commerce-Website können Fehler beim Bezahlvorgang und die Datenbanklatenz entscheidend sein; eine Entwicklungsagentur legt möglicherweise mehr Wert auf die Verfügbarkeit von Kundenumgebungen und erfolgreiche Backups. Entscheidend ist die Arbeitslast, nicht das beeindruckendste Dashboard.

Gehen Sie mit Labels sorgfältig um. Labels ermöglichen das Filtern nach Umgebung, Serverrolle, Kunde, Region oder Anwendung. Sie können auch eine große Anzahl unterschiedlicher Zeitreihen erzeugen, wenn sie Werte enthalten, die sich ständig ändern, etwa Benutzer-IDs, Bestell-IDs, Sitzungstokens oder Anfragepfade mit dynamischen Parametern. Labels mit hoher Kardinalität sind ein unauffälliger Weg, Prometheus deutlich mehr Arbeit als nötig zu machen.

Richten Sie die Erfassung ein, ohne neue Risiken zu schaffen

Prometheus benötigt in seiner Konfiguration eine Liste der Ziele. Ein einfaches Node-Exporter-Ziel könnte so aussehen:

``\`yaml scrape_configs:

• job_name: node

static_configs:

• targets: ['10.0.0.15:9100']

labels: environment: production role: web ``\`

In einer kleinen Umgebung sind statische Ziele übersichtlich und zuverlässig. Mit wachsender Infrastruktur ist Service Discovery meist besser geeignet, da Ziele automatisch hinzugefügt und entfernt werden. Halten Sie die Überwachungsendpunkte unabhängig von der gewählten Methode nach Möglichkeit privat. Lassen Sie Exporter-Ports nicht ohne Einschränkungen im öffentlichen Internet erreichbar, nur weil ein Dashboard Daten benötigt.

Verwenden Sie bei Bedarf ein privates Netzwerk, Firewall-Allowlisten, ein VPN oder einen Reverse Proxy mit Authentifizierung. Verschlüsseln Sie den Datenverkehr, wenn Metriken über nicht vertrauenswürdige Netzwerke übertragen werden. Prometheus-Metriken können Hostnamen, interne Dienstnamen, Arbeitslastmuster und Versionsdetails offenlegen. Es handelt sich um Betriebsdaten, nicht um öffentliche Dekoration.

Legen Sie die Aufbewahrungsdauer anhand Ihrer Anforderungen an die Störungsanalyse und Kapazitätsplanung fest. Für viele kleine Installationen reichen fünfzehn bis dreißig Tage aus, um aktuelle Änderungen und kurzfristige Trends zu erkennen. Eine längere Aufbewahrung erleichtert die Analyse saisonaler Nachfrage und des allmählichen Kapazitätswachstums, erhöht aber den Festplattenbedarf. Für längerfristige historische Berichte sollten Sie externen Speicher in Betracht ziehen, statt unbegrenzte Aufbewahrung auf demselben VPS einzurichten, auf dem Grafana läuft.

Erstellen Sie Dashboards für eine schnelle Diagnose

Erstellen Sie zuerst ein Übersichts-Dashboard. Es sollte den Zustand der wichtigsten Systeme anzeigen, nicht jede Metrik im Katalog. Eine nützliche Übersicht umfasst häufig Serververfügbarkeit, CPU, Arbeitsspeicher, Festplattennutzung, Netzwerkverkehr, HTTP-Fehlerrate und Anfragelatenz. Verwenden Sie Variablen für Host, Umgebung und Dienst, damit ein Dashboard mehrere Systeme abdecken kann, ohne zu einem Copy-and-paste-Museum zu werden.

Erstellen Sie anschließend dienstspezifische Dashboards. Ein Datenbank-Dashboard benötigt andere Panels als ein Webserver-Dashboard. Ein Dashboard für einen Hintergrund-Worker sollte Warteschlangentiefe, Verarbeitungszeit, Wiederholungsversuche und Fehler anzeigen. Halten Sie die Panel-Titel eindeutig: „Freier Speicherplatz auf /var“, „HTTP-5xx-Rate“ und „Aktive PostgreSQL-Verbindungen“ sind besser als originelle Namen, die im ungünstigsten Moment erst entschlüsselt werden müssen.

Anmerkungen zu Bereitstellungen, Wartungsfenstern und Konfigurationsänderungen sind sinnvoll. Steigt die Latenz kurz nach einer Veröffentlichung, macht eine Anmerkung aus einem verdächtigen Diagramm einen hilfreichen Gesprächsaufhänger. Sie beweist keinen ursächlichen Zusammenhang, bietet der Untersuchung aber einen sinnvollen Ausgangspunkt.

Lösen Sie bei Symptomen aus, nicht bei jeder Zahl

Eine CPU-Warnmeldung bei 80 % kann für einen Server nützlich und für einen anderen bedeutungslos sein. Ein Batch-Verarbeitungsknoten kann planmäßig stundenlang stark ausgelastet sein, während ein plötzlicher Anstieg der API-Latenz Kunden sofort beeinträchtigen kann, selbst wenn die CPU-Auslastung moderat ist. Warnmeldungsregeln sollten Auswirkungen und erwartetes Verhalten berücksichtigen.

Beginnen Sie mit Warnmeldungen für Zustände, die eine Reaktion erfordern: Ein Exporter oder Dienst ist nicht erreichbar, der Festplattenspeicher geht bald zur Neige, Backup-Aufträge schlagen fehl, Speicherdruck führt zu Auslagerungen, Fehlerraten steigen, Zertifikate nähern sich ihrem Ablaufdatum oder die Datenbankreplikation funktioniert nicht ordnungsgemäß. Legen Sie eine Dauer fest, damit kurze Spitzen nicht unnötig jemanden alarmieren. Anhaltend wenig Festplattenspeicher über fünfzehn Minuten ist in der Regel handlungsrelevanter als ein Einbruch von fünf Sekunden.

Jede Warnmeldung sollte drei Fragen beantworten: Was ist falsch? Wo tritt es auf? Was sollte die zuständige Person zuerst prüfen? Nehmen Sie den Servernamen, die Umgebung, den Dienst und eine kurze Runbook-Anweisung in die Anmerkung der Warnmeldung auf. „Wenig Festplattenspeicher“ reicht nicht aus, wenn es zwanzig Server gibt und jemand die Nachricht auf dem Handy liest.

Unterdrückungen und Wartungsfenster gehören zu einer funktionierenden Alarmierung und dienen nicht dazu, Probleme zu verbergen. Verwenden Sie sie für geplante Arbeiten und heben Sie sie nach deren Abschluss wieder auf. Eine vergessene Unterdrückung hat ein ausgesprochen schlechtes Timing.

Halten Sie den Überwachungs-Stack wartbar

Betrachten Sie Dashboards, Warnmeldungsregeln und die Prometheus-Konfiguration als Betriebsmittel. Sichern Sie sie, überprüfen Sie sie nach Störungen und speichern Sie die Konfiguration sicher in der Versionsverwaltung, sofern Ihr Team dies tun kann. Testen Sie Warnmeldungen gelegentlich. Ein Benachrichtigungskanal, der noch nie getestet wurde, ist lediglich eine hoffnungsvolle Annahme.

Überwachen Sie auch das Überwachungssystem selbst. Prometheus benötigt genügend Arbeitsspeicher und Speicherplatz, Grafana braucht Sicherungen seiner Konfiguration und Datenbank, und Exporter müssen auch nach Änderungen an Firewall oder Netzwerk erreichbar bleiben. Behalten Sie die Dauer der Abrufe, fehlgeschlagene Abrufe, die Speicherkapazität und fehlgeschlagene Zustellungen von Warnmeldungen im Blick. Ist der Überwachungsserver überlastet, sehen seine Diagramme möglicherweise ruhig aus, während er unbemerkt genau die Belege verpasst, die Sie benötigen.

Für Teams, die neben ihrer Infrastruktur auch betriebliche Unterstützung wünschen, kann kodu.cloud überwachte VPS- und Serverumgebungen unterstützen, während Sie anhand der für Ihr Unternehmen wichtigen Metriken den Überblick behalten. Das Ziel ist nicht, die Überwachung undurchschaubar zu machen. Es geht darum, das nächste Problem kleiner, früher und leichter beherrschbar zu machen.

Eine gut abgestimmte Prometheus- und Grafana-Installation verhindert keine Störungen. Sie verschafft Ihrem Team frühere Warnungen, klarere Zusammenhänge und weniger Entscheidungen im Blindflug, wenn eine Störung auftritt. Beginnen Sie mit einem Server, einem Dashboard und einer kleinen Auswahl an Warnmeldungen, auf die tatsächlich reagiert wird. Von dort aus kehrt wieder Ruhe in den Betrieb ein.

Andres Saar, Customer-Care-Techniker