HomeLabNext Monitoring Teil 4: Checkmk einrichten und Proxmox als ersten Host überwachen

Nach der Installation ist Checkmk zwar erreichbar – produktiv eingerichtet ist das Monitoring damit aber noch lange nicht. In Teil 4 räume ich zuerst die Checkmk-Basis auf, sichere den Admin-Zugang ab und binde anschließend meinen ersten Proxmox-Node über API und Linux-Agent an. Dabei zeigt sich direkt, warum ein Monitoring-Aufbau erst im echten Betrieb sinnvoll dimensioniert werden kann.

Ausgangslage

Checkmk läuft als unprivilegierter LXC auf Proxmox. Die Site heißt monitoring. Nach dem tmpfs-Fix aus Teil 3 lief die Site sauber, zunächst mit 2 CPU-Cores und 2 GB RAM. Genau mit dieser bewusst kleinen Ausgangskonfiguration ging es weiter.

Praxis-Hinweis: Das Proxmox Community Helper Script legt die initialen Checkmk-Zugangsdaten im LXC ab. Sie lassen sich mit cat ~/checkmk.creds anzeigen.

1. Apache-Default-Seite aufräumen

Beim Aufruf der reinen HTTP-Adresse ohne /monitoring erschien zunächst die Debian-Apache-Default-Seite. Technisch kein Fehler, für eine Monitoring-Appliance aber unnötig.

Vor der Bereinigung landete die Root-URL noch auf der Debian-Apache-Default-Seite.

Die Default-Site wurde deshalb so angepasst, dass nur die Root-URL auf /monitoring/ umleitet. Einen externen Hostnamen habe ich bewusst nicht fest verdrahtet, weil der spätere Zugriff über einen separaten nginx-Reverse-Proxy erfolgen soll.

<VirtualHost *:80>n    RedirectMatch 302 ^/$ /monitoring/n    ErrorLog ${APACHE_LOG_DIR}/error.logn    CustomLog ${APACHE_LOG_DIR}/access.log combinedn</VirtualHost>

Danach: apache2ctl configtest und systemctl reload apache2.

2. Checkmk-Grundeinstellungen prüfen – nicht alles anfassen

Frische Checkmk-Installation vor dem ersten echten Host.

Unter Setup → General → Global settings habe ich die grundlegenden Bereiche geprüft. Die wichtigste Erkenntnis: Fast alle Defaults können zunächst bleiben. Service Discovery, Check-Ausführung, Benachrichtigungen und UI-Einstellungen werden erst dann angepasst, wenn ein konkreter Grund besteht.

Die globalen Service-Discovery-Einstellungen blieben zunächst weitgehend auf Standard.

Benachrichtigungen habe ich bewusst noch nicht scharf geschaltet. Erst sollen Hosts und Services stabil laufen, sonst erzeugt der Aufbau nur unnötigen Alarm-Spam.

3. Persönlichen Admin und 2FA einrichten

Statt dauerhaft mit dem initialen cmkadmin-Account zu arbeiten, habe ich einen persönlichen Administrator angelegt. Der generierte Admin bleibt vorerst als Break-Glass-Zugang bestehen.

Danach wurde für den persönlichen Admin die Zwei-Faktor-Authentifizierung eingerichtet und der Login getestet. Backup-Codes gehören in einen Passwortmanager und nicht auf den Checkmk-Server.

Checkmk bietet Authenticator-App, Security-Token und Backup-Codes für 2FA.

4. Eine schlanke Host-Struktur

Bevor der erste Host angelegt wurde, habe ich eine einfache Ordnerstruktur erstellt. Ordner sind in Checkmk nicht dasselbe wie Host-Gruppen: Sie dienen der organisatorischen Struktur und können Einstellungen und Regeln vererben.

Die erste Ordnerstruktur: Network, Servers, Services, SmartHome und Virtualization.

Für den aktuellen Aufbau reichen fünf Bereiche: Network, Servers, Services, SmartHome und Virtualization. Einen eigenen Storage-Ordner gibt es nicht – ein einzelner Unraid-Server landet unter Servers.

5. Proxmox: API-Zugang mit minimalen Rechten

Für die Proxmox-API wurde ein eigener Benutzer checkmk@pve angelegt. Er bekommt keine Admin-Rechte, sondern ausschließlich die Rolle PVEAuditor auf Pfad / mit aktivierter Vererbung.

Read-only-Berechtigung für den Checkmk-Proxmox-Benutzer über PVEAuditor.

In Checkmk folgt anschließend unter Setup → Agents → VM, cloud, container → Proxmox VE eine Regel für den Special Agent. Die Regel wird explizit auf den Proxmox-Host beschränkt. Da auf Proxmox aktuell noch kein von Checkmk vertrauenswürdiges Zertifikat eingesetzt wird, ist die Zertifikatsvalidierung für diesen ersten Aufbau deaktiviert. Das ist eine Übergangslösung; langfristig soll die CA sauber vertraut werden.

Der Proxmox-Special-Agent mit expliziter Einschränkung auf den Proxmox-Host. Der interne Hostname wurde anonymisiert.

Der erste Test war erfolgreich: Die Proxmox-API lieferte Node-Info, Memory- und CPU-Allocation, HA-/Quorum-Status, Storage-Informationen, Replication und Uptime.

6. Zusätzlich den normalen Checkmk-Linux-Agent installieren

Die Proxmox-API ersetzt nicht das Betriebssystem-Monitoring. Deshalb wurde zusätzlich das aktuelle Debian-Paket des Checkmk-Agenten auf dem Proxmox-Node installiert und der Agent Controller gegen die Checkmk-Site registriert.

apt install ./check-mk-agent_2.5.0p11-1_all.debnncmk-agent-ctl register \n  --hostname <PROXMOX-HOST> \n  --server <CHECKMK-SERVER> \n  --site monitoring \n  --user agent_registration

Für agent_registration wird das Automation Secret verwendet. Nach erfolgreicher Registrierung meldete Checkmk sowohl den normalen Agenten als auch den Proxmox-Special-Agent als erfolgreich.

7. Die erste große Service Discovery – und direkt ein OOM

Mit API und Linux-Agent kamen auf dem ersten Proxmox-Node sofort mehr als 100 erkannte Services zusammen: CPU, RAM, Filesysteme, ZFS, Corosync, Temperaturen, Interfaces, systemd-Dienste und diverse Proxmox-spezifische Checks.

Genau dabei zeigte sich die erste echte Grenze der ursprünglichen Dimensionierung: Die komplette Checkmk-Site stoppte.

Während der ersten großen Discovery war die komplette Checkmk-Site gestoppt.

Im Journal war die Ursache eindeutig:

omd.service: A process of this unit has been killed by the OOM killer.nomd.service: Failed with result 'oom-kill'.nomd.service: ... 1.9G memory peak.

Die 2 GB RAM waren im Leerlauf ausreichend, aber für den ersten größeren Discovery-Lauf zu knapp. Der LXC wurde deshalb auf 4 GB RAM erhöht. Danach standen rund 2,8 GB frei zur Verfügung und die Site lief wieder stabil.

Das ist genau der Grund für klein starten: Nicht vorsorglich Ressourcen verschwenden, sondern unter realer Last messen und dann gezielt erhöhen.

8. Nicht jeden erkannten Service blind übernehmen

Der Linux-Agent findet auf einem Proxmox-Host sehr viel. Sinnvoll sind unter anderem CPU, Load, RAM, Disk-I/O, reale Filesysteme, ZFS-/Storage-Status, Corosync, NTP, Temperaturen, systemd-Zusammenfassung und wichtige Proxmox-Prozesse.

Weniger sinnvoll sind zahlreiche dynamische virtuelle Interfaces wie tap*, veth*, fwbr*, fwpr* oder ähnliche VM-/Firewall-Interfaces. Auch alte Storage-Strukturen sollen später über Discovery-Regeln sauber ausgeblendet werden, statt dauerhaft die Service-Liste zuzumüllen.

9. Monitoring findet sofort echte Baustellen

Schon beim ersten Durchlauf meldete Checkmk mehrere WARN- und CRIT-Zustände: ein nahezu volles CIFS-Backup-Ziel, einzelne stark belegte Container-Dateisysteme, CPU-/RAM-Overcommitment, eine hohe Thread-Zahl, eine auflaufende Postfix-Queue, einen fehlgeschlagenen systemd-Service und einen CPU-Temperatur-Peak.

Diese Punkte werden nicht für den Artikel künstlich „grün“ gemacht. Genau sie sind der nächste Schritt: prüfen, echte Fehler beheben und anschließend nur dort Schwellwerte anpassen, wo die Defaults nicht zum bewusst überbuchten Homelab passen.

Zwischenstand

Damit ist der erste Proxmox-Node technisch vollständig an Checkmk angebunden: Proxmox-API für Plattformdaten plus Linux-Agent für das Betriebssystem. Gleichzeitig hat der Aufbau bereits zwei wichtige Praxisprobleme sichtbar gemacht – zu wenig RAM für den Checkmk-LXC und mehrere reale WARN/CRIT-Zustände auf dem Hypervisor.

Im nächsten Schritt geht es nicht sofort zum nächsten Gerät. Zuerst werden die gefundenen Probleme in Ruhe abgearbeitet und die Discovery-Regeln so angepasst, dass nur dauerhaft relevante Services übrig bleiben. Danach folgen Palo Alto, Unraid, Home Assistant und weitere Hosts.