Monitoring. Nerviges Thema, ich weiß. Wobei es sich gerade dann lohnt, wenn die Dinge mal nicht so laufen, wie sie sollen. Das selbe gilt an sich auch für zentrales Logging, das Thema schiebe ich zuhause aktuell noch vor mir her.
Beruflich arbeite ich viel mit dem Prometheus-Stack: Prometheus, Alertmanager, Grafana, Node-Exporter und VictoriaMetrics. Für den professionellen Betrieb ist das mächtig genug, aber für mein Homelab zu schwergewichtig. Der Aufwand für Wartung, Speicher, Alerting und Dashboards ist im Alltag einfach zu hoch. Ich wollte etwas, das schneller produktiv ist und weniger Ballast mitbringt.
Privat habe ich länger mit Zabbix gearbeitet, ganz ursprünglich sogar mit Icinga 2. Das Tool ist sehr stark, aber für zuhause ebenfalls zu dick. Die Konfiguration und die nötige Pflege waren für ein privates Setup zu viel. Ein Kollege hat mich dann irgendwann auf Beszel aufmerksam gemacht.
Warum überhaupt Monitoring und warum Beszel?
Eigentlich, um Probleme zu erkennen, bevor sie ernsthaft werden. Dauerhaft hohe CPU-Last, zu hohe RAM-Auslastung, volllaufende Datenträger oder auch ausfallende SSDs/HDDs sind so das gängigste. Natürlich auch die Erreichbarkeit der Server an sich.
Beszel ist auf Homelabs und generell kleine Umgebungen konzipiert und deckt von Haus aus direkt quasi alles Wichtige ab. Die Einstiegshürde ist gering, die Oberfläche ist aufgeräumt und man kommt schnell zu brauchbaren Ergebnissen.
Besonders angenehm ist, dass Beszel nicht versucht, einen mit Funktionen zu erschlagen. Es geht nicht um tausend Alarme, komplizierte Regelwerke oder eine massive Lernkurve. Stattdessen bekommt man eine klare Sicht auf Hosts und Dienste, ohne erst ein ganzes Observability-Ökosystem bauen zu müssen. Die relevanten Daten (Ressourcenauslastung, SMART-Daten, Systemd-Services, Docker, …) werden alle bereitgestellt.
Wer eine komplexe Multi-Tenant-Umgebung, tiefes Alerting, Spezialmetriken oder hochgradig anpassbare Dashboards braucht, wird wahrscheinlich woanders besser aufgehoben sein. Aber genau das ist auch nicht Beszels Ziel. Es will nicht die riesige Plattform ersetzen, sondern eine saubere, einfache Lösung für den Alltag bieten. Beszel ist auch längst nicht so weit konfigurierbar wie andere Systeme, aber das macht es für mich gerade so interessant.
Zusätzlich: Uptime-Kuma und Smokeping
Für die reine Erreichbarkeitsprüfung von Services nutze ich zusätzlich Uptime-Kuma. Damit prüfe ich, ob Endpunkte, APIs, Web-Dienste oder interne Tools erreichbar sind.
Latenzüberwachung zu verschiedenen Zielen im Internet mache ich mit [Smokeping]https://secretmine.de/blog/2026/2026-04-18-latenzmessungen-mit-smokeping/, darüber hatte ich vor einigen Monaten schon ausführlich berichtet.
Beszel und Uptime-Kuma ergänzen sich dabei gut. Beszel liefert die tieferen Systemdaten und Ressourcen-Metriken, während Uptime-Kuma sich auf die Erreichbarkeit konzentriert. Klar, das ließe sich mit dem Prometheus-Stack und dem Blackbox-Exporter alles umsetzen, aber ich finde Beszel und Uptime-Kuma einfach angenehmer.
Fazit
Auch wenn ich gerne die großen Enterprise-Lösungen einsetze, ist irgendwo dann doch eine Grenze erreicht. Und beim Monitoring war das der Fall, da standen Aufwand und Nutzen nicht mehr in einem passenden Verhältnis. Ich habe Beszel jetzt seit einem halben Jahr im Einsatz und bin happy damit: Es liefert alles Wichtige an Alerts und bleibt übersichtlich. Der Agent ist auch angenehm simpel zu installieren - das Ganze habe ich natürlich in eine Ansible-Rolle gegossen.