Server Monitoring: Uptime Kuma, Netdata und Prometheus im Praxistest (2026)

Server Monitoring heißt: Ein Programm prüft laufend, ob dein Server und die Dienste darauf funktionieren, und meldet sich, wenn etwas nicht stimmt. Für die meisten kleinen Setups reichen zwei Bausteine. Ein Uptime-Monitor wie Uptime Kuma prüft von außen, ob deine Website antwortet. Ein Metrik-Monitor wie Netdata oder Prometheus schaut von innen auf CPU, RAM, Festplatte und Dienste. Wichtig ist nicht das Dashboard, sondern der Alarm: Er muss bei einem Menschen ankommen, der ihn liest.

Das klingt einfach, und die Installation ist es auch. Jedes der drei großen Open-Source-Werkzeuge läuft bei uns in unter drei Sekunden. Schwierig wird es an einer anderen Stelle: Monitoring kann grün zeigen, während deine Seite kaputt ist. In unserem Test meldete ein HTTP-Monitor 70 Sekunden lang „OK“, während die Website nur noch „Fehler: Datenbankverbindung fehlgeschlagen“ auslieferte. Und Prometheus hat einen Alarm korrekt ausgelöst, ihn dann aber an niemanden geschickt, ohne irgendeine Warnung.

Wir haben am 6. November 2026 Uptime Kuma 2.5.9, Netdata 2.12.3, Prometheus 3.16.0 mit Node Exporter und Grafana 13.2.5 als Wegwerf-Container auf unserem eigenen Server gestartet, gegen eine kleine Testseite laufen lassen und diese Seite absichtlich kaputt gemacht. Dieser Artikel zeigt dir, was du überwachen solltest, welches Tool zu dir passt, wie du es einrichtest und wo die stillen Lücken liegen. Wenn dein Server noch ganz neu ist, fang mit unserer Anleitung Linux Server einrichten an und komm dann hierher zurück.

Video (Deutsch): ARNA Techs zeigt Schritt für Schritt die Installation von Uptime Kuma und die ersten Monitore (Juni 2026). Unsere Messungen weiter unten sind unabhängig davon entstanden.

Was ist Server Monitoring und warum brauchst du es?

Ohne Monitoring erfährst du von einem Ausfall durch deine Nutzer. Oder gar nicht. Eine Website, die nachts um drei ausfällt, ist bis zum Frühstück vielleicht fünf Stunden weg, und du merkst es erst, wenn eine Kundin schreibt. Ein Server, dessen Festplatte langsam vollläuft, läuft wochenlang gut und bleibt dann an einem beliebigen Dienstag stehen, weil die Datenbank keine Zeile mehr schreiben kann. Beides passiert nicht plötzlich. Es kündigt sich an, wenn jemand hinschaut.

Server Monitoring ist dieses Hinschauen, nur automatisch. Es beantwortet drei Fragen:

1. Ist es erreichbar? Antwortet die Website, der Mailserver, die API? Das ist die Sicht deiner Nutzer.
2. Ist es gesund? Wie voll sind Festplatte und Arbeitsspeicher, wie hoch ist die Last, laufen alle Dienste? Das ist die Sicht von innen.
3. Wird es bald ein Problem? Wächst die Platte jede Woche um zwei Prozent? Läuft das TLS-Zertifikat in zehn Tagen ab? Das ist der Blick nach vorn.

Dazu kommt der vierte Teil, der am häufigsten vergessen wird: Wer erfährt davon? Ein Dashboard, das niemand öffnet, ist eine Tapete. Ein Alarm, der in einer Logdatei landet, ist ein Kommentar. Monitoring ist erst fertig, wenn ein Problem dich auf einem Weg erreicht, den du tatsächlich bemerkst: als Push auf dem Handy, als Nachricht im Messenger, als Mail in einem Postfach, das du liest.

Was solltest du auf einem Server überwachen?

Die Liste ist kürzer, als die meisten Dashboards vermuten lassen. Netdata hat bei uns ohne jede Konfiguration 3.302 Diagramme angelegt. Du brauchst davon vielleicht zehn. Diese Werte sind für einen typischen Webserver die wichtigsten:

