Workshop: Monitoring mit Checkmk – Teil 10 So monitoren Sie Proxmox VE mit Checkmk

Virtualisierungsplattformen sind längst selbst in mittleren IT-Umgebungen Standard – und natürlich kann auch Checkmk solche Plattformen samt VMs und Containern überwachen. Das Konzept ist simpel, die Praxis im Detail nicht immer, wie das Beispiel Proxmox VE zeigen wird.

Plattformen für Container und virtuelle Maschinen sorgen heute überall für gut skalierbare Infrastrukturen. Ob es nun Amazon AWS für SaaS-Angebote im großen Stil ist, das eigene Kubernetes für die Ausfallsicherheit der internen Server oder auch nur ein simpler Docker-Server, der Kleinstbetriebe mit Business-Anwendungen versorgt.

Bei der Überwachung solcher Systeme gibt es einige Besonderheiten. Die Server selbst sind freilich in der Regel kein Problem, aus Checkmk-Sicht sind die meisten Systeme ganz schlicht normale Linux-Hosts, die mit dem Standard-Agenten überwacht werden. Anders sieht es freilich bei den Container und VM aus. Zunächst mal lassen sich in solchen Instanzen oft keine eigenen Agenten einsetzen, beispielsweise weil sie über das Netzwerk nicht erreichbar sind. Oder der Aufwand ist zu groß. Zudem dürften häufig viele Daten, die der Linux-Agent erhebt gar nicht sonderlich relevant sein.

Bildergalerie

Bildergalerie mit 7 Bildern

Checkmks Lösung dafür hört auf die schönen Namen Piggyback und Spezialagent. Das Piggyback-Prinzip ist simpel: Die Management-Anwendungen, also etwa Docker oder VMware ESXi, haben ja allerlei Informationen über die Container und VMs, die sie verwalten. Diese Informationen werden dann über Spezialagenten abgefragt, die in der Regel schlicht die APIs der Virtualisierer abfragen. Im Monitoring wird der Virtualisierungs-Server als Host angelegt. Und eben dieser Host bringt dann neben seinen eigenen Daten auch die Daten der virtuellen Systeme mit ins Monitoring – also huckepack/piggyback.

Im Monitoring werden anschließend Hosts für die einzelnen VMs und Container erstellt und die huckepack genommenen Daten werden diesen Hosts zugeordnet. Der Virtualisierungs-Host zeigt dann später Meta-Informationen wie die Version des Virtualisierers oder die Anzahl der VMs. Und die einzelnen VM-Hosts zeigen, was auch immer der jeweilige Spezialagent zu fassen bekommt.

Die Zuordnung von Piggyback-Daten zu den passenden Piggyback-Hosts ist die eigentliche Magie: Wenn der Spezialagent Daten zu einer VM namens „foobar-123“ liefert und in Checkmk ein Host namens „foobar-123“ existiert, werden die Daten automatisch diesem Host zugeordnet. Ganz wichtig für alle Plattformen: Der Name muss entsprechend exakt übereinstimmen!

Und schon poppt bei erfahrenen VM- und Container-Nutzern eine Frage auf: Was ist mit flüchtigen Instanzen? An der Stelle treffen Sie auf eines der wenigen Features, die nur den kommerziellen Checkmk-Editionen spendiert werden: Dynamische Host-Verwaltung mit dem Dynamic Configuration Daemon (DCD). Der DCD kann Hosts, für die Piggyback-Daten existieren, eigenständig im Monitoring anlegen und löschen.

Ein guter Einstieg in die Überwachung von VMs und Container ist der Artikel zu Spezialagenten im offiziellen Handbuch. Dort finden Sie auch explizite Artikel zu VMWare ESXi, AWS, GCP, Kubernetes, Docker, OpenShift und Azure.

Was noch fehlt ist die Open-Source-Lösung Proxmox, die speziell seit Broadcoms VMWare-Übernahme zunehmend in den Fokus rückt.

