Self-hosted Monitoring: von Netdata über Grafana bis Beszel

Menschen kommen auf unterschiedliche Weise zum Self-Hosting. Bei mir, wie bei vielen anderen, begann es mit einer einzigen App, die ich auf meinem eigenen Server installieren wollte. Anfangs war es vor allem technische Neugier, der Wunsch, herauszufinden, wie alles funktioniert, und nebenbei etwas zu lernen. Dann bist du am Haken und fängst an, noch eine App hinzuzufügen, dann eine dritte, eine vierte, und ehe du dich versiehst, hast du einen ganzen Zoo an Servern, von denen einige mehrere Apps gleichzeitig betreiben.

Früher oder später stellt sich also die Frage: Wie behältst du diesen ganzen Zoo aus Servern und Anwendungen im Blick? Anfangs hat es mir Spaß gemacht, mich per SSH von Hand auf jeden Server zu verbinden, Updates manuell auszuführen, mit den üblichen Tools (top, htop, btop) die Vitalwerte zu beobachten, App-Logs zu checken und so weiter.

TL;DR: Nach Netdata und Grafana + Prometheus bin ich bei Beszel gelandet, und ich wünschte, ich hätte es früher gefunden. Weiter unten erkläre ich das Warum im Detail, für wen es gedacht ist und was Beszel nicht kann. Das ist kein Beszel-Review; es geht darum, welche Lösungen ich ausprobiert habe und was ich für das Monitoring meiner kleinen Infrastruktur ausgewählt habe.

Aber ich hatte schnell genug davon, den “coolen Hacker” aus dem Film zu spielen, und die ganze Sache wurde zu einer öden Pflicht, auf die ich nicht immer Lust hatte. Trotzdem: Da viele dieser Server direkt am offenen Internet hängen, ist das Beobachten, regelmäßige Updaten der Apps, Checken der Logs und so weiter keine Option, sondern Pflicht. Also muss jeder Self-Hoster irgendwann das Problem lösen, seine Produktionsserver und die darauf laufenden Apps effizient zu monitoren.

In den letzten zwei Jahren habe ich drei verschiedene Monitoring-Stacks durchlaufen: zuerst Netdata, dann Grafana + Prometheus und schließlich Beszel. Jeder hat mich etwas gelehrt, und ich bin am Ende ganz woanders gelandet, als ich angefangen habe. Wenn ich am Anfang einen Post wie diesen gelesen hätte, hätte mir das eine Menge geholfen.

👉 Wenn du eine Handvoll VPS, ein paar Mini-PCs, ein NAS und vielleicht noch ein paar Docker-Hosts hast, ist das hier für dich.

👉 Wenn du ein Team aus 500 Engineers hast, ist das nichts für dich. Geh zurück zu deinen Datadog-Dashboards.

Was ich wirklich vom Monitoring gebraucht habe

Bevor ich auf die Tools eingehe, lass mich das Problem beschreiben, denn die richtige Antwort hängt komplett davon ab, was du eigentlich vorhast.

Aktuell habe ich sieben Server bei Hetzner (eine Mischung aus CX22 und CPX21), alle laufen Ubuntu, alle mit Terraform provisioniert, mit Ansible verwaltet, und die meisten laufen Docker-Container. Ich brauchte:

1. CPU, Speicher, Disk und Netzwerk pro Host, mit Historie über ein paar Wochen.
2. Ressourcenverbrauch pro Container (alles Interessante lebt in Docker).
3. Alerts, wenn etwas brennt oder kurz davor ist, Feuer zu fangen. Der wichtigste Teil von Monitoring überhaupt.
4. Ein sauberes Übersichts-Dashboard, das ich in fünf Sekunden überfliegen kann, wenn nötig.
5. Minimaler Overhead durch den Collection-Agent, damit er nicht die Ressourcen des Servers auffrisst.
6. Etwas, das ich irgendwann Kunden zeigen kann. Ich baue gerade RunMyApp, einen Managed-Self-Hosting-Service für kleine Unternehmen in der EU, und “wir monitoren deinen Server proaktiv” ist Teil meines Wertversprechens.

Was noch nicht auf der Liste steht: Log-Aggregation, Distributed Tracing, APM und Observability auf SRE-Niveau. Logs sind die eine Sache, die ich noch lösen muss. Falls du also eine interessante Option kennst, sag Bescheid.

