Deshalb habe ich mich entschieden, Beszel als schlanke Monitoring-Lösung auf meinem VPS einzusetzen.

Warum zusätzlich zu Dockhand?

Für die Verwaltung meiner Docker-Container verwende ich bereits Dockhand. Damit lassen sich Container, Stacks und deren aktueller Zustand komfortabel verwalten.

Was mir derzeit allerdings fehlt, ist eine vernünftige Langzeitansicht der Systemressourcen. Ich möchte nicht nur sehen, wie stark mein VPS gerade ausgelastet ist, sondern auch nachvollziehen können, wie sich der Ressourcenverbrauch über mehrere Tage oder Wochen entwickelt.

Genau hier soll Beszel ansetzen. Dockhand bleibt weiterhin für die Containerverwaltung zuständig, während Beszel die Ressourcenüberwachung übernimmt.

Was ist Beszel?

Beszel ist eine leichtgewichtige, quelloffene Monitoring-Lösung, die sich besonders für kleinere Serverumgebungen und Homelabs eignet.

Die Software besteht aus zwei Komponenten:

• Beszel Hub: Zentrale Weboberfläche zur Anzeige und Auswertung der Messwerte.
• Beszel Agent: Erfasst die Systeminformationen und übermittelt sie an den Hub.

Neben klassischen Systemmetriken kann Beszel auch den Ressourcenverbrauch einzelner Docker-Container erfassen.

Damit eignet sich die Software gut für meinen VPS, ohne gleich eine umfangreiche Monitoring-Infrastruktur mit Prometheus und Grafana aufbauen zu müssen.

Welche Ressourcen möchte ich überwachen?

Im Mittelpunkt steht die langfristige Entwicklung der Ressourcenauslastung.

Besonders wichtig ist mir dabei die Überwachung des Festplattenspeichers. Damit Beszel die Speicherplatzbelegung der primären Systempartition korrekt überwachen konnte, musste nach der initialen Bereitstellung zusätzlich die Umgebungsvariable FILESYSTEM im Beszel-Agent definiert werden.

    environment:
      [...]
      FILESYSTEM: "vda1"

Einblicke in das Monitoring

Systemübersicht

Die Gesamtübersicht zeigt die wichtigsten Ressourcen meines VPS auf einen Blick. Dazu gehören unter anderem CPU-Auslastung, Arbeitsspeicher und Festplattenbelegung. So lässt sich schnell erkennen, wie stark das System ausgelastet ist und wie sich die Werte im Zeitverlauf entwickeln. Die Ansicht lässt sich zwischen Tabelle und Raster (siehe Bild) umstellen.

Netzwerk-Monitore

Die Netzwerk-Monitore zeigen die Ergebnisse verschiedener Prüfungen, die der Beszel-Agent durchführt. Dazu gehören unter anderem Ping-Tests, DNS-Namensauflösung, HTTP-Requests und weitere Netzwerkchecks. So lassen sich Erreichbarkeitsprobleme, erhöhte Antwortzeiten oder Störungen bei der Namensauflösung frühzeitig erkennen.

Ressourcen-Detailansicht

In der Detailansicht lässt sich der Ressourcenverbrauch einzelner Docker-Container genauer betrachten. Damit kann ich beispielsweise feststellen, welche Anwendungen besonders viel RAM oder CPU benötigen und wie sich Konfigurationsänderungen auf deren Auslastung auswirken.

Benachrichtigungen über Discord

Wie bei meinen anderen Diensten sollen auch die Benachrichtigungen von Beszel über Discord erfolgen. So kann ich beispielsweise über kritische Ressourcenauslastungen oder knapp werdenden Speicherplatz informiert werden, ohne regelmäßig die Monitoring-Oberfläche öffnen zu müssen.

Die Webhook-URL wird in Discord erstellt und hat folgendes Format:

https://discord.com/api/webhooks/WEBHOOKID/TOKEN

Für Beszel muss die URL in folgendes Format umgewandelt werden:

discord://TOKEN@WEBHOOKID

E-Mail-Benachrichtigungen, wie ich sie während jedem Setup erstmal einrichte, wären möglicherweise die robustere Variante, da sie weniger von einem für mich nicht steuerbaren Provider abhängig sind. Allerdings möchte ich vermeiden, dass meine Postfächer durch exzessive technische Meldungen überflutet werden.

Deshalb bleibt Discord mein bevorzugter Benachrichtigungskanal für das laufende Monitoring (analog zu Uptime Kuma).