Zwei Punkte aus dieser Tabelle sind wichtiger, als sie aussehen.

Arbeitsspeicher misst fast jeder falsch. Der Wert „free“ ist auf einem gesunden Linux-Server fast immer klein, weil der Kernel freien Speicher als Cache nutzt. Ein Alarm darauf schlägt ständig an, ohne dass etwas kaputt ist. Wir haben das ausführlich in Wie viel RAM braucht ein Server? nachgemessen. Der verlässliche Wert ist /proc/pressure/memory. Er zeigt, wie viel Zeit Prozesse wirklich auf Speicher warten. Und genau dieses Missverständnis haben wir im Test live gesehen: Netdata meldete auf unserem Server sofort nach dem Start „Swap 99,9 % belegt“ als CRITICAL, obwohl der Server zum selben Zeitpunkt 16 GB verfügbaren Speicher hatte. Ein voller Swap ist kein Problem. Hoher Speicherdruck ist eins.

Ein stummer Cronjob ist das tückischste Problem. Dein Backup-Skript läuft jede Nacht um drei Uhr. Wenn es abbricht, merkst du das an einer Fehlermail. Wenn der Cronjob aber gar nicht mehr startet, weil jemand die Crontab überschrieben hat, kommt keine Fehlermail. Es kommt gar nichts, und „nichts“ sieht genau so aus wie „alles in Ordnung“. Dagegen hilft nur ein umgekehrter Check: Das Skript meldet sich nach jedem erfolgreichen Lauf bei deinem Monitoring, und das Monitoring schlägt Alarm, wenn diese Meldung ausbleibt. Uptime Kuma nennt das „Push“-Monitor, andere Dienste „Heartbeat“ oder „Dead Man’s Switch“. Wie du den Cronjob selbst sauber aufsetzt, steht in Cronjob erstellen.

Die Werkzeuge: Uptime Kuma, Netdata und Prometheus mit Grafana

Es gibt Dutzende Monitoring-Tools. Für Einsteiger und kleine bis mittlere Setups haben sich drei Open-Source-Projekte durchgesetzt, die sehr unterschiedliche Fragen beantworten.

Uptime Kuma ist ein Uptime-Monitor mit schöner Weboberfläche. Du legst Monitore an (HTTP, Keyword, Ping, TCP-Port, DNS, Docker-Container, Push und einige mehr), und Kuma prüft sie in einem festen Takt. Fällt etwas aus, benachrichtigt es dich über einen von über 90 Kanälen, darunter Mail, Telegram, Discord, Signal, Slack und ntfy. Uptime Kuma schaut nicht in deinen Server hinein. Es sieht nur, was ein Besucher sieht.

Netdata ist das Gegenteil: ein Agent, der auf dem Server läuft und alles misst, was er findet. CPU pro Kern, jede Festplatte, jede Netzwerkschnittstelle, jeder Docker-Container, Datenbanken, Webserver. Er bringt eine große Zahl vorkonfigurierter Alarme mit und ein Dashboard, das sofort funktioniert. Seit einigen Versionen ist das lokale Dashboard teilweise an Netdata Cloud gekoppelt. Der Agent selbst bleibt aber frei nutzbar.

Prometheus mit Grafana ist der Baukasten. Prometheus sammelt Metriken von sogenannten Exportern ein (für den Server selbst ist das der Node Exporter), speichert sie als Zeitreihen und wertet Alarmregeln aus. Grafana zeichnet daraus Dashboards. Der Alertmanager verschickt die Alarme. Das ist mächtiger und flexibler als alles andere hier, aber du baust es aus vier Einzelteilen zusammen, und jedes davon will konfiguriert werden.

Daneben gibt es Leichtgewichte wie Beszel (sehr kleiner Agent, simples Dashboard), klassische Systeme wie Zabbix und Checkmk und gehostete Dienste wie UptimeRobot oder Better Stack. Die haben wir in diesem Test nicht gemessen.

