Eigenes Monitoring mit Prometheus und Grafana

Meine PRTG-Installation läuft mit der kostenlosen Lizenz, und die erlaubt hundert Sensoren. Als ich einen weiteren Server aufnehmen wollte, waren alle hundert belegt. Also habe ich den Objektbaum exportiert und ausgewertet, statt einen bestehenden Sensor zu löschen.

Das Limit war nicht das Problem.

Die Bestandsaufnahme

117 Sensoren auf 37 Geräten, 25 Sensortypen, davon 100 aktiv. Die 17 pausierten entfallen größtenteils auf zwei NAS-Systeme, die derzeit nicht in Betrieb sind.

Sensortyp	Anzahl
Ping	34
HTTP	27
Virtualisierung (Host und VMs)	12
WMI Speicherplatz	9
Windows CPU-Last	7
WMI Arbeitsspeicher	7
SMTP, DNS, TCP, FTP, RDP	11
SNMP	0

60 der 117 Sensoren sind Ping- oder HTTP-Prüfungen. Sie beantworten genau eine Frage: antwortet das Gerät. SNMP-Sensoren gibt es keinen einzigen. Die gesamte Netzwerk- und Speicher-Hardware — NAS, Access Points, Router mit DSL-Modem — wird angepingt, mehr nicht. Vom NAS weiß ich, dass es online ist. Nicht, wie voll es ist, wie warm es wird, ob eine Platte SMART-Fehler meldet.

Bei den Linux-Servern dasselbe Bild: fast nur Ping. Kein Speicherplatz, keine Last, kein Arbeitsspeicher, keine Dienstüberwachung.

Auch die Abfrageintervalle waren mager: 81 Sensoren im Minutentakt, elf alle zehn Minuten, einer stündlich.

Der Stack

Auf einer eigenen VM laufen jetzt Prometheus als Zeitreihendatenbank, Loki für Protokolle, Grafana zur Darstellung, Alertmanager für die Benachrichtigung und der blackbox_exporter für alles, was von außen geprüft wird. Alles in Containern, Konfiguration in Dateien, Aufbewahrung 90 Tage.

Die Oberfläche ist ausschließlich aus dem internen Netz erreichbar. Ein Monitoring-Dashboard zeigt in Summe die gesamte Infrastruktur — Hostnamen, Adressen, Versionsstände, offene Schwachstellen — und gehört damit nicht ins Internet, auch nicht hinter eine Anmeldung.

Interessant ist daran nicht die Oberfläche, sondern wie die Daten hineinkommen. Dafür gibt es drei Wege.

Stufe 1: Was es fertig gibt

Auf den Windows-Servern läuft je ein windows_exporter. Ein Dienst je Maschine ersetzt sämtliche WMI-Einzelsensoren. Der Virtualisierungshost war mit 28 Sensoren der größte Posten in PRTG — ein einziger Service deckt dort Host und alle Gastsysteme in einem Abruf ab. Für Mail- und Datenbankserver kommen weitere Services dazu, die deren Fachwerte liefern: Transportwarteschlangen und Zugriffszeiten beim einen, Datenbankinstanzen beim anderen.

Auf den Linux-Hosts läuft Grafana Alloy. Dort war der Zugewinn am größten, weil vorher praktisch nichts gemessen wurde. Alloy liest auf dem Reverseproxy zusätzlich die Webserver-Protokolle und macht daraus Anfragen, Statuscodes, Durchsatz und Latenzverteilung, getrennt je Website.

Die 60 Ping- und HTTP-Sensoren stecken heute in einem einzigen blackbox_exporter:

Prüfung	Anzahl
ICMP	28
HTTP	22
TCP	7
DNS	3

Wieder exakt 60, nur in einem Container statt als 60 lizenzierte Sensoren. Nebenbei fällt für jeden Endpunkt das Ablaufdatum des Zertifikats ab, gewarnt wird bei 30 Tagen, 14 Tagen und am Tag des Ablaufs. Weil ich eine eigene PKI betreibe, gilt das auch für die internen Zertifikate.

Für NAS und Netzwerkgeräte kam SNMP dazu: Füllstände, Temperaturen, Lüfterdrehzahlen, SMART-Status, RAID-Zustand. Das NAS hält diese Werte seit Jahren bereit. Abgefragt hat sie nie jemand.