Runde 1: Netdata, ein toller Einstieg

Netdata war mein erstes ernsthaftes Monitoring-Tool, und ehrlich gesagt ist es echt cool. Der Agent lässt sich mit einem einzigen Befehl installieren. Das Cloud-Dashboard ist dicht gepackt, schön und nützlich und zeigt alles: CPU, Speicher, Disk-I/O, Netzwerk, jeden laufenden Prozess, jeden Docker-Container, sogar Temperaturen pro Gerät.

Für die ersten drei oder vier Server war Netdata perfekt. Ein-Zeiler-Installation. Dashboards funktionieren einfach. Die Integrationsliste ist riesig. PostgreSQL, Nginx, Redis, Traefik, was du willst, dafür gibt es einen Collector. Alerts per Discord-Webhook einzurichten dauert zehn Minuten. Aber am Ende habe ich es aus zwei Gründen fallen gelassen.

Erstens, der Ressourcenverbrauch des Agents. Der Netdata-Agent sammelt eine enorme Datenmenge in hoher Auflösung, was großartig ist, wenn du es brauchst, und auffällig, wenn nicht. Auf meinen bescheidenen VPS konnte der Agent locker ein paar Prozent CPU und 200 bis 500 MB RAM ziehen, je nachdem, was auf dem Host lief und was du monitoren wolltest. Auf einer 4-GB-Maschine mit ein paar Services ist das eine echte Abgabe.

Zweitens, der Preis. Netdata Cloud ist kostenlos bis 5 Nodes. Danach kostet die Business-Stufe 4,50 USD pro Node und Monat bei jährlicher Abrechnung, das macht 54 USD pro Node und Jahr. Bei einer Flotte aus sieben Nodes sind das rund 378 USD pro Jahr. Für ein Homelab-Budget ist das eine Menge.

Fairerweise gibt es inzwischen eine Homelab-Stufe für 90 USD pro Jahr für unbegrenzt viele Nodes unter einer Fair-Use-Policy. Als ich gewechselt habe, gab es das noch nicht, und es ist ein wirklich faires Angebot, wenn du alles strikt für dich selbst nutzt. Aber zwei Dinge halten mich trotzdem zurück. Erstens verbietet die Homelab-Stufe in ihrer Policy ausdrücklich die kommerzielle Nutzung: “Monitoring der Infrastruktur deines Unternehmens”, “Anbieten von Monitoring-Services an Kunden”, “Nutzung in einem geschäftlichen Kontext”. RunMyApp fällt da buchstäblich rein, also kommt für mich nur die Business-Stufe in Frage. Zweitens lebt das Dashboard in ihrer Cloud, nicht auf meiner Infrastruktur, und ich besitze lieber den gesamten Stack.

Ich mag die Plattform immer noch sehr, und ich finde Netdata ein tolles Produkt. Wenn du weniger als fünf Nodes hast oder in die Homelab-Stufe passt und mit einem Cloud-gehosteten Dashboard zufrieden bist, installiere einfach Netdata. Es wird wirklich alle deine Bedürfnisse abdecken, weil es alles hat. Aber wenn du voll self-hosted und (fast) null Kosten pro Node willst, lies weiter.

Runde 2: Grafana + Prometheus, der anerkannte Klassiker

Die “richtige” Antwort in der Self-Hosting-Community lautet immer Grafana + Prometheus. Das ist der Open-Source-Observability-Stack, der Industriestandard, unendlich flexibel, und jeder Arbeitgeber der Welt will ihn in deinem Lebenslauf sehen. Wie könntest du nicht versuchen, diese Rakete zu durchschauen?

Das initiale Setup war ehrlich gesagt nicht so beängstigend. Prometheus in Docker, node_exporter auf jedem Host, cAdvisor für Container-Metriken, Grafana als Frontend, alles mit ein paar docker-compose-Dateien zusammengeklebt. Mit einem LLM zur Hand hatte ich an einem Abend einen laufenden Stack.

Dann habe ich versucht, ihn tatsächlich zu nutzen.

Da fing der Spaß an. Die Standard-Grafana-Dashboards, die du aus der Community-Galerie importierst, sehen auf Screenshots beeindruckend aus, aber du verlierst dich sofort darin, sobald du sie in der Praxis benutzt. Vor allem, wenn du in dem Bereich null Erfahrung hast (wie ich).