Video (Englisch): Tech with Gerard richtet Uptime Kuma für einen ganzen Stapel selbst gehosteter Dienste ein und zeigt Statusseiten und Benachrichtigungen (Juni 2026).

Unser Testaufbau

Alle Werkzeuge liefen als Docker-Container auf unserem Entwicklungsserver (12 vCPU AMD EPYC, 22 GB RAM, Ubuntu 24.04). Die Ports haben wir nur an 127.0.0.1 gebunden, damit von außen niemand drankommt. Als Prüfobjekt diente ein winziger Node.js-Webserver, den wir per Befehl in vier Zustände schalten konnten:

• ok: HTTP 200 mit „Shop OK“
• dberr: HTTP 200, aber die Seite zeigt nur „Fehler: Datenbankverbindung fehlgeschlagen“, wie ein Shop, dessen Datenbank weg ist
• down: Verbindung wird sofort abgebrochen, wie ein abgestürzter Dienst
• slow: Antwort erst nach 40 Sekunden, wie ein überlasteter Server

In Uptime Kuma haben wir zwei Monitore auf dieselbe Seite gesetzt: einen normalen HTTP-Monitor und einen Keyword-Monitor, der zusätzlich nach „Shop OK“ sucht. Prüfintervall 20 Sekunden, Timeout 16 Sekunden, keine Wiederholungen. In Prometheus lief eine Alarmregel „Seite nicht erreichbar seit 1 Minute“ bei 15 Sekunden Abfrageintervall. Am Ende haben wir alle Container, das Netzwerk, die Images und das Datenvolume gezielt wieder gelöscht.

Ressourcen im Vergleich: was die Tools kosten

Ein paar Dinge fallen auf.

Netdata ist der Einzige, der dauerhaft CPU zieht. 12 bis 13 Prozent eines Kerns, gemessen über fünf Proben. Das liegt daran, dass Netdata standardmäßig jede Sekunde misst und dabei 38 Collectors durchläuft. Auf unserem 12-Kerner ist das ein Prozent der Gesamtleistung. Auf einem kleinen VPS mit einem Kern sind es 12 Prozent, nur für die Überwachung. Das lässt sich über das Messintervall reduzieren, aber du solltest es wissen.

Prometheus plus Node Exporter sind zusammen unter 45 MiB. Der Speicherhunger des klassischen Stacks steckt in Grafana, nicht in Prometheus. Wer nur Alarme will und Dashboards selten braucht, kann Grafana weglassen oder auf einem anderen Rechner betreiben.

Uptime Kuma ist im Betrieb sparsam, aber das Image ist riesig. 2,53 GB, weil es einen eingebetteten Browser für die Prüfung von JavaScript-Seiten und eine eingebaute MariaDB mitbringt. Es gibt eine „slim“-Variante ohne diese Extras. Auf einem Server mit wenig Platte macht das einen Unterschied.

Die Falle: grün, obwohl die Website kaputt ist

Das ist der wichtigste Abschnitt dieses Artikels. Wir haben die Testseite nacheinander in die vier Zustände geschaltet und mitgeschrieben, was Uptime Kuma meldet.

Der HTTP-Monitor hat die kaputte Datenbank nicht bemerkt. Aus seiner Sicht war alles bestens: Der Server hat geantwortet, der Statuscode war 200, die Antwort kam in drei Millisekunden. Dass auf der Seite nur noch eine Fehlermeldung stand, prüft ein reiner HTTP-Monitor nicht.

Das ist kein konstruierter Fall. Viele PHP-Anwendungen, CMS und Shops liefern bei einem Datenbankfehler eine Fehlerseite mit Status 200 aus. Gleiches gilt für eine Wartungsseite, für eine leere weiße Seite nach einem fehlgeschlagenen Deployment oder für die Standardseite eines Webservers, nachdem jemand die Konfiguration überschrieben hat. All das ist für deine Nutzer ein Ausfall und für einen HTTP-Monitor ein Erfolg.