Stufe 2: Was es nicht fertig gibt

Eine Wetterstation spricht kein Prometheus. Eine Hausautomatisierungszentrale auch nicht. Ein Satellitenreceiver schon gar nicht.

Bei einem Kaufprodukt hört die Überwachung genau hier auf: kein Sensortyp, keine Daten. Das Prometheus-Format ist dagegen Text über HTTP — Metrikname, Beschriftungen in geschweiften Klammern, eine Zahl.

Dafür läuft ein eigenes Projekt, Monitoring.Devices, in C# auf Basis von prometheus-net. Ein Modul je Gerätetyp, alle unter einem gemeinsamen /metrics-Endpunkt. Angebunden sind die Hausautomatisierungszentrale und fünf Satellitenreceiver. Bei den Receivern kommen zwei Wege zusammen: Die Weboberflächen-Schnittstelle liefert Standby, Tuner-Belegung, laufende Aufnahmen und programmierte Timer, ein gebündelter SSH-Aufruf holt Last, Arbeitsspeicher, Netzwerkzähler, Speicherplatz und eingebundene Netzwerkfreigaben. Der Router läuft über einen eigenen Abruf und liefert DSL-Synchronisation, WAN-Durchsatz und Fehlerzähler.

Jedes Modul meldet zusätzlich, ob sein Gerät erreichbar war und wie alt die Messwerte sind. Bei den Receivern ist das keine Formalie: Einer steht in der Küche und läuft nicht durchgehend. Ohne diese Angabe wäre ein ausgeschaltetes Gerät nicht von einer klemmenden Abfrage zu unterscheiden.

Der Aufwand ist nicht null, aber einmalig und kalkulierbar. Die Frage ist nicht mehr, ob der Hersteller mein Gerät unterstützt, sondern ob das Gerät seine Werte irgendwie herausgibt.

Stufe 3: Was gar keine Infrastruktur ist

Der dritte Weg hatte denselben Auslöser wie der ganze Umbau: ein Limit.

Ich nutze Claude Code täglich und auf mehreren Rechnern. Neben der Abrechnung je Anfrage gibt es ein Kontingent pro Woche, und bei meiner Arbeitsweise wäre es nach drei Tagen erschöpft. Den Rest der Woche hätte ich ohne dagestanden, trotz größtem verfügbaren Abo.

Eine Schätzung hilft da nicht. Ich brauchte den Verlauf: welcher Rechner, welches Projekt, welche Arbeitsweise, wie schnell sich das Kontingent leert. Daraus ist ein eigenes Projekt geworden, das die Nutzungsdaten aller Rechner einsammelt, über eine WebAPI in eine Datenbank schreibt und in Grafana auswertet. Zwei der neun Dashboards gehören dazu, eines zeigt ausschließlich den Abstand zum nächsten Limit.

Prometheus interessiert es nicht, ob eine Zahl von einem Betriebssystem kommt oder aus einer eigenen Anwendung. Der Abstand zum Wochenlimit steht jetzt in derselben Oberfläche wie der Füllstand einer Festplatte — und funktioniert nach demselben Prinzip: Vorwarnung statt Meldung.

Wie das Projekt aufgebaut ist und was die Zahlen über meine Arbeitsweise verraten haben, kommt in einen eigenen Beitrag.

Was dabei herauskam

	PRTG	heute
Messpunkte	100, Limit erreicht	77 Ziele, 106.370 Zeitreihen
Windows-Server	WMI-Einzelsensoren	vollständige Systemmetriken je Maschine
Linux-Server	nur Erreichbarkeit	vollständige Systemmetriken, dazu Auswertung der Webserver-Protokolle
Netzwerk und NAS	nur Erreichbarkeit	SNMP, wo verfügbar
Abfrageintervall	30 bis 3600 Sekunden	15 bis 30 Sekunden
Speicherplatz	starrer Schwellwert	Trendvorhersage über predict_linear
Zertifikate	teilweise	flächendeckend, auch intern, 30/14/0 Tage
Historie	begrenzt	90 Tage
Alarmregeln	Schwellwerte je Sensor	45 Alarm- und 26 Aufbereitungsregeln in 17 Gruppen