Eine Ausnahme bleibt Dockhand: Die Containerverwaltung selbst darf weiterhin E-Mails versenden. Damit behalte ich für wichtige Verwaltungs- und Backup-Meldungen einen zusätzlichen Kommunikationsweg, der auch dann funktioniert, wenn Beszel und Uptime Kuma mal ausgefallen sind.

Sicherheit

Gemäß meinem Sicherheitskonzept werden administrative Schnittstellen ausschließlich über das WireGuard-VPN bereitgestellt. Bei Beszel betrifft dies sowohl das Monitoring-Frontend als auch die integrierte PocketBase-Administrationsoberfläche. Da beide über denselben Dienst (und TCP-Port) erreichbar sind, wird der Zugriff bereits auf Netzwerkebene auf das WireGuard-Interface beschränkt.

Ein weiteres Argument ist, dass Monitoring-Daten wie CPU- und Speicherauslastung, Dateisystembelegung und Container-Status detaillierte Einblicke in die Systeminfrastruktur ermöglichen. Da diese Informationen ausschließlich administrativen Zwecken dienen, besteht keine Notwendigkeit, sie über das öffentliche Internet zugänglich zu machen.

Fazit

Mit Beszel habe ich eine schlanke Ergänzung zu Dockhand gefunden, um die Ressourcen meines VPS und der einzelnen Docker-Container langfristig im Blick zu behalten. Die historischen Messwerte sind eine signifikante Verbesserung meiner Einblicke in die Entwicklung meines VPS über die nächsten Wochen und Monate.

Die Einrichtung ist unkompliziert, der Ressourcenbedarf gering und dank Discord-Benachrichtigungen muss ich die Oberfläche nicht ständig kontrollieren, außerdem werden meine E-Mail-Postfächer nicht überflutet und ich bekomme Benachrichtigungen an meinem Smartphone (und sogar meiner Smartwatch) dadurch angezeigt. Für meine aktuelle VPS-Umgebung bietet Beszel damit genau den Funktionsumfang, den ich benötige.

Der Beitrag Homelab – Monitoring mit Beszel erschien zuerst auf Maximilian Krieg.

Zurück kamen verschiedene Vorschläge, insbesondere hier ein großes Dankeschön an Jonas, Julian, Nils und Robin, deren Anregungen ich mit meinen eigenen bisherigen Homelab-Projekten und weiteren Empfehlungen aus Artikeln und Community-Diskussionen zusammengeführt habe.

Die in diesem Artikel entstandene Liste ist ausdrücklich keine Bewertung und keine Rangliste. Der Artikel dient vielmehr als Auftakt für eine Serie und soll zunächst Stichpunktartig zeigen, welche Projekte zusammengekommen sind, was sie machen und welche davon für weitere Tests interessant sein könnten. Dabei berücksichtige ich ebenfalls, dass ich verschiedene Docker-Plattformen habe und es durchaus sein kann, dass ein Container auf einer oder mehreren dieser Plattformen für mich (keinen) Sinn ergeben würde.

Meine drei Docker-Plattformen

Für den Betrieb und die Tests stehen mir drei unterschiedliche Docker-Plattformen zur Verfügung.

Ich habe mir vorgenommen sie nach diesen Zwecken differenziert einzusetzen:

• NAS: Zentraler Datenspeicher und Host für Anwendungen mit direktem Bezug zu größeren oder dauerhaft gespeicherten Datenbeständen.
• Raspberry Pi: Stromsparender 24×7-Host für kleinere Dienste, Netzwerktools, Monitoring und Automatisierungen.
• VPS: Unabhängiger 24×7-Host für dauerhaft verfügbare und extern benötigte Dienste. Je nach Anwendung erfolgt der Zugriff dann öffentlich oder geschützt über VPN.

Den Aufbau und die technische Umsetzung meiner Docker-Umgebung werde ich in einem separaten Artikel nochmals ausführlicher beschreiben.

Containerverwaltung

Monitoring

Netzwerkmanagement

Netzwerkdienste

IT-Sicherheit

Dateimanagement

Medienverwaltung

Webanwendungen

Datenbanken

Produktivität

Gaming

IT-Administration

Benachrichtigungen

Entwicklung & Versionsverwaltung

Automatisierung

Datensicherung

E-Learning

Wissensmanagement

Die Zuordnung zu den Docker-Plattformen

Nach längerer Sichtung und Abwägung habe ich mich zunächst dagegen entschieden, die einzelnen Projekte den drei Plattformen NAS, Raspberry Pi und VPS zuzuordnen. Die Liste ist inzwischen deutlich umfangreicher geworden als ursprünglich gedacht, und viele Anwendungen lassen sich nicht eindeutig einer Plattform zuweisen.