Die Lösung ist einfach: Prüfe nicht nur, ob die Seite antwortet, sondern ob das Richtige drinsteht. In Uptime Kuma heißt das „HTTP(s) - Keyword“. Wähle ein Wort, das nur auf der funktionierenden Seite vorkommt und von der Datenbank abhängt, zum Beispiel einen Produktnamen oder den Text im Footer, der aus dem CMS kommt. Noch besser ist eine eigene Health-Seite, die intern Datenbank, Cache und Speicher prüft und nur dann „OK“ zurückgibt, wenn alles stimmt. Uptime Kuma kennt dafür auch den Typ „HTTP(s) - Json Query“, der einen Wert in einer JSON-Antwort prüft.

Ein zweites Detail aus der Tabelle: Beim langsamen Zustand verlängerte sich der Prüftakt von 20 auf 36 Sekunden, weil Kuma erst den Timeout von 16 Sekunden abwartet und dann das Intervall startet. Bei einem Intervall von 60 Sekunden und einem großzügigen Timeout von 48 Sekunden prüft Kuma eine hängende Seite also nur noch knapp alle zwei Minuten. Setz den Timeout deshalb deutlich unter das Intervall, für normale Websites reichen 10 bis 15 Sekunden.

Und der dritte Punkt: Wir haben bewusst keine Wiederholungen eingestellt, damit wir jede einzelne Prüfung sehen. Im echten Betrieb solltest du ein bis zwei Wiederholungen („Retries“) setzen. Sonst weckt dich jeder einzelne Netzwerk-Schluckauf. Mit Intervall 60 Sekunden und zwei Wiederholungen erfährst du von einem echten Ausfall nach etwa zwei bis drei Minuten. Das ist für die meisten Websites ein guter Kompromiss.

Die zweite Falle: ein Alarm, der niemanden erreicht

Mit Prometheus haben wir die Testseite gestoppt und jede Sekunde den Zustand der Alarmregel abgefragt:

• +23 Sekunden: Alarm „pending“. Prometheus hat bemerkt, dass die Seite nicht antwortet, wartet aber die eingestellte Minute ab.
• +83 Sekunden: Alarm „firing“. Die Bedingung ist seit einer Minute erfüllt, der Alarm ist aktiv.

Bis hierhin funktioniert alles. Dann haben wir nachgesehen, wohin Prometheus den Alarm geschickt hat: activeAlertmanagers: []. Nirgendwohin. Prometheus selbst verschickt keine Benachrichtigungen. Das macht ein separates Programm, der Alertmanager. Ist keiner konfiguriert, wertet Prometheus brav jede Regel aus, zeigt den Alarm in seiner eigenen Weboberfläche als rot an und verschickt nichts. Es gibt dazu keine Warnung im Log und keinen Hinweis beim Start.

Genau so entstehen Setups, die monatelang „laufen“: Jemand installiert Prometheus und Grafana, baut schöne Dashboards, schreibt Alarmregeln, sieht in der Oberfläche, dass sie feuern, und hält das Thema für erledigt. Bis zum ersten echten Ausfall.

Bei Netdata ist es umgekehrt, aber nicht unbedingt besser. Netdata bringt 1.179 vorkonfigurierte Alarmregeln mit und schickt sie standardmäßig per Mail an den lokalen Benutzer root, über das sendmail im Container. Auf einem typischen VPS ohne eingerichteten Mailversand landet das irgendwo oder nirgends. Und selbst wenn die Mail ankommt: Bei uns waren nach einer Minute schon zwei Alarme aktiv, einer davon der falsche Swap-Alarm von oben. Wer so etwas jeden Tag bekommt, liest es irgendwann nicht mehr. Das ist die gefährlichste Form von Monitoring: eine, die zu oft ruft.

Daraus folgen zwei Regeln:

1. Teste den Alarmweg, nicht die Alarmregel. Lass nach dem Einrichten absichtlich etwas ausfallen (Dienst stoppen, falsches Keyword setzen) und warte, bis auf deinem Handy etwas ankommt. Erst dann ist das Monitoring fertig. Uptime Kuma hat dafür in jeder Benachrichtigung einen „Test“-Knopf. Der prüft aber nur den Kanal, nicht deinen Monitor. Mach beides.
2. Lieber wenige Alarme, die stimmen, als viele, die nerven. Schalte Alarme ab, die bei dir regelmäßig ohne echten Grund anschlagen, oder passe die Schwelle an. Jeder Fehlalarm macht den nächsten echten Alarm leiser.