Der Sprung auf über hunderttausend Zeitreihen klingt spektakulärer als er ist — eine Zeitreihe ist erst mal nur eine gemessene Größe, keine Alarmquelle. Zwei andere Zeilen sind wichtiger.

Die Auflösung. PRTG fragte 81 Sensoren im Minutentakt ab, einen stündlich. Jetzt wird flächendeckend alle 15 bis 30 Sekunden gemessen, ohne Zusatzkosten. Kurze Aussetzer, die vorher zwischen zwei Messungen verschwanden, sind sichtbar.

Der Speicherplatz. Ein Schwellwert bei 90 Prozent meldet sich, wenn es fast zu spät ist. predict_linear wertet den Verlauf der letzten Stunden aus und warnt, wenn die Platte auf dieser Kurve in vier Tagen voll wäre.

Wer überwacht das Monitoring?

Ein Monitoring, das ausfällt, meldet seinen eigenen Ausfall nicht. Es wird still, und Stille sieht aus wie „alles in Ordnung“.

Die Lösung ist ein Dead Man’s Switch. Auf der Monitoring-VM läuft alle zwei Minuten ein Timer. Er prüft erst, ob Prometheus und Alertmanager antworten, und schickt dann ein Lebenszeichen an einen kleinen Dienst — bewusst nicht bei mir zu Hause, sondern auf einem gemieteten Server im Rechenzentrum. Bleibt das Lebenszeichen aus, meldet der sich an ein Postfach, das ebenfalls nichts mit meiner Infrastruktur zu tun hat.

Fällt die VM aus, der Virtualisierungshost oder der Strom im ganzen Haus, kommt die Warnung trotzdem an. Durchgespielt habe ich das.

Was nicht auf Anhieb funktioniert hat

Die Alarm-Mails landeten in der Spam-Quarantäne. 26 bis 30 Spampunkte, stillschweigend aussortiert. Ich hatte dem Mailserver das Docker-Netz als vertrauenswürdig bekannt gegeben, aber der vorgeschaltete Inhaltsfilter führt eine eigene Netzliste und wertete dieselbe Einlieferung als offenes Relay. Gelöst über einen eigenen Einlieferungsport ohne Inhaltsfilter, ausschließlich für Benachrichtigungen.

Das ist die unangenehme Sorte Fehler: Das Monitoring arbeitet einwandfrei, erkennt jede Störung, verschickt jede Meldung — und trotzdem kommt nichts an. Eine Fehlermeldung gibt es nicht, es wird nur still. Seitdem löse ich jede Alarmregel mindestens einmal absichtlich aus.

Wie es weitergeht

PRTG läuft noch. Der Parallelbetrieb ist Absicht: Erst wenn über mehrere Wochen belegt ist, dass der neue Stack dieselben Ereignisse meldet, wird abgeschaltet. Bisher findet er mehr als der alte, aber das ist eine Beobachtung, kein Beweis.

Auf dem Übersichtsdashboard steht selten alles auf Grün, und das ist auch nicht der Anspruch — ein Monitoring, das nie etwas meldet, misst zu wenig. Offen sind zurzeit der Netzwerkdrucker, eigene Exporter für Wetterstation und DNS-Blacklist-Prüfung sowie Push aufs Telefon statt nur per E-Mail.

Der größere Schritt betrifft meine eigenen Webanwendungen. Die sehe ich bisher nur von außen: ob sie antworten, und was der Reverseproxy an Anfragen, Statuscodes und Latenzen protokolliert. Wie viele Besucher tatsächlich kommen, ob die Hintergrundjobs durchlaufen, was in den Protokollen steht — alles unsichtbar. Diese Daten liegen längst vor, nämlich in der Datenbank der jeweiligen Anwendung. Der nächste Schritt ist deshalb kein weiterer Exporter, sondern eine Dashboard-Vorlage, die direkt gegen die Projektdatenbank abfragt und sich ohne Änderung auf das nächste Projekt anwenden lässt. Entwickelt wird sie gegen diese Homepage hier. Dazu kommen die Anwendungsprotokolle in Loki, mit Alarmregeln darauf statt nur einem Diagramm.

Die Ausgangsfrage hat sich damit umgedreht. Vorher: Welchen Sensor kann ich mir noch leisten? Heute: Welche Zahl gibt dieses Gerät heraus, und will ich sie sehen?