Die Hälfte der Panels zeigte “No data”, weil die Metriknamen im Dashboard nicht zu dem passten, was meine Version von node_exporter exponierte (klassisches Beispiel: node_cpu aus alten Dashboards gegenüber node_cpu_seconds_total aus aktuellen Versionen). Die andere Hälfte zeigte Daten, aber in einem Layout oder Stil, der für mich überhaupt nicht funktionierte.

Also habe ich angefangen, mein eigenes Dashboard zu bauen. Mein Gott, das ist eine eigene Kunstform, mit der du ein Leben verbringen kannst. Um in Grafana ein Panel zu bauen, das etwas Sinnvolles zeigt, musst du PromQL schreiben. PromQL ist eine schöne und mächtige Query-Sprache, und du lernst sie nicht an einem Abend. Ich habe Stunden damit verbracht, herauszufinden, wie ich “durchschnittliche CPU-Auslastung pro Host in den letzten 5 Minuten, ausgenommen idle und iowait” ausdrücke, ohne dass am Ende null oder unendlich rauskommt. Am Ende hatte ich etwas, das entfernt an die Statusseite von Proxmox erinnerte, und etwa drei Tage lang war ich stolz darauf.

Dann habe ich einen neuen Server hinzugefügt.

Einen Server hinzuzufügen bedeutete: neu labeln, Scrape Configs erneut prüfen, Dashboard-Variablen editieren und Template-Queries überarbeiten, damit der neue Host in den Dropdowns auftaucht. Einen Server zu entfernen war noch schlimmer, weil die historischen Daten erhalten blieben und die Dashboards Lücken und Geister anzeigten. Jede Infrastrukturänderung wurde zu Dashboard-Arbeit. Vielleicht weiß ich auch einfach nicht, wie man es richtig macht. Aber eine schnelle Lösung ist es definitiv nicht.

Zu den Ressourcen: Prometheus allein dümpelte mit rund 300 MB RAM auf dem zentralen Monitoring-Host vor sich hin, und node_exporter + cAdvisor fügten auf jedem überwachten Host weitere 50 bis 100 MB hinzu. Mit ein paar Wochen Historie und sieben Nodes näherte sich das zentrale Prometheus 600 bis 800 MB. Keine Katastrophe, aber auch nicht gerade leichtgewichtig. Vielleicht wissen die Profis wieder, wie man weniger Systemressourcen verbraucht. Aber ich bin kein Profi. Und ehrlich gesagt hatte ich auch keine Lust, meinem digitalen Kumpel (der KI) damit auf den Wecker zu gehen.

Ich habe nach etwa drei Wochen aufgegeben. Nicht weil der Stack nicht funktioniert hat, sondern weil für mich die Kosten des Betriebs in keinem Verhältnis zum Wert standen, den ich rausbekommen habe. Ich verbrachte mehr Zeit damit, Grafana zu tunen, als tatsächlich meine Infrastruktur zu beobachten.

Fazit: Grafana + Prometheus ist die richtige Antwort, wenn (a) du eine stabile Flotte hast, die sich selten ändert, (b) du wirklich Custom-Dashboards und Queries brauchst, (c) du den Stack aus beruflichen Gründen lernen willst oder (d) du zusätzlich Log-Aggregation (Loki) brauchst und alles an einem Ort haben willst. Für ein kleines, ständig wechselndes Homelab, in dem du einfach nur wissen willst “lebt der Server noch”, ist das brutal überdimensioniert.

Runde 3: Beszel, der “wo warst du mein ganzes Leben”

Ich bin in irgendeinem Thread in einem Self-Hosting-Forum auf eine Erwähnung von Beszel gestoßen, und anfangs hat mir nicht einmal der Name Vertrauen eingeflößt. Aber dann habe ich es eines schönen Sonntagmorgens installiert, und bis zum Mittagessen hatte ich alle sieben Server auf die Plattform migriert, und ich lebe seitdem damit. Diesen Absatz zu schreiben hat länger gedauert als Beszel zu installieren.