Die dritte Falle: Monitoring auf demselben Server

Uptime Kuma, Netdata und Prometheus laufen in den meisten Anleitungen auf genau dem Server, den sie überwachen. Für Metriken von innen ist das unvermeidlich und auch richtig. Für die Frage „Ist mein Server erreichbar?“ ist es nutzlos. Fällt der Server aus, fällt das Monitoring mit aus. Es kann seinen eigenen Tod nicht melden.

Das gilt auch in kleinerem Maßstab. Läuft Uptime Kuma auf dem Webserver selbst, prüft es die Website über die lokale Netzwerkschnittstelle. Eine kaputte Firewall-Regel, ein abgelaufenes DNS, ein Problem beim Hoster mit dem Netz: Das alles sieht ein lokaler Monitor nicht, weil er den Umweg über das Internet gar nicht nimmt.

Unsere Praxis: Der Uptime-Monitor läuft auf einem zweiten, kleinen Server in einem anderen Rechenzentrum. Der kostet ein paar Euro im Monat und prüft den Hauptserver von außen. Er meldet sich nur, wenn dort wirklich etwas ausfällt. Wer keinen zweiten Server hat, kann für den Außenblick auch einen gehosteten Dienst mit kostenlosem Kontingent nehmen. Wichtig ist nur, dass die Prüfung von einer Stelle kommt, die nicht mit deinem Server zusammen ausfällt.

Uptime Kuma einrichten: Schritt für Schritt

Für die meisten Leser ist Uptime Kuma der beste Einstieg. Es ist in zehn Minuten eingerichtet und deckt die wichtigste Frage ab: Ist meine Website für Besucher in Ordnung? Am einfachsten installierst du es mit Docker Compose. Was Docker ist und wie Compose funktioniert, erklären wir in Was ist Docker? und mit fertigen Beispielen in Docker Compose Beispiel.

# docker-compose.yml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./kuma-data:/app/data

Zwei Zeilen darin sind wichtiger als der Rest.

127.0.0.1:3001:3001 bindet die Oberfläche nur an den lokalen Rechner. Erreichbar machst du sie über einen Reverse Proxy mit HTTPS (siehe Was ist ein Reverse Proxy?) oder per SSH-Tunnel. Schreibst du nur 3001:3001, ist die Oberfläche für das ganze Internet offen, und Docker umgeht dabei sogar die UFW-Firewall.

./kuma-data:/app/data legt die Datenbank in einen Ordner neben der Compose-Datei. Ohne diese Zeile legt Docker ein anonymes Volume an. Bei uns ist genau das passiert: Nach dem Löschen des Containers lag ein namenloses Volume mit allen Monitoren auf der Platte, das man leicht übersieht und beim nächsten Aufräumen löscht.

Dann starten:

docker compose up -d
docker compose logs -f uptime-kuma

Beim ersten Aufruf fragt Uptime Kuma 2 zuerst, welche Datenbank es verwenden soll: die eingebaute SQLite, eine eingebettete MariaDB oder eine externe MariaDB/MySQL. Für einen einzelnen Server mit bis zu einigen Dutzend Monitoren ist SQLite völlig ausreichend. Danach legst du das Admin-Konto an.

Wichtig: Das Admin-Konto legt an, wer die Seite zuerst aufruft. Es gibt keinen Einmal-Code und kein Passwort aus einer Datei. In unserem Test haben wir das Konto per Skript über die Websocket-Schnittstelle angelegt, ohne jede Anmeldung. Mach die Oberfläche deshalb erst öffentlich, nachdem du dein Konto erstellt hast.

Die ersten Monitore

