Nach dem Toolvergleich wird es praktisch: Checkmk soll als zentrale Monitoring-Plattform auf Proxmox laufen. Für den Aufbau nutze ich das Community Helper Script, gehe aber bewusst durch den Advanced-Installer. So sehe ich genau, welche Ressourcen und LXC-Funktionen aktiviert werden.
Warum Advanced Install?
Der Default-Installer wäre schneller. Für ein System, das später große Teile meines Homelabs überwachen soll, möchte ich aber nachvollziehen können, wie der Container aufgebaut ist. Deshalb wähle ich Advanced Install und gehe jede relevante Option einzeln durch.
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/checkmk.sh)"
Die Advanced-Installation Schritt für Schritt
1. Container-Typ – Unprivileged
Checkmk benötigt keine privilegierten Host-Rechte. Deshalb bleibt der Container unprivileged. Das ist die sauberere Sicherheitsbasis und reicht für Checkmk vollkommen aus.
2. Root-Passwort
Der Helper kann den Container auch ohne gesetztes Root-Passwort erstellen. Ich vergebe bewusst ein eigenes Passwort für die lokale Administration des LXC. Das Passwort selbst ist im Screenshot nicht sichtbar.
3. Passwort bestätigen
Das Root-Passwort wird noch einmal bestätigt. Das ist nur ein normaler Kontrollschritt des Installers.
4. Container-ID
Die Container-ID folgt meinem eigenen Proxmox-Schema. Da die konkrete Nummer für andere Nutzer keinerlei Mehrwert hat, wird dieser Schritt nur beschrieben und nicht als Screenshot veröffentlicht.
5. Hostname
Als Hostname verwende ich schlicht checkmk. Der Name ist kurz, eindeutig und beschreibt direkt die Funktion des Systems.
6. Disk-Größe
Für den Start reichen mir 10 GB. Die Checkmk-Basis benötigt nur einen Teil davon. Falls die Installation später wächst, kann ich die Root-Disk des LXC in Proxmox problemlos vergrößern.
7. CPU-Cores
Ich starte mit 2 CPU-Cores. Das reicht für die erste Ausbaustufe. Ob später mehr nötig ist, sollen reale Monitoring-Daten zeigen.
8. RAM
Auch beim RAM starte ich bewusst klein mit 2 GB. Ein LXC lässt sich später einfach auf mehr RAM erweitern, ohne das System neu aufzubauen.
9. Netzwerk-Bridge
Der Container hängt an der VLAN-aware Bridge des Proxmox-Hosts. Dadurch kann der LXC sauber in das vorgesehene Servernetz eingeordnet werden. Die konkrete Bridge-Konfiguration und weitere interne Netzwerkbezeichnungen zeige ich nicht als Screenshot.
10. IPv4-Modus
Für ein Monitoring-System möchte ich eine feste Adresse. Deshalb wähle ich Static statt DHCP. Das macht Webzugriff, Firewall-Regeln und spätere Agent-Verbindungen eindeutig.
11. Statische IPv4-Adresse
Hier wird die feste Adresse im Servernetz eingetragen. Die reale interne IP veröffentliche ich nicht.
12. Gateway
Als Gateway wird das Gateway des Servernetzes gesetzt. Auch dieser Wert bleibt intern und erscheint nicht im Blog.
13. MTU
Die MTU lasse ich auf dem normalen Standardwert. Jumbo Frames bringen für Checkmk hier keinen Vorteil und würden nur eine weitere Fehlerquelle schaffen.
14. DNS Search Domain
Die interne Search-Domain hilft später bei der Namensauflösung interner Systeme. Der konkrete Domainname bleibt privat und wird nicht als Screenshot gezeigt.
15. DNS-Server
Checkmk verwendet meine internen DNS-Resolver. Damit kann das Monitoring später interne Hosts per DNS erreichen. Die konkreten DNS-Adressen veröffentliche ich nicht.
16. VLAN-Tag
Der LXC wird in das vorgesehene Server-VLAN eingeordnet. Die konkrete VLAN-ID bleibt intern. Entscheidend ist das Prinzip: VLAN-aware Bridge plus VLAN-Tag am virtuellen Interface.
17. Container-Tags
Mit Tags wie community-script und monitoring lässt sich der LXC in der Proxmox-Oberfläche später leichter wiederfinden. Technisch notwendig sind die Tags nicht.
18. SSH-Key-Quelle
Der Helper kann vorhandene SSH-Keys übernehmen. Für meinen ersten Aufbau übernehme ich keine zusätzlichen Keys vom Proxmox-Host. Die Proxmox-Konsole reicht als administrativer Zugriff.
19. Root-SSH
Root-SSH bleibt deaktiviert. Checkmk benötigt keinen direkten Root-Zugang über das Netzwerk. Weniger Remote-Zugänge bedeuten weniger Angriffsfläche.
20. FUSE
FUSE wäre beispielsweise für rclone oder Userspace-Dateisysteme nötig. Checkmk braucht das nicht, also bleibt die Option aus.
21. TUN/TAP
TUN/TAP wird typischerweise für VPN-Software oder spezielle Netzwerkfunktionen gebraucht. Der Checkmk-LXC ist kein VPN-Gateway und benötigt diese Funktion nicht.
22. Nesting
Nesting würde Docker oder weitere Container innerhalb des LXC ermöglichen. Genau das möchte ich hier nicht. Checkmk läuft direkt im LXC, deshalb bleibt Nesting deaktiviert.
23. GPU-Passthrough
Für Monitoring ist keine GPU-Beschleunigung nötig. GPU-Passthrough bleibt daher aus.
24. APT Cacher
Ein lokaler APT-Cacher kann bei vielen Debian-Systemen Bandbreite sparen. Für diesen Aufbau brauche ich ihn nicht.
25. HTTP/HTTPS-Proxy
Der Container darf direkt über mein Netzwerk auf Paketquellen zugreifen. Ein zusätzlicher HTTP-Proxy ist nicht erforderlich.
26. Zeitzone
Die Zeitzone setze ich passend zum Proxmox-Host. Bei Monitoring ist eine korrekte Zeit besonders wichtig, damit Alarme und historische Daten später sauber zusammenpassen.
27. Container Protection
Protection kann vor versehentlichem Löschen schützen. Für ein Monitoring-System, das später selbst wichtig für das Homelab wird, ist das sinnvoll.
28. Device Node Creation
Checkmk benötigt keine zusätzlichen Device Nodes. mknod bleibt daher deaktiviert.
29. Zusätzliche Filesystem-Mounts
Für den Checkmk-Basisbetrieb brauche ich keine zusätzlichen NFS-, CIFS- oder sonstigen Mounts. Das Feld bleibt leer.
30. Post-Install Hook
Ich verwende keinen eigenen Post-Install-Hook. Dadurch bleibt die Installation möglichst nah am Community Script und leichter nachvollziehbar.
31. Verbose Mode
Beim ersten Aufbau aktiviere ich Verbose Mode. Dadurch sehe ich die einzelnen Installationsschritte und Warnungen direkt. Genau das hat sich später beim tmpfs-Problem ausgezahlt.
Vor dem Start: Zusammenfassung kontrollieren
Bevor der Container wirklich erstellt wird, zeigt der Helper noch einmal die vollständige Konfiguration. Hier kontrolliere ich vor allem Container-Typ, CPU, RAM, Disk und die deaktivierten Sonderfunktionen. Da diese Übersicht gleichzeitig interne Netzwerk- und Infrastrukturwerte enthält, veröffentliche ich davon bewusst keinen Screenshot.
Die Advanced-Einstellungen speichere ich nicht als allgemeine Vorlage. Werte wie IP, VLAN oder Ressourcen können beim nächsten Container anders aussehen.
Installation und erste Anmeldung
Danach erstellt das Script den Debian-LXC, installiert Checkmk und legt die erste Site an. Die originale Terminal-Ausgabe enthält interne Werte und automatisch generierte Zugangsdaten. Deshalb wird sie im Beitrag nicht als Screenshot verwendet.
Die vom Helper erzeugten Login-Daten lassen sich anschließend direkt auf dem Checkmk-LXC auslesen:
cat ~/checkmk.credsDamit erhält man die für den ersten Login benötigten Zugangsdaten. Nach dem ersten Login sollte das automatisch erzeugte Passwort geändert werden.
Das erste echte Problem: tmpfs
Checkmk war nach der Installation erreichbar und die Site lief. Im Terminal erschien allerdings eine Warnung, dass das temporäre Site-Verzeichnis nicht wie vorgesehen als tmpfs gemountet werden konnte.
WARNING: You may continue without tmpfs,
but the performance of Check_MK may be degraded.Mit folgendem Befehl lässt sich prüfen, wo das temporäre Verzeichnis tatsächlich liegt:
df -h /opt/omd/sites/monitoring/tmpIn meinem Fall zeigte die Ausgabe noch das Root-Filesystem des LXC. Das Helper Script hatte zwar bereits einen passenden Eintrag in /etc/fstab erzeugt, der Mount wurde im unprivilegierten LXC aber nicht aktiv – auch nicht nach einem Reboot.
tmpfs /opt/omd/sites/monitoring/tmp tmpfs noauto,user,mode=751,uid=monitoring,gid=monitoring 0 0Die Lösung auf dem Proxmox-Host
Die saubere Lösung war, den tmpfs-Mount direkt in der LXC-Konfiguration auf dem Proxmox-Host bereitzustellen.
pct stop <CTID>
# /etc/pve/lxc/<CTID>.conf
lxc.mount.entry: tmpfs opt/omd/sites/monitoring/tmp tmpfs rw,nosuid,nodev,size=512M,mode=0751,uid=999,gid=988,create=dir 0 0
pct start <CTID>Danach ließ sich kontrollieren, dass /opt/omd/sites/monitoring/tmp tatsächlich als 512-MB-tmpfs gemountet war und die Checkmk-Site weiterhin vollständig lief.
Ergebnis
Die Ressourcen lasse ich vorerst bei 2 CPU-Cores, 2 GB RAM und 10 GB Disk. Wenn das Monitoring später wächst, kann ich RAM und Storage in Proxmox problemlos erweitern.
Wie es weitergeht
Im nächsten Teil binde ich den ersten echten Host ein: Proxmox selbst. Dann sehen wir, welche Services Checkmk automatisch erkennt und welche Checks für mein Homelab wirklich sinnvoll sind.