Beszel ist ein leichtgewichtiges self-hosted Server-Monitoring-Tool, das auf PocketBase basiert. Open Source unter MIT-Lizenz, eine einzige Go-Binary plus ein winziger Agent, und es macht genau das, was 80% der Nutzer beim Monitoring wirklich brauchen: Host-Metriken, Docker-Container-Stats, historische Graphen und konfigurierbare Alerts. Kein PromQL, keine YAML-Scrape-Configs, kein Herumstochern in Dashboard-JSON. Das Dashboard ist out of the box fertig und funktioniert einfach. Es gibt helles und dunkles Theme. Und die Alerts habe ich schon erwähnt, oder?

Die Zahlen sprechen für sich. Der Hub selbst braucht etwa 30 MB RAM. Der Agent etwa 10 MB pro Host. Vergleiche das mit 300 MB für Prometheus oder mehreren hundert MB pro Agent bei Netdata. Auf einem kleinen VPS ist das der Unterschied zwischen “Monitoring ist unsichtbar” und “Monitoring ist ein zweiter Mieter”.

Eine wichtige architektonische Anmerkung: Der Hub verbindet sich mit den Agents (es ist ein Pull-Modell über SSH), nicht umgekehrt. Das bedeutet, auf einem Host mit Agent muss Port 45876 für den Hub erreichbar sein, und du konfigurierst deine Firewall entsprechend. Im Gegenzug lebt der Public Key des Hubs auf den Agents, und es werden keine Tokens oder Passwörter im Klartext durch die Gegend geschickt.

Das bekomme ich raus:

• Ein großartiges Dashboard, das alle Server gleichzeitig anzeigt, mit CPU-, Speicher-, Disk- und Netzwerkinformationen.
• Klick auf einen beliebigen Server, und du siehst detaillierte Zeitreihen für Ressourcen plus eine Liste der Docker-Container mit ihrem Ressourcenverbrauch.
• Konfigurierbare Alerts global oder pro Server für CPU, Speicher, Disk, Traffic, Temperatur und Host-Status, gesendet an alles, was Shoutrrr unterstützt: Discord, Telegram, E-Mail, ntfy, Slack, das übliche Aufgebot.
• Multi-User-Support, sodass du Kunden Read-Only-Zugriff geben kannst.

Was ich am meisten liebe: Wenn ich einen neuen Server hinzufüge, führe ich einen einzigen Befehl darauf aus, füge den Key in der Hub-UI ein, und der neue Host taucht im Dashboard auf. Kein Re-Templating, kein Re-Labeling, kein PromQL. Wenn ich einen Server entferne, lösche ich ihn aus dem Hub, und weg ist er. Das Dashboard passt sich an, weil das Dashboard für alle dasselbe ist.

Was Beszel nicht macht

Da will ich ehrlich sein, denn das ist der Hauptgrund, warum Beszel nicht für jeden geeignet sein wird.

Beszel kümmert sich nicht um Logs. Es überwacht Ressourcen. Wenn du zentralisierte Log-Aggregation, -Suche und -Analyse brauchst (Loki, ELK-Stack, SigNoz, OpenObserve), ist Beszel nicht dein Tool. Entweder lässt du etwas daneben laufen, oder du gibst die Einfachheit auf und gehst zurück zum Grafana-Stack mit Loki obendrauf.

In meinem Fall ist das okay. Ich muss selten Logs über Hosts hinweg abfragen. Wenn doch, gehe ich per SSH rein und mache es von Hand (gut, mit sorgfältig aufgebauten Scripts). Aber wenn du eine Produktiv-App betreibst und Fehler über Services hinweg korrelieren musst, reicht Beszel allein nicht.

Was Beszel sonst noch nicht macht: APM, Distributed Tracing, Custom-Metriken aus deinen Apps, synthetische Checks externer Endpunkte, SLO-Tracking. Es ist schlicht ein einfacher Host- und Container-Ressourcenmonitor. Genau dieser Fokus ist es, der es so gut darin macht, was es macht.

Schneller Vergleich

Die Kurzfassung: So sehen alle drei Stacks nebeneinander für mein Szenario aus (7 Nodes bei Hetzner):

Die RAM-Zahlen sind ungefähre Werte und hängen von deiner Konfiguration und Retention ab. Aber die Größenordnung erzählt die Geschichte.

Eine praktische Anleitung zur Installation von Beszel