1. Hauptseite als Keyword-Monitor. Typ „HTTP(s) - Keyword“, URL deiner Startseite, Keyword ein Text, der nur auf der funktionierenden Seite steht. Intervall 60 s, Retries 2, Timeout 15 s.
2. Wichtige Unterseite (Checkout, Login, API-Endpunkt) ebenso als Keyword- oder JSON-Monitor. Startseiten werden oft gecacht und funktionieren noch, wenn alles dahinter schon kaputt ist.
3. Zertifikatsablauf. In den erweiterten Einstellungen jedes HTTPS-Monitors kannst du „Certificate Expiry Notification“ einschalten. Kuma warnt dann standardmäßig vor Ablauf. Wie die automatische Erneuerung selbst funktioniert und warum sie still scheitern kann, steht in SSL Zertifikat erstellen.
4. Push-Monitor für Backups. Typ „Push“, Kuma zeigt dir eine URL. Hänge sie an das Ende deines Backup-Skripts, aber nur, wenn das Backup erfolgreich war:

#!/bin/bash
set -euo pipefail
/usr/local/bin/backup.sh
curl -fsS -m 10 "https://status.example.com/api/push/AbCdEf123?status=up&msg=OK" > /dev/null

Stell das Intervall des Push-Monitors etwas größer als den Abstand zwischen zwei Backups ein, bei einem täglichen Backup zum Beispiel 25 Stunden. Bleibt die Meldung aus, weil das Skript abgebrochen ist oder gar nicht erst gestartet wurde, schlägt Kuma Alarm. Mit set -e erreicht das Skript den curl-Befehl bei einem Fehler nicht. Warum das bei Backups so wichtig ist, zeigen unsere Messungen im Artikel zur 3-2-1-Backup-Strategie.

5. Benachrichtigung einrichten. Unter „Einstellungen → Benachrichtigungen“ einen Kanal anlegen und bei „Standardmäßig aktiviert“ einen Haken setzen, damit jeder neue Monitor ihn bekommt. Dann den Testknopf drücken und anschließend, siehe oben, einen echten Ausfall simulieren.

Netdata einrichten: Metriken von innen

Wenn du wissen willst, warum dein Server langsam ist, brauchst du Metriken von innen. Netdata ist dafür der schnellste Weg. Die offizielle Installation erfolgt per Skript direkt auf dem System oder als Docker-Container. Für Docker braucht Netdata Lesezugriff auf /proc und /sys des Hosts, sonst sieht es nur sich selbst:

docker run -d --name netdata \
  --pid=host --cap-add SYS_PTRACE \
  -v /proc:/host/proc:ro -v /sys:/host/sys:ro \
  -v netdataconfig:/etc/netdata -v netdatacache:/var/cache/netdata \
  -p 127.0.0.1:19999:19999 \
  --restart unless-stopped \
  netdata/netdata:stable

Auch hier gilt: 127.0.0.1: vor den Port. Netdata lauscht im Container auf allen Schnittstellen, und die API war in unserem Test ohne jede Anmeldung abrufbar. Ein einziger Aufruf von /api/v1/allmetrics lieferte 17.302 Zeilen mit allen Messwerten des Servers: Prozessnamen, Mountpoints, Netzwerkschnittstellen, Container-Namen. Für einen Angreifer ist das eine sehr bequeme Landkarte. Wer das Dashboard von außen sehen will, setzt einen Reverse Proxy mit Passwort davor oder nutzt einen VPN-Zugang.

Nach dem Start lohnt sich ein Blick auf die aktiven Alarme. Passe Schwellen an, die bei dir nicht sinnvoll sind (Netdata nennt die Konfiguration „health“, Dateien unter /etc/netdata/health.d/, bearbeiten per edit-config). Und richte einen echten Benachrichtigungsweg ein, statt dich auf sendmail zu verlassen: Netdata unterstützt unter anderem ntfy, Telegram, Discord, Slack und Webhooks.

Für einen kleinen VPS mit einem Kern solltest du außerdem das Messintervall von einer auf fünf oder zehn Sekunden heraufsetzen. Das senkt die CPU-Last deutlich, und für einen Webserver brauchst du keine sekundengenauen Kurven.

Prometheus und Grafana: wann sich der Baukasten lohnt

Der Prometheus-Stack lohnt sich, wenn du mehrere Server überwachst, eigene Anwendungen mit eigenen Metriken hast oder Daten über Monate auswerten willst. Für einen einzelnen Blog-Server ist er zu viel Arbeit.

Die minimale Einrichtung besteht aus vier Teilen: Node Exporter auf jedem Server, Prometheus mit einer prometheus.yml, die die Exporter abfragt, der Alertmanager für den Versand und optional Grafana. Eine Alarmregel sieht so aus:

# rules.yml
groups:
- name: basis
  rules:
  - alert: WebsiteDown
    expr: up{job="web"} == 0
    for: 1m
  - alert: PlatteFastVoll
    expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) < 0.1
    for: 10m

Und in der prometheus.yml unbedingt den Alertmanager eintragen, sonst passiert, was wir oben gemessen haben:

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

Prüfen kannst du das jederzeit mit curl -s localhost:9090/api/v1/alertmanagers. Steht dort eine leere Liste, kommt kein Alarm bei dir an.

Zwei weitere Messwerte aus dem Test: Prometheus hält Daten standardmäßig 15 Tage (storage.tsdb.retention.time). Für Langzeitvergleiche musst du das hochsetzen und Speicherplatz einplanen. Und die Prometheus-API war, wie bei Netdata, ohne Anmeldung abrufbar. Auch hier also nur lokal binden. Grafana akzeptierte in unserem Test den Standard-Login admin:admin über die API. Die Oberfläche fordert zwar beim ersten Login ein neues Passwort, aber erst, wenn jemand sich dort anmeldet. Setz das Admin-Passwort deshalb per Umgebungsvariable (GF_SECURITY_ADMIN_PASSWORD), bevor der Container zum ersten Mal startet.

Welches Server Monitoring passt zu dir?

Wenn du nur eines tust, dann das: Ein Keyword-Monitor auf deine wichtigste Seite, von einem anderen Rechner aus, mit einer Benachrichtigung, die du getestet hast. Das deckt den Großteil der echten Ausfälle ab, kostet nichts und ist in einer Viertelstunde fertig. Alles andere baust du darauf auf, wenn du merkst, dass dir Informationen fehlen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Uptime Monitoring und Server Monitoring?

Uptime Monitoring prüft von außen, ob ein Dienst antwortet, so wie ein Besucher. Server Monitoring im engeren Sinn misst von innen Werte wie CPU, RAM, Festplatte und Dienste. Du brauchst beides: Uptime Monitoring sagt dir, dass etwas kaputt ist, Server Monitoring sagt dir, warum.

Ist Uptime Kuma kostenlos?

Ja. Uptime Kuma ist Open Source unter MIT-Lizenz und kostet nichts. Du brauchst nur einen Rechner, auf dem es läuft. Idealerweise ist das nicht derselbe Server, den es überwacht.

Wie viel RAM braucht Uptime Kuma?

In unserem Test belegte Uptime Kuma 2.5.9 im Leerlauf 114 MiB und mit zwei aktiven Monitoren 144 MiB. Ein VPS mit 512 MB RAM reicht für Kuma allein. Das Docker-Image ist mit 2,53 GB allerdings groß, die „slim“-Variante ist deutlich kleiner.

Netdata oder Prometheus: Was ist besser für Einsteiger?

Netdata. Es funktioniert nach einem Befehl, erkennt Dienste automatisch und bringt fertige Alarme mit. Prometheus ist flexibler, aber du musst Exporter, Regeln, Alertmanager und Dashboards selbst zusammenbauen. Dafür braucht Prometheus mit Node Exporter nur rund 40 MiB RAM und kaum CPU, während Netdata bei uns dauerhaft 12 bis 13 Prozent eines Kerns nutzte.

Wie oft sollte ein Monitor prüfen?

Für normale Websites ist ein Intervall von 60 Sekunden mit zwei Wiederholungen ein guter Wert. Du erfährst von einem echten Ausfall nach etwa zwei bis drei Minuten, ohne dass dich jeder kurze Netzwerkfehler weckt. Kürzere Intervalle lohnen sich nur, wenn jede Minute Ausfall wirklich Geld kostet.

Warum zeigt mein Monitoring grün, obwohl die Seite kaputt ist?

Meistens, weil der Monitor nur den HTTP-Statuscode prüft. Viele Anwendungen liefern Fehlerseiten mit Status 200 aus. In unserem Test blieb ein HTTP-Monitor bei einer Datenbank-Fehlerseite 70 Sekunden lang grün, ein Keyword-Monitor schlug nach 10 Sekunden an. Prüfe deshalb immer auf einen Inhalt, der nur auf der funktionierenden Seite steht.

Kann ich meinen Server mit einem Tool auf demselben Server überwachen?

Für Metriken wie CPU und Festplatte ja. Für die Erreichbarkeit nein: Fällt der Server aus, fällt auch das Monitoring aus und kann dir nichts mehr melden. Der Uptime-Check sollte von einem zweiten Rechner oder einem externen Dienst kommen.

Wie werde ich bei einem Ausfall benachrichtigt?

Uptime Kuma bringt über 90 Kanäle mit, darunter Mail, Telegram, Discord, Slack, Signal (über einen Zusatzdienst), ntfy und Webhooks. Netdata unterstützt unter anderem Mail, Telegram, Discord, Slack, ntfy und Webhooks. Prometheus benachrichtigt nur über den separaten Alertmanager. Wichtig ist, den ganzen Weg einmal mit einem echten Ausfall zu testen. Ein Test-Knopf prüft nur den Kanal, nicht ob dein Monitor überhaupt anschlägt.

Wie überwache ich Cronjobs und Backups?

Mit einem umgekehrten Check, oft „Heartbeat“ oder „Push-Monitor“ genannt. Das Skript ruft nach jedem erfolgreichen Lauf eine URL auf. Bleibt der Aufruf länger als erwartet aus, schlägt das Monitoring Alarm. So bemerkst du auch Jobs, die gar nicht mehr starten. Die würden sonst nie eine Fehlermeldung erzeugen.

Welche Werte sollte ich beim Arbeitsspeicher überwachen?

Nicht „free“, sondern den Speicherdruck aus /proc/pressure/memory oder zumindest „available“. Freier Speicher ist auf einem gesunden Linux-Server fast immer knapp, weil der Kernel ihn als Cache nutzt. Netdata meldete bei uns einen vollen Swap als kritisch, obwohl 16 GB Speicher verfügbar waren.

Ist es gefährlich, Monitoring-Dashboards öffentlich zu machen?

Ja. Netdata und Prometheus waren in unserem Test ohne Anmeldung abrufbar und verraten Prozesse, Mountpoints, Container und Netzwerkdetails. Grafana akzeptierte über die API das Standardpasswort. Binde alle Monitoring-Ports an 127.0.0.1 und mach sie nur über einen Reverse Proxy mit Anmeldung oder per VPN zugänglich.

Fazit: Monitoring ist fertig, wenn der Alarm ankommt

Die Installation ist bei allen getesteten Werkzeugen der leichteste Teil. Uptime Kuma, Netdata und Prometheus laufen in Sekunden, die Dashboards sehen sofort gut aus. Was ein Monitoring wertvoll macht, steckt in drei unspektakulären Entscheidungen.

Prüf den Inhalt, nicht nur den Statuscode. Ein HTTP-Monitor, der eine Datenbank-Fehlerseite für „OK“ hält, gibt dir falsche Sicherheit. Ein Keyword-Monitor kostet keine Minute mehr und hat den Fehler bei uns nach zehn Sekunden gefunden.

Prüf von außen. Ein Monitor, der mit dem Server zusammen ausfällt, meldet genau den schlimmsten Fall nie. Ein zweiter kleiner Rechner oder ein externer Dienst löst das.

Prüf den Alarmweg. Prometheus hat bei uns einen Alarm korrekt ausgelöst und an niemanden geschickt. Netdata hat einen Alarm ausgelöst, der gar keiner war. Beides fällt erst auf, wenn man den Ernstfall probt. Also: einmal absichtlich etwas kaputt machen und warten, bis das Handy klingelt. Erst dann kannst du nachts ruhig schlafen.