Home > Effizientes Proxmox-Monitoring mit Checkmk

Effizientes Proxmox-Monitoring mit Checkmk

Alexander Wilms
By Alexander Wilms on Jun 11, 2021

Proxmox ist eine beliebte Server-Virtualisierungs-Plattform auf Linux-Basis. Die Open-Source-basierte Software kombiniert mit KVM (Kernel-Based Virtual Machine) und LXC (LinuX Containers) zwei Virtualisierungstechniken zum Betrieb von virtuellen Maschinen (VMs) und Containern. Über die Konfigurationsoberfläche von Proxmox lassen sich Container, VMs, Storage und virtuelle Netzwerke auf den Host-Systemen einfach verwalten. Sie können Proxmox entweder als einzelnen Node betreiben oder mehrere Proxmox-Server in einem Cluster, was normalerweise der Fall ist.

Um einen reibungslosen Betrieb der via Proxmox verwalteten Container und VMs zu gewährleisten, ist es ratsam beziehungsweise notwendig, die Proxmox-Nodes oder -Cluster in Ihr IT-Infrastruktur-Monitoring aufzunehmen. Mit Checkmk haben Sie die Möglichkeit, alle wichtigen Metriken Ihrer Proxmox-Umgebung zu überwachen und so Probleme oder Engpässe zeitnah zu erkennen.

Proxmox-Server für das Monitoring vorbereiten

Dafür ist es zunächst notwendig, den Linux-Monitoring-Agenten auf Ihren Proxmox-Nodes zu installieren. Im Handbuch finden Sie eine Anleitung, wie Sie den Linux-Agenten installieren. Anschließend können Sie die Monitoring-Daten über den Port 6556 im lokalen Netzwerk oder – falls sich dieser nicht im lokalen Netzwerk befindet – über die öffentliche IP-Adresse verschlüsselt via SSH abfragen. Zusätzlich zum Agenten sollten Sie den Spezialagenten Proxmox VE in Checkmk konfigurieren und benutzen.

Zunächst müssen Sie jedoch etwas Vorarbeit in der Konfigurationsoberfläche von Proxmox leisten und einen API-Zugang einrichten. Dafür erstellen Sie für Ihren Cluster unter dem Reiter „Permissions“ einen User Checkmk mit dem Realm „pve“. Dieser Benutzer wird von Proxmox und nicht vom zugrundeliegendem Debian authentifiziert.

Den User Checkmk in der Proxmox-Oberfläche erstellen

Anschließend weisen Sie den erstellten User der Gruppe „Read only“ zu.

Konfiguration der Read-Only-Gruppe in der Proxmox-Oberfläche

Zum Abschluss müssen Sie nun (weiterhin auf Cluster-Ebene) auf „Permissions“ klicken und dort für die Gruppe „Read only“ den gewünschten Pfad festlegen. Der Pfad legt quasi den Startpunkt der API fest. In unserem Beispiel ist das /, also das root-Verzeichnis. Als Rolle legen wir für die Gruppe hier „PVEAuditor“ fest. In Kombination mit dem root-Pfad darf der User nun alles auf dem Node sehen beziehungsweise lesen – hat aber keine darüber hinausgehenden Rechte.

Die richtigen Permissions für die Rolle PVEAuditor in der Proxmox-Oberfläche setzen

Hinweis: Um Ihnen das Monitoring an späterer Stelle zu vereinfachen, empfehle ich Ihnen, dass Sie Ihr Netzwerk-Monitoring mit Checkmk optimieren, inklusive einer effizienten Überwachung Ihrer Interfaces. Dadurch haben sämtliche Interfaces in Ihrer IT-Infrastruktur einen sinnvollen Namen. In unserem Blogartikel „Three rules to rule them all“ finden Sie eine ausführliche Anleitung, wie Sie in Checkmk mit lediglich drei Regeln ein effizientes Netzwerk-Monitoring aufsetzen können.

Proxmox-Nodes in das Monitoring aufnehmen

Wenn Sie die Vorarbeiten abgeschlossen haben, können Sie nun Ihre Proxmox-Nodes in das Monitoring mit Checkmk aufnehmen. Wichtig ist, dass Sie beim Hinzufügen des Hosts im Bereich Monitoring Agents die Option Configured API integrations and Checkmk agent auswählen.

Einen Proxmox-Node in Checkmk anlegen

Anschließend konfigurieren Sie die API-Integration (Spezialagent). Dazu suchen Sie im Setup-Menü nach „Proxmox“ und wählen unter AgentsVM, Cloud, Container die Regel Proxmox VE aus. Dort hinterlegen Sie nun den in Proxmox angelegten Usernamen. Unter Explicit hosts geben Sie die Nodes Ihres Proxmox-Clusters an, die Checkmk über die API-Integration überwachen soll. Nach dem Speichern der Regel und Aktivierung der Änderungen sollte Checkmk nun sämtliche Services auf Ihren Proxmox-Hosts finden, darunter auch verschiedene Interfaces.

Die Regel Proxmox VE in Checkmk konfigurieren

Wenn Sie die oben verlinkte Anleitung für ein effizientes Monitoring der Interfaces befolgt haben, sollten die Interface-Namen nicht „Interface 1“, „Interface 2“ ... sein, sondern so lauten, wie sie auch der Linux Kernel darstellt, also zum Beispiel „Interface ens16“. Damit können Sie sehen, welche Schnittstellen zum lokalen Node gehören – diese fangen beispielsweise mit „bond“ oder „eno“ an – und welche von der Virtualisierung für die VMs angelegt wurden. Die VM-Schnittstellen beginnen je nach Konfiguration mit „fw“ und „tap“.

Proxmox-Cluster im Monitoring einrichten

Wie bereits erwähnt, lassen sich Proxmox-Server entweder als Single Nodes betreiben oder in einem Cluster, was der Regelfall ist. Den Proxmox-Cluster sollten Sie auch in Ihrem Monitoring abbilden, da sonst die oben genannten VM-Interfaces zwischen den Nodes „wandern“, wenn Sie eine VM oder einen Container von einer Node auf eine andere verschieben.

Dazu gehen Sie im Setup-Menü auf Hosts und klicken anschließend unter dem Reiter Host auf create new cluster. Dort legen Sie unter Hostname einen Namen für Ihren Cluster fest und fügen anschließend unter Nodes alle Proxmox-Server hinzu, die Sie dem Cluster zuordnen wollen. Wichtig ist, dass Sie unter IP address family das Dropdown-Menü auf No IP setzen. Zwar haben die einzelnen Proxmox-Nodes eine eigene IP, jedoch nicht der Proxmox-Cluster an sich. Daher ist es nicht notwendig beziehungsweise nicht möglich den Cluster anzupingen.

Im Bereich Monitoring agents ist es außerdem wichtig, dass Sie die Option Checkmk agent / API integrations auf die gleiche Einstellung setzen, die Sie bereits bei den einzelnen Nodes festgelegt haben: Configured API integrations and Checkmk agent. Wenn Cluster und Nodes nicht die gleiche Datenquelle haben, erhalten Sie ansonsten eine Fehlermeldung. Anschließend speichern Sie den Cluster.

Proxmox-Cluster in Checkmk erstellenn

Services einem Cluster zuweisen

Nun geben Sie im Setup-Menü „clustered“ in das Suchfeld ein und wählen unter Service monitoring rules die Regel Clustered services aus. In der anschließenden Maske aktivieren Sie die Checkbox bei Explicit hosts und fügen in der Reihe nun Ihre Proxmox-Nodes hinzu. In unserem Beispiel-Screenshot sind das die Nodes „pve-xyz-001.checkmk.com“,„pve-xyz-002.checkmk.com“ und „pve-xyz-003.checkmk.com“.

Nun aktivieren Sie die Checkbox bei Services und geben in die Felder die Such-Präfixe Interface fw und Interface tap an. Wie bereits erwähnt handelt es sich hierbei um die Interfaces einer VM oder eines Containers. Da Checkmk die Regel, wie es in der Beschreibung angegeben ist, auf die Nodes und nicht auf den Cluster-Host anwendet, ordnet es diese auf den Nodes gefundenen Interfaces nun dem Cluster zu.

Services in Checkmk einem Cluster zuweisen

Indem Sie die Container- beziehungsweise VM-Interfaces einem Cluster zuweisen, können die Services wie bereits erwähnt zwischen den einzelnen Nodes wandern, ohne dass Checkmk diese Interfaces als Vanished Services anzeigt beziehungsweise diese als neue Services auf dem „neuen“ Node erkennt. Dadurch müssen Sie die Interface-Services nicht auf dem einen Node entfernen und auf dem anderen neu hinzufügen, da diese weiterhin Bestandteil des Clusters bleiben. Nachdem Sie die Regel gespeichert und die Änderungen aktiviert haben, erkennt die Service Discovery die besagten Interfaces nun auf dem Cluster-Host.

Hinweis: Die Zuweisung der Interfaces auf Cluster-Ebene funktioniert jedoch nur, wenn Sie die oben verlinkte Anleitung „ Three rules to rule them all“ befolgt haben. Nur dann können Sie in Checkmk die Interfaces überhaupt sinnvoll filtern, da die Interfaces dadurch die benötigte Namensgebung erhalten.

Mit dieser Konfiguration bietet Ihnen Checkmk einen weiteren Vorteil: In der Host-Ansicht des Clusters sehen Sie nun unter Service etwa die Interfaces „fwbr“ mit einer Zahl dahinter. Bei der Zahl handelt es sich um die VM-ID. In der Summary können Sie außerdem erkennen, auf welchem Node sich das Interface befindet. Daraus können Sie zum Beispiel auf einem Blick ablesen, dass sich die VM mit der ID 100 auf dem Node pve-xyz-001.checkmk.com befindet. Auf diese Weise erhalten Sie mit Checkmk ein umfangreiches Monitoring Ihrer Proxmox-Umgebung.

Interfaces des Proxmox-Cluster in Checkmk

Sonderfall volatile VMs

Haben Sie in Ihrer Proxmox-Umgebung sehr volatile VMs, etwa Test-VMs, die Sie nicht überwachen wollen, empfehle ich Ihnen folgende Vorgehensweise: Erstellen Sie in Proxmox eine VM oder einen Container mit einer benutzerdefinierten VM-ID, die sich außerhalb Ihres normalen Zahlenbereichs befindet, etwa 600-699. Die Interfaces dieser VMs erscheinen in Checkmk beispielsweise als „Interface tap666i0“. Mit der Regel Disabled services im Setup-Menü können Sie mit der Regex „Interface fw6/d/d und „Interface tap6/d/d“ diese Interfaces matchen und dadurch von Ihrem Monitoring ausnehmen.

Weitere Vorteile des Proxmox-Monitorings mit Checkmk

Dank des Piggyback-Mechanismus der API-Integration kann Checkmk darüber hinaus Informationen aus den VMs abrufen, etwa den von der VM genutzten Speicherplatz oder Arbeitsspeicher. Sie erhalten außerdem Einblick darin, wie viel des zugeteilten Arbeitsspeichers der Container bereits nutzt oder wie dessen Backup-Status ist. Sollten Sie in einer VM keinen Agenten installieren dürfen, liefert Ihnen Checkmk auf diese Weise zumindest die wichtigsten Informationen zur VM und Sie haben den aktuellen Backup-Status jederzeit im Blick.

Wenn Sie für Ihren Proxmox-Server Ceph-Storage benutzen, empfehle ich Ihnen außerdem das Plugin Ceph statistics aus unserem Exchange. Es stellt Informationen zu Ceph-Statistiken, Pools, OSDs und dem allgemeinen Status bereit. Darüber hinaus bringt Checkmk einige offizielle Plugins für das Proxmox-Monitoring mit. Die Default-Schwellwerte für Ihre Proxmox-Services können Sie individuell anpassen, wenn Sie im Hamburger-Menü des jeweiligen Services auf Parameters for this service klicken.

Wanted: IT Monitoring Superheroes

Do you have an interesting story about working with Checkmk?

We'd like to hear from you!

Learn more
checkmk superhero

By posting a comment to this blog article or by subscribing to our blog notification system, you agree to our Privacy and Cookie Policy and consent that tribe29 GmbH can process your data and may contact you, if needed, in regards to the above mentioned purposes.