Da wir es bis hierher geschafft haben, hier wie ich Beszel heute installieren würde. Vorausgesetzt, du hast Docker und docker-compose auf der Maschine, die den Hub laufen lassen wird, und SSH-Zugang zu den Maschinen, die du überwachen willst.

Schritt 1: Hub starten

Auf der Maschine, die dein Monitoring-Hub werden soll, lege ein Verzeichnis für Beszel an und schreibe das in eine docker-compose.yml-Datei:

services:
  beszel:
    image: henrygd/beszel:latest
    container_name: beszel
    restart: unless-stopped
    ports:
      - "8090:8090"
    volumes:
      - ./beszel_data:/beszel_data

Starte ihn:

docker compose up -d

Öffne http://dein-host:8090 im Browser. Du wirst aufgefordert, den ersten Admin anzulegen.

Wenn du HTTPS willst (und das willst du, vor allem wenn du das Ganze ins Internet stellst), pack Caddy oder Traefik davor. Caddy ist am einfachsten. Zwei Zeilen in einer Caddyfile reichen:

beszel.deinedomain.com {
    reverse_proxy beszel:8090
}

Damit Caddy in einem Container Beszel unter dem Namen beszel erreicht, müssen beide im selben Docker-Netzwerk sein. Entweder startest du sie in einer docker-compose-Datei zusammen, oder du gibst beiden ein externes Netzwerk und verbindest sie. Wenn Caddy auf dem Host und nicht in einem Container läuft, ersetze beszel:8090 durch localhost:8090. Caddy holt sich das Let’s-Encrypt-Zertifikat selbst. Hub steht.

Schritt 2: Ein System hinzufügen

Klicke in der Hub-UI auf “Add System”. Gib ihm einen Namen (ich verwende mnemonische Hostnames, aber es kann jeder beliebige Text sein, der für dich Sinn ergibt) und die IP oder den Hostname, unter dem der Hub den Agent erreichen kann. Beszel zeigt einen Dialog mit zwei Tabs: Docker und Binary. In beiden sind der Public Key des Hubs und das System-Token bereits ausgefüllt; alles, was du tun musst, ist den fertigen Befehl zu kopieren.

Schritt 3: Agent starten

Und hier wird es richtig schön: Beszel hat die Agent-Installation so einfach gemacht, dass sie eine Bildschirmaufnahme verdient. Ich plane übrigens, eine zu machen, also abonniere ruhig meinen YouTube-Kanal, damit du sie nicht verpasst.

Option 1 (empfohlen): ein einziges Bash-Script. Klicke im Binary-Tab auf “Copy Linux command” (oder Homebrew/Windows/FreeBSD, je nachdem) und füge es auf dem Host ein, den du überwachen willst:

curl -sL https://get.beszel.dev -o /tmp/install-agent.sh && \
chmod +x /tmp/install-agent.sh && \
/tmp/install-agent.sh \
  -p 45876 \
  -k "ssh-ed25519 AAAAC3Nz... (der Public Key deines Hubs)" \
  -t "dein-system-token" \
  -url "https://dein-hub.beispiel.com"

Das Script installiert die Binary, legt einen systemd-Service an, setzt Token und Public Key und startet den Agent. Ein paar Sekunden später taucht das System im Hub als “up” auf, mit Live-Metriken. Keine docker-compose-Dateien, keine manuellen Env-Variablen.

Option 2: Docker. Wenn du in Containern lebst und keinen systemd-Service auf dem Host willst, hat der Docker-Tab fertige Buttons “Copy docker compose” und “Copy docker run”. Der Inhalt sieht ungefähr so aus:

services:
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      LISTEN: 45876
      KEY: "ssh-ed25519 AAAA..."
      TOKEN: "dein-system-token"
      HUB_URL: "https://dein-hub.beispiel.com"

Starte ihn wie gewohnt mit docker compose up -d.

Massen-Rollout mit Ansible. Beszel unterstützt ein Universal-Token: ein einziges Token, das viele Agents auf einmal registrieren kann, wobei der Hub automatisch System-Einträge für sie anlegt. Damit fällt der manuelle “Add System”-Schritt in der UI für jeden Host weg, und es passt perfekt zu Ansible. Ich halte das Token im Ansible Vault, lasse in einem Playbook eine simple Shell-Task mit dem curl-Befehl über eine Servergruppe laufen, und die gesamte Flotte registriert sich selbst.

