Im vorherigen Leitfaden haben Sie das Proxmox-eigene Backup-System vollständig über das Panel eingerichtet, nämlich einen geplanten Job, einen echten Wiederherstellungspfad und einen echten „vzdump“-Lauf, der von Anfang bis Ende in einem eigenen Aufgabenprotokoll erfasst wurde. Das manuelle Überwachen dieses Protokolls funktioniert nur, solange jemand tatsächlich auf den Bildschirm schaut. Daher schließt diese abschließende Anleitung den Kreis: Sie zeigt, wie man die von Proxmox bereits erfassten Informationen zu seinen eigenen Ressourcen auswertet und bestimmte Ereignisse in eine Benachrichtigung umwandelt, die an einer Stelle angezeigt wird, an der ein Mensch sie tatsächlich sieht.
Lesen Sie die integrierten Ressourcendiagramme
Die eigene Übersichtsseite jedes Knotens öffnet sich mit einer Reihe von Echtzeitwerten, noch bevor auch nur ein einziges Diagramm geladen wird: CPU-Auslastung, durchschnittliche Auslastung, RAM-Auslastung, freier Speicherplatz, E/A-Verzögerung, KSM-Nutzung und Swap-Auslastung – alle Werte werden direkt vom Host ausgelesen und sind keine Schätzungen. Auf derselben Seite wird zudem übersichtlich angegeben, auf welcher Hardware und mit welcher Software diese Plattform tatsächlich läuft – ein Blick darauf lohnt sich beim ersten Laden.
Der Repository-Status ist lesenswert und sollte nicht übersprungen werden: Dieser spezielle Knoten weist auf ein nicht produktionsreifes Repository hin – das kostenlose, abonnementfreie Repository, auf dem dieses gesamte Lab seit der allerersten Anleitung läuft. Es handelt sich um eine echte und korrekt angezeigte Warnung und nicht um eine bloße kosmetische Ermahnung. Stunde, Tag, Woche, Monat und Jahr zeichnen jeweils dieselben Diagramme zu CPU, Arbeitsspeicher, Netzwerk und Festplatte unten neu – mit einer immer gröberen Auflösung, je weiter der Zeitraum zurückreicht. Das reicht aus, um ein langsames Speicherleck oder eine sich unbemerkt füllende Festplatte zu erkennen, ohne auf Tools außerhalb des Panels selbst zurückgreifen zu müssen.
Bleibt der Verlauf dieser Grafik nach einem Neustart erhalten?
Ja. Proxmox speichert die Daten als RRD-Daten auf der Festplatte – im gleichen Round-Robin-Format, das Munin und Cacti schon seit Jahren verwenden. Bei einem Neustart gehen daher bereits aufgezeichnete Daten nicht verloren, und das Hinzufügen weiterer Daten zu derselben Datei wird einfach fortgesetzt.
Echte Ereignisse an eine echte Benachrichtigung weiterleiten
Ein Diagramm ist nur für diejenigen hilfreich, die es sich tatsächlich ansehen. Aus diesem Grund bietet Proxmox ein völlig eigenständiges Benachrichtigungssystem an: „Datacenter“, „Notifications“ – unterteilt in zwei Listen, die zusammenarbeiten, anstatt eine einzige lange Einstellungsseite zu bilden.
Schauen Sie sich an, was bereits verkabelt ist
Bei einem neuen Knoten sind beide Hälften bereits im Hintergrund konfiguriert, noch bevor jemand diese Seite aufruft: ein Ziel und ein Matcher, die beide als „Built-In“ gekennzeichnet sind und nicht von einem Benutzer hinzugefügt wurden.
„mail-to-root“, das Ziel, ist ein Sendmail-Eintrag, der auf die Adresse verweist, zu der „root@pam“ tatsächlich aufgelöst wird. „default-matcher“, der Matcher, ist bewusst unspezifisch gehalten: Er passt auf alles und leitet alles an dieses eine Ziel weiter. Genau aus diesem Grund benötigte der im vorherigen Leitfaden beschriebene „vzdump“-Befehl keinerlei Benachrichtigungseinrichtung, um bereits über eine Anlaufstelle für die Meldung eines Fehlers zu verfügen.
Webhook-Ziel hinzufügen
E-Mail funktioniert zwar, aber nur selten ist es der Ort, an dem ein Operator tatsächlich in Echtzeit darauf achtet, auf etwas zu reagieren. Die Schaltfläche „Hinzufügen“ in der Symbolleiste „Benachrichtigungsziele“ bietet außerdem Gotify, SMTP und Webhook an, wobei Webhook die einzige Option ist, die wirklich überall hinreicht: zu jeder URL, die eine POST-Anfrage akzeptiert, mit voller Kontrolle über Header, Body und Geheimdaten.
Nichts in diesem Formular setzt einen bestimmten Dienst auf der Empfängerseite voraus. „Headers“ dient zur Angabe eines API-Schlüssels oder einer Überschreibung des Content-Types, „Body“ ist eine frei gestaltbare Vorlage für jede beliebige JSON-Struktur, die die Empfängerseite erwartet, und „Secrets“ sorgt dafür, dass ein Token nicht im „Body“-Feld selbst erscheint, sodass es niemals versehentlich in einem Aufgabenprotokoll oder einem Prüfpfad auftaucht.
Verleite Ereignisse an diese Route
Ein Matcher entscheidet, welche Ereignisse tatsächlich ein bestimmtes Ziel erreichen. Er basiert auf Regeln, die sich fast wie ein Suchfilter lesen. Das Feld „Field“ innerhalb einer Regel bietet genau fünf echte Ereignistypen, von denen jeder mit einem bestimmten Teil von Proxmox verknüpft ist und nicht mit einer fiktiven Schweregradstufe:
- vzdump: Benachrichtigungen zu Backups – genau die Kategorie, in die ein fehlgeschlagener Auftrag aus der vorherigen Anleitung fallen würde.
- Replikation: Benachrichtigungen zu Replikationsaufträgen, die relevant sind, sobald ein zweiter Knoten diesem Cluster beitritt.
- Fencing: Benachrichtigungen zum Knoten-Fencing, die mit der Hochverfügbarkeit (HA) verknüpft sind und an eine gut sichtbare Stelle weitergeleitet werden sollten, sobald eine echte Failover-Konfiguration vorliegt.
- package-updates: Ein einfacher Hinweis darauf, dass Updates verfügbar sind – eher eine Zusammenfassung als ein Vorfall.
- system-mail: alles, was das System sonst an den lokalen Benutzer senden würde; es handelt sich also eher um eine Sammelkategorie als um ein bestimmtes Ereignis.
Indem man diesen Matcher „backup-alerts“ nennt und auf der Registerkarte „Benachrichtigungen“ unter „Ziele“ die Option „ops-webhook“ auswählt, anstatt den „default-matcher“ vollständig zu ersetzen, laufen nun beide Regeln parallel: Ein „vzdump“-Ereignis wird gezielt an „ops-webhook“ weitergeleitet, während „default-matcher“ weiterhin alles abfängt – einschließlich Backup-Benachrichtigungen – und wie bisher E-Mails an „root@pam“ versendet. Das Aufeinanderstapeln mehrerer Matcher auf diese Weise ist das übliche Vorgehen, sobald die Anzahl der Warnmeldungen über eine einzige Sammelregel hinausgeht.
Bevor Sie einen neuen Matcher in der Produktion einsetzen: Lassen Sie zunächst ein echtes Testereignis durchlaufen. Die Funktion „Testen“ in der Symbolleiste „Benachrichtigungsziele“ löst sofort eine echte Benachrichtigung an ein ausgewähltes Ziel aus. Dies ist der schnellste Weg, um zu überprüfen, ob ein Webhook-Endpunkt tatsächlich das empfängt, was dieser Dialog verspricht – und das sollten Sie unbedingt herausfinden, bevor ein echter Backup-Fehler auftritt.
Exportkennzahlen für Echtzeit-Dashboards und Alarmschwellenwerte
Die integrierten Diagramme geben zwar Aufschluss darüber, „was passiert ist“ – zumindest für diejenigen, die daran denken, einen Blick darauf zu werfen. Sie bieten jedoch keine Lösung für den Fall, dass „jemand benachrichtigt werden soll, sobald die CPU-Auslastung fünf Minuten lang über 90 % liegt“, da Proxmox selbst kein Konzept für Metrik-Schwellenwerte kennt. Genau diese Lücke soll „Metric Server“ schließen, der weiter oben im selben „Datacenter“-Menü zu finden ist: ein Live-Stream aller Metriken, die dieses Panel bereits erfasst, wird an ein System gesendet, das genau für diese Aufgabe entwickelt wurde.
Graphite und InfluxDB sind die beiden seit Langem etablierten Optionen, die beide schon seit langem mit Grafana für genau diese Art von Dashboards kombiniert werden; OpenTelemetry ist die neuere, herstellerneutrale Ergänzung – dasselbe Protokoll, auf das sich bereits ein wachsender Anteil der Observability-Stacks standardisiert, unabhängig davon, welche Datenbank dahinter steht.
Sobald die Metriken in einer Echtzeit-Zeitreihendatenbank gespeichert sind, stellt die Schwellenwertwarnung für Proxmox keinerlei Einschränkung mehr dar: Die eigenen Warnregeln von Grafana oder jede andere Lösung, die Abfragen an InfluxDB oder Graphite senden kann, übernehmen ab diesem Punkt die Überwachung und beobachten genau dieselben Zahlen, die in dieser Anleitung bisher auf der Übersichtsseite manuell abgelesen wurden.
Zusammenfassend lässt sich sagen
- Auf den Übersichtsseiten für Knoten und Rechenzentren werden die Verlaufsdaten zu CPU, Arbeitsspeicher, Netzwerk und Festplatten für bis zu ein Jahr erfasst – für einen schnellen Überblick ist kein separates Tool erforderlich.
- Das Benachrichtigungssystem unterscheidet zwischen Zielen, an die eine Warnmeldung gesendet wird, und Matchern, welche Ereignisse dorthin weitergeleitet werden, wobei sich beide stapeln können.
- Ein Webhook-Ziel kann jede beliebige URL erreichen – genau wie der Integrationspunkt hinter Slack, Discord, PagerDuty oder einem internen Dashboard.
- Der Export von Metric Server nach Graphite, InfluxDB oder OpenTelemetry ermöglicht erst die schwellenwertbasierte Alarmierung über die von Proxmox standardmäßig erfassten Werte hinaus.
Der Tunnelverkehr, der bereits weiter oben in diesem Leitfaden behandelt wurde, weist ebenfalls eine eigene Nutzung auf, die es zu beachten gilt und die in Taipans eigenem Referenz zur Bandbreitenmessung.