Proxmox überwachen

Die Überwachung von Proxmox folgt dem oben beschriebenen Muster, das wir hier nun im Detail vorstellen. Von Checkmk selbst gibt es zwar ältere Beiträge zu dem Thema, die im Detail allerdings lückenhaft sind beziehungsweise in der aktuellen Version so nicht mehr ganz korrekt. Also wird es ab hier etwas kleinteiliger.

Wenn Sie bereits einen Proxmox-Server betreiben – perfekt. Zum Testen lässt sich allerdings auch die einfache Desktop-Virtualisierung Oracle VirtualBox verwenden, auch wenn der Betrieb einer Virtualisierungsplattform in einer weiteren Virtualisierungsplattform nicht wirklich in der Best-Practice-Liga spielt.

Sobald Proxmox läuft, haben Sie standardmäßig ein Cluster namens „Datacenter“ und darunter den Standard-Node namens „pve“, der für den Proxmox-Server selbst steht (egal, ob dieser nun echte Hardware oder eine VirtualBox-VM ist).

Für das Datacenter müssen zunächst die Voraussetzungen geschaffen werden, damit Checkmk darauf zugreifen und Node-Informationen beziehungsweise später VM-/Container-Daten beziehen kann. Sie benötigen für einen vollständigen Test

• eine Gruppe, beispielsweise namensgebend „Read_only“,

• Gruppenrechte für den Basispfad (/) und die Rolle „PVEAuditor“ (für umfassende Leserechte),

• einen Nutzeraccount namens „checkmk“ in der erstellten Gruppe (samt Passwort) sowie

• eine virtuelle Maschine, hier im Beispiel etwa auf Bunselabs-Basis mit dem Namen „Bunsen1“.

Die Proxmox-Konfiguration können Sie in der Bildergalerie nachvollziehen (siehe Abbildung 1 bis 3).

Sinnvollerweise sollte anschließend der reguläre Checkmk-Agent auf dem Proxmox-Server installiert werden, um diesen als ganz normalen Host überwachen zu können.

Dann geht es endlich in der Weboberfläche von Checkmk weiter. Zunächst sollte der Proxmox-Server als Host erstellt werden, der Nachvollziehbarkeit am besten mit dem auch in Proxmox verwendeten Namen, standardmäßig also „pve“. Einzige Besonderheit in dessen Konfiguration: In den Einstellungen zum Monitoring-Agenten sollte „Configured API integrations AND Checkmk agent“ gewählt werden. „API integrations“ ist ein anderer Ausdruck für Spezialagent.

Es folgt der Host, der zur virtuellen Maschine „Bunsen1“ aus Proxmox gehört (siehe Abbildung 4). Hier müssen zwei Einstellungen gesetzt werden: Zum einen muss die Option „No IP“ gesetzt werden – anderfalls produziert Checkmk Fehlermeldungen bezüglich der Namensauflösung. Zum anderen muss der Monitoring-Agent auf „No API integrations, no Checkmk agent“ gesetzt werden – schließlich wird die VM selbst nicht abgefragt, Daten kommen per Piggyback.

Es gibt im Monitoring nun also den Host für den Proxmox-Server (pve) und den Host für die virtuelle Maschine (Bunsen1) – fehlt noch der Spezialagent, um Daten von „pve“ zu besorgen und „Bunsen1“ zuzuordnen.

Die zugehörige Regel ist „Proxmox VE“, zu finden im Bereich „VM, cloud, container“ im Agenten-Setup. Zwingend sind hier folgende Angaben (siehe Abbildung 5):

• Nutzername in der Form „checkmk@pve“,

• Passwort,

• Beschränkung der Regel auf den Proxmox-Server/-Host, hier also abermals „pve“.

Damit wäre die Konfiguration abgeschlossen und es können Service-Erkennungen für die beiden neuen Hosts durchgeführt werden. Beim Proxmox-VM-Host „Bunsen1“ wird dann auch sichtbar, woher die Daten kommen: Die Meldung „Piggyback: Successfully processed from source pve“ sollte erscheinen (siehe Abbildung 6).

Nun, da Proxmox-Server und -VM als Hosts „pve“ und „Bunsen1“ im Monitoring zur Verfügung stehen, können die Proxmox-spezifischen Services ganz einfach in Dashboards und Ansichten gefiltert werden – denn sie beginnen alle mit „Proxmox VE“. Ein Dashboard, das lediglich die Ansicht „All Services“ mit einem entsprechenden Namensfilter zeigt, bietet so zum Beispiel eine Übersicht aller relevanten Daten (siehe Abbildung 7).

Cluster

In der Praxis werden Virtualisierungs-Server häufig als Cluster betrieben und sollten dann auch als solche in Checkmk abgebildet werden. Das Prozedere ist unabhängig von der konkreten Technologie immer gleich simpel:

In der Hosts-Verwaltung lassen sich Host-Cluster ganz ähnlich wie Hosts selbst erstellen: Hosts hinzufügen, den Agenten wieder auf „Configured API integrations AND Checkmk agent“ setzen und letztlich die IP-Adresse auf „No IP“ (wie schon oben beim Proxmox-VM-Host).

Dann müssen über die Regel „Clustered services“ nur noch die gewünschten Services den passenden Clustern zugewiesen werden – via direkter Auswahl oder regulärer Ausdrücke.

Das Aufsetzen von Clustern ist im Grunde intuitiv möglich. Über das Inhaltliche müssen Sie sich freilich Gedanken machen. Am Ende hat diese Cluster-Abbildung einen großen Vorteil: Services können mal auf diesem, mal auf jenem Proxmox-Node laufen, ohne Statusänderungen und Benachrichtigungen auszulösen.

Ob nun Proxmox oder eine andere Virtualisierungsplattform, lässt man die Checkmk-Begrifflichkeiten mal außen vor, stellt sich das Prozedere ziemlich trivial dar: Checkmk bekommt die API-Zugangsdaten für den Virtualisierer und ordnet die gelieferten Daten zu VMs und Containern gleichnamigen Hosts zu.

Workshop: Monitoring mit Checkmk – Teil 1

Wie funktioniert das Monitoring mit Checkmk?

Workshop: Monitoring mit Checkmk – Teil 2

Monitoring von Servern und Workstations

Workshop: Monitoring mit Checkmk – Teil 3

Monitoring von Webseiten, Mailkonten und Applikationen

Workshop: Monitoring mit Checkmk – Teil 4

Wie sieht eine gute Strukturierung in Checkmk aus?

Workshop: Monitoring mit Checkmk – Teil 5

Die wichtigsten Schritte zur Backup-Überwachung mit Checkmk

Workshop: Monitoring mit Checkmk – Teil 6

Wie funktioniert das Überwachen von Schnittstellen und Ports mit Checkmk?

Workshop: Monitoring mit Checkmk – Teil 7

Dashboards aus Daten: So wird das Checkmk-Inventar sichtbar

Workshop: Monitoring mit Checkmk – Teil 8

Checkmk aktualisieren – vorsichtig!

Workshop: Monitoring mit Checkmk – Teil 9

Checkmk: Android-Geräte überwachen – oder nicht?

Workshop: Monitoring mit Checkmk – Teil 10

So monitoren Sie Proxmox VE mit Checkmk

Workshop: Monitoring mit Checkmk – Teil 11

Webseiten mit check_httpv2 überwachen – auch ohne Checkmk!

Workshop: Monitoring mit Checkmk – Teil 12

Zertifikate mit check_cert überwachen – auch ohne Checkmk!

Workshop: Monitoring mit Checkmk – Teil 13

Checkmk anpassen: Ansichten nach Belieben gestalten

(ID:50447216)