Schritt 4: Alerts konfigurieren

Öffne im Hub die Einstellungen für jedes System und setze die Schwellwerte. CPU über 80% für 5 Minuten, Disk über 90%, Speicherdruck, Host down, was auch immer dir wichtig ist. Lege Notification-Channels in den Benutzereinstellungen an, richte sie auf einen Discord-Webhook oder einen Telegram-Bot, und die Alerts sind scharf.

Schritt 5: Backup einrichten

Beszel speichert alles in ./beszel_data (das Volume, das du gemountet hast). Darunter steckt das SQLite von PocketBase, also gibt es einen Haken: Ein tar der laufenden Datenbank unter Last kann dir einen korrupten Snapshot bescheren. Zwei Optionen:

• Einfach: Stoppe den Container für eine Minute, tar ihn, fahr ihn wieder hoch. Reicht für den Homelab-Einsatz.
• Sauber: Nutze sqlite3 .backup für einen atomaren Snapshot, ohne den Service zu stoppen.

Danach ist es Standardkram: Ein nächtlicher Cron-Job lädt das Archiv nach S3, B2 oder wo auch immer du deine Backups hältst. In meinem Setup geht es zusammen mit dem Rest meiner PocketBase-Daten.

Das ist die ganze Installation. Im Ernst. Von Null bis zum Monitoring einer Flotte aus sieben Servern in unter einer Stunde, wenn du dir Zeit lässt.

Weitere Optionen, die du kennen solltest

Viele davon habe ich selbst nicht ausprobiert, aber sie kommen in jeder Monitoring-Diskussion vor, und ich habe diese Liste hier der Übersicht halber zusammengestellt.

Uptime Kuma ist ein hübsches, einfaches Tool im Stil einer Statuspage für Uptime-Checks per HTTP/TCP/Ping. Es ergänzt Beszel eher, als dass es mit ihm konkurriert. Beszel sagt dir, dass der Server am Leben und gesund ist; Uptime Kuma sagt dir, dass deine Services auf öffentliche Requests antworten. Lass beide laufen, wenn du magst.

SigNoz ist eine moderne Observability-Plattform, die auf OpenTelemetry aufbaut und OTLP unterstützt. Metriken, Logs und Traces in einem self-hosted Stack, mit einem moderneren Look als Grafana + Loki + Tempo. Wenn du Logs und Traces brauchst und ein einziges Tool willst, würde ich mir das zuerst anschauen.

Zabbix ist Enterprise-Grade Open Source, das es seit gefühlt immer gibt. Sehr mächtig, sehr schwer, mit einer UI, die wirkt, als wäre sie 2010 entworfen worden. Sollte man kennen, für ein Homelab vermutlich Overkill.

Checkmk Raw ist die kostenlose Variante eines kommerziellen Produkts mit Nagios-Genen. Eine solide Option für Sysadmin-mäßiges Monitoring in gemischten Umgebungen, aber die UX fühlt sich angestaubt an.

Glances ist ein großartiges Tool für einen einzelnen Host, in CLI und Web. Es kann nach InfluxDB und Prometheus exportieren, ist also nicht strikt auf einen Host beschränkt, verliert aber bei der UX für eine Flotte gegen Beszel. Wenn du genau eine Maschine überwachen musst und Terminals liebst, ist Glances wunderbar.

OpenObserve ist eine neue, leichtgewichtige Alternative zu Elasticsearch/Loki für Logs und Metriken. Habe ich noch nicht ernsthaft ausprobiert, aber sie steht auf meiner “wenn ich jemals Logs brauche”-Liste.

Cockpit ist ein webbasiertes Server-Admin-Tool von Red Hat mit leichtgewichtigem Monitoring an Bord. Gut für die Verwaltung eines einzelnen Hosts, aber kein echtes Multi-Server-Dashboard.

Der Sinn dieser Liste ist nicht Vollständigkeit, sondern dir eine Startauswahl an Alternativen zu geben. Wenn Beszel bei dir nicht zündet, klappt es vermutlich mit einer davon. Detaillierte Reviews zu jeder findest du leicht online.

Wie du deine Lösung auswählst

Wenn du die Marken weglässt, läuft die Wahl meist auf vier Fragen hinaus:

1. Wie viele Hosts?
   • Weniger als 5: Netdata kostenlos oder Beszel.
   • 5 bis 50: Beszel, oder Netdata Homelab, wenn deine Projekte nicht kommerziell sind.
   • 50+: Du bist vermutlich schon im Prometheus- oder SigNoz-Territorium.
2. Brauchst du Logs? Wenn ja, schau dir Grafana + Loki, SigNoz oder OpenObserve an. Beszel hilft dir da nicht. Wenn nein, ist Beszel schwer zu schlagen.
3. Wie viel Zeit hast du für Setup und Wartung? Beszel: Minuten. Netdata: Minuten. Der Grafana-Stack: Wochenenden, im Plural.
4. Ist es für dich oder für Kunden? Self-hosted gibt dir die Vertrauensstory. Cloud-hosted lässt dir weniger zu warten.

Für meine heutigen Anforderungen ist Beszel die richtige Antwort. Für deine vielleicht nicht, und das ist okay. Die eigentliche Erkenntnis ist: Greif nicht standardmäßig zum schwersten Tool, nur weil am meisten darüber geredet wird. Wähl das Tool passend zu deinem Problem.

FAQ

Ist Beszel produktionsreif? Für Ressourcen-Monitoring von Hosts und Containern ja. Für vollständige Observability mit Logs, Traces und APM nein. Du musst verstehen, was du wählst.

Unterstützt Beszel Windows? Der Agent wird für Linux, macOS und FreeBSD gebaut. Windows läuft nicht nativ; du brauchst WSL2 oder einen Container. Für ein typisches Linux-basiertes Homelab ist das kein Problem.

Kann ich Kubernetes überwachen? Beszel überwacht Hosts und Docker-Container, keine Pods als Kubernetes-Objekte. Wenn du k8s einsetzt, brauchst du kube-state-metrics plus Prometheus oder etwas Ähnliches. Beszel ist dafür nicht gemacht.

Worin unterscheidet sich Beszel von Uptime Kuma? Beszel überwacht die Servergesundheit von innen (CPU, RAM, Disk, Container). Uptime Kuma überwacht Services von außen (antwortet der HTTP-Endpunkt, ist der Port offen). Sie lösen unterschiedliche Probleme und leben friedlich nebeneinander.

Und Updates? Geht da was kaputt? Beszel ist ein junges Projekt und wird aktiv weiterentwickelt. Releases kommen regelmäßig. Ich aktualisiere alle paar Wochen mit docker compose pull && docker compose up -d, bisher ist nichts kaputtgegangen. Aber das ist keine Ausrede dafür, vor einem Update kein Backup der Datenbank zu machen.

Schlussgedanken

Ich habe Netdata durch, habe mit Grafana + Prometheus gekämpft und bin bei Beszel gelandet. Die Lehre ist nicht, dass irgendeines dieser Tools schlecht wäre. Die Lehre ist, dass “Monitoring” eine breite Palette an täglichen Aufgaben abdeckt, und jede populäre Antwort zielt vermutlich auf Probleme, die die meisten von uns gar nicht haben.

Wenn du eine kleine Server-Flotte hast und wissen willst, was los ist, ohne Wochenenden in PromQL zu verbrennen oder jeden Monat für jeden Node zu zahlen, installier Beszel heute Nachmittag. Im schlimmsten Fall verschwendest du zwanzig Minuten. Im besten Fall hast du am Ende ein Monitoring, das du jahrelang tatsächlich nutzt.

Und wenn du es am Ende einsetzt: Das Beszel-Projekt ist Open-Source-Arbeit einer einzelnen Person, die zu etwas Brillantem gewachsen ist. Gib dem Repo einen Stern, schreib gute Bug Reports, und wenn du kannst, unterstütze den Maintainer. Das self-hosted Ökosystem lebt von Menschen wie ihm.

Und wenn du dich überhaupt nicht mit Deployment, Updates und Monitoring herumschlagen willst, ist genau das der Fall, für den ich RunMyApp baue: deine Apps auf deinem Server, und wir behalten ihn im Blick. Wenn du Interesse hast, meld dich.

Ich hoffe, dieser Post hat dir geholfen, dich zurechtzufinden. Wenn du über neue Beiträge informiert werden willst, abonniere die Benachrichtigungen. Ich spamme nicht, weil ich Spam selbst nicht mag.

Viel Erfolg.