Eine pauschale Zuordnung würde daher wenig Sinn ergeben. Stattdessen möchte ich die interessantesten Projekte nach und nach genauer betrachten, testen und erst anschließend entscheiden, auf welcher Plattform ihr Einsatz am sinnvollsten ist. Dabei spielen insbesondere der Einsatzzweck, die benötigten Ressourcen, die Datenhaltung und die Erreichbarkeit eine Rolle.

Fazit

Aus einer einfachen Frage an Kollegen und Freunde ist inzwischen eine ziemlich lange Liste mit interessanten Docker-Projekten geworden. Mit so vielen Vorschlägen hatte ich gar nicht gerechnet.

Was davon am Ende auf meinem NAS, Raspberry Pi oder VPS landet, wird sich zeigen. Die Liste werde ich auf jeden Fall weiter ergänzen, da ich noch weitere Personen gefragt habe und selbst weiterhin nach interessanten Projekten suche.

Quellen

• makeuseof.com – Docker Containers to Monitor Your Home Lab
• virtualizationhowto.com – 15 Docker Containers That Make Your Home Lab Instantly Better
• bitdoze.com – Docker Containers for Home Server
• xda-developers.com – Every Homelab I Build Now Starts With the Same Docker Containers
• reddit.com – Best Docker Images for Home Lab 2024?
• portalzine.de – My Top Self-Hosted Solutions with Docker for 2026
• stackademic.com – The Ultimate Homelab Setup: Running 50+ Docker Containers on a Raspberry Pi
• virtualizationhowto.com – 6 Home Lab Projects to Try This Weekend – October 2, 2026
• reddit.com – What Are Your Must Docker Containers for Home Lab?

Der Beitrag Homelab – Docker-Container fürs Labor erschien zuerst auf Maximilian Krieg.

Monitoring-Schwellwerte

Dem Monitoring-Team stellen wir folgende Schwellwerte als Empfehlung für sämtliche LetsEncrypt-Zertifikate des Kunden, unabhängig davon welches System sie präsentiert oder verlängert, zur Verfügung:

• Warnung – Ab 28 bis 30 Tagen
• Fehler – Ab 5 bis 7 Tagen

Erst bei Eintreten des Fehlerzustands im Monitoring-System sollte ein Ticket erzeugt werden. 5 bis 7 Tage sollten genug Zeit sein den Prozess manuell zu starten oder in die Fehleranalyse zu gehen, warum der Automated Certificate Management Environment (ACME)-Client das Zertifikat nicht korrekt innerhalb des Standard-Intervalls erneuert hat. Standardmäßig hat ein LetsEncrypt-Zertifikat eine Laufzeit von 90 Tagen und erst ab 60 Tagen ist es eigentlich zum Renewal vorgesehen. Mehr Informationen hierzu findet man in der ACME Renewal Information (ARI).

Die oben genannte Werte sind bereits individuell angepasst auf die Konfiguration der Kunden-spezifischen Umgebung. Ebenfalls denkbar wären folgende, allgemeinen Schellwerte, wenn nur einmal am Tag eine Prüfung der Laufzeiten erfolgt:

• Warnung – Ab 30 Tagen
• Fehler – Ab 28 Tagen

Renewal-Prozess

Die FortiGate-Firewalls sehen im Standard vor, dass ein Zertifikat 30 Tage vor Ablauf den Renewal-Prozess initiieren.

config vpn certificate local
    edit <ACME_certificate_name>
        set acme-renew-window 30
    end

Über folgende Befehle kann man dann ein Zertifikat manuell, auch vor den 30 Tagen, erneuern.

ACME-Status prüfen:

get system acme status
get system acme acc-details

Zertifikate erneuern:

diagnose sys acme regenerate-client-config
diagnose sys acme restart

2-3 Minuten warten, danach neue Laufzeiten je Zertifikat kontrollieren:

get vpn certificate local details <Local certificate name>
diagnose sys acme status-full <Certificate’s CN domain>

Quellen

• Improving Resiliency and Reliability for Let’s Encrypt with ARI – Let’s Encrypt (letsencrypt.org)
• Troubleshooting Tip: Let’s Encrypt certificate did… – Fortinet Community
• draft-ietf-acme-ari-02 – Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension

Der Beitrag Fortinet – LetsEncrypt-Zertifikate manuell erneuern erschien zuerst auf Maximilian Krieg.