⚡ HomelabVergleich

Monitoring ohne Cloud: Was läuft auf dem Server?

Du betreibst einen oder mehrere Server, macht das seit Monaten ganz gut, und dann – plötzlich – ist ein Dienst weg. Nicht weil jemand etwas kaputt gemacht hat, sondern weil ein Container abstürzte, die Platte voll läuft, oder die CPU seit Stunden auf 100 Prozent läuft, ohne dass du es mitgekriegt hast. Monitoring ist genau die Antwort auf diese Lücke: es sagt dir, was passiert ist, bevor der Nächste es dir erzählt.

Der eine wesentliche Grund für Monitoring ist nicht, dass es schön aussieht. Es ist, dass ein Server ohne Monitoring im Ernstfall blind ist. Du merkst eine Ausfallstunde oft erst, wenn jemand anderes fragt. Das ist der Moment, in dem Monitoring von „Nice-to-have" zu „wird sonst teuer" wird.

Dieser Artikel geht davon aus, dass du einen Linux-Host hast (Debian, Ubuntu, ähnlich), der Docker oder ähnliches nutzt, und dass du etwas wissen willst, ohne eine Cloud-Abonnementschnittstelle einzubauen. Es gibt hier keine versprochenen Magic Numbers – nur Komponenten, die wirklich existieren, und Konfigurationen, die funktionieren.

Die drei Ebenen, die man nicht vermischen darf

Monitoring besteht aus drei Ebenen, die man sauber trennen sollte. Wenn man sie vermischt, endet man schnell mit einer Lösung, die alles halbzweiundhalb macht und nichts ordentlich.

Ebene 1 – Verfügbarkeit von außen. Das ist die einfachste Frage: Ist der Dienst erreichbar? Antwort kommt von außen, nicht von innen. Wenn dein Webserver läuft, aber sein Port nicht mehr auf der IP hört, sagt dir ein Check von außen Bescheid. Das ist die Ebene, auf der Uptime Kuma angesiedelt ist.

Ebene 2 – Ressourcen und Metriken im Host. Das ist die Ebene, auf der du wissen willst, wie viel CPU, RAM, Plattenplatz, I/O und Netzwerk gerade genutzt wird. Das ist Host-intern. Prometheus mit Node Exporter ist hier die gängige Wahl – Node Exporter ist der Komponente, die systemd-ähnliche Metriken aus dem Host holt und auf einem HTTP-Port ausliefert, den Prometheus abfragt.

Ebene 3 – Logs zentral sammeln und durchsuchen. Metriken sagen dir „CPU ist auf 100 Prozent". Logs sagen dir „warum". Wenn ein Container abstürzt, zeigt die Metrik den abstürzenden Container, aber der Log sagt dir den Stacktrace. Loki ist hier die Komponente, die Logs sammelt und speichert, und Grafana kann sie anzeigen. Vector ist optional als Sammler davor – er holt Logs von verschiedenen Quellen ein und reicht sie an Loki weiter. Loki allein reicht auch, wenn die Log-Quellen einfach sind.

Die drei Ebenen sind komplementär. Verfügbarkeitschecks allein sagen dir nicht, warum etwas ausgefallen ist. Metriken allein sagen dir nicht, was im Log passiert ist. Logs allein sagen dir nicht, dass etwas gerade nicht erreichbar ist. Alles drei zusammen ist der sinnvolle Minimum-Betrieb.

Vergleichstabelle: Uptime Kuma, Prometheus-Stack, vollständige Lösung

Die folgende Tabelle vergleicht die drei Ebenen einzeln und gemeinsam nach Kriterien, die für Homelab- und kleine-Firmen-Betrachtungen relevant sind.

| Kriterium | Uptime Kuma (Ebene 1 nur) | Prometheus + Node Exporter (Ebene 2 nur) | Uptime Kuma + Prometheus + Loki gemeinsam |

|---|---|---|---|

| Aufwand für Erstinstallation | Niedrig – ein Docker-Container oder Binär, 30–60 Minuten bis laufend | Mittel – Prometheus, Node Exporter, Alertmanager, ggf. Grafana; je nach Vorkenntnis 2–6 Stunden | Hoch – drei Komponenten mit eigenen Konfigurationen, Alarm-Routing, Log-Pipelines; 1–2 Arbeitstage für vollständigen Betrieb |

| Speicherbedarf | Gering – SQLite oder PostgreSQL für Statusverlauf, Metriken im RAM | Mittel – Prometheus speichert Zeitreihen auf lokaler Platte; bei 30 Tage Aufbewahrung und moderater Metrik-Anzahl 5–20 GB je nach Konfiguration | Höher – Prometheus-Plattenbedarf plus Loki-Speicher für Logs; Loki mit Object-Storage-Backend (z.B. S3-kompatibel oder lokaler MinIO) oder direkt auf Platte; ohne Kompression und Aufbewahrungsregeln schnell mehrere GB pro Woche |

| Alarmierungs-Möglichkeiten | E-Mail, Slack, Discord, Push, Webhook, Telegram integriert; keine Metrik-basierten Regeln | Alertmanager mit Pluggable-Integrationen (Slack, E-Mail, PagerDuty, Webhook); Regeln auf Metrikwerten; komplex zu konfigurieren, aber mächtig | Kombination: Verfügbarkeits-Alarme aus Uptime Kuma, metrische Alarme aus Prometheus/Alertmanager; Log-basierte Alarme möglich (z.B. bestimmte Fehlermuster in Loki) |

| Logsuche | Keine – nur Statusverfügbarkeit | Keine – nur Metriken | Ja, über Loki + Grafana Explore oder LogQL-Abfragen; Suchgeschwindigkeit hängt von Log-Menge und Indexierung ab |

| Dienstabhängigkeiten | Ein einzelner Container oder Binary; wenig Abhängigkeiten | Prometheus, Node Exporter (auf jedem überwachten Host), Alertmanager optional, Grafana optional; Node Exporter als separate Instanz pro Host | Uptime Kuma, Prometheus + Node Exporter je Host, Loki, ggf. Vector als Log-Agent, Grafana für Darstellung; mehr moving parts, aber alle unabhängig voneinander betreibbar |

| Auswertung im Browser | Webinterface für Status, Zeitreihen für Checks | Prometheus Expression Browser für Ad-hoc-Anfragen; Dashboards über Grafana | Grafana-Dashboards für alles – Uptime-Status, Metriken, Logs in einem Interface |

| Lizenzkosten | Open Source (AGPL); keine Lizenzkosten | Prometheus, Node Exporter, Alertmanager, Grafana Open Source und kostenfrei (Grafana unter AGPL; kommerzielle Editionen existieren, aber die Open-Source-Version deckt den normalen Betrieb) | Summe der Einzelkomponenten; keine direkten Lizenzkosten für die Open-Source-Komponenten; Cloud-Infrastruktur entfällt, dafür eignet sich lokaler Speicher und Wartung |

| Passend für | Einzelne Dienste, einfache Verfügbarkeitsüberwachung, kleine Homelabs mit wenig Zeit | Server mit Ressourcenbeobachtung, Alarmierungs-Bedarf auf Metriken, mehrere Hosts | Volles Monitoring mit Alarmierung, Logsuche und Dashboard; Firmen mit echtem Betriebsbedarf, Homelaber mit Zeit und Lust zum Konfigurieren |

Kurz gesagt: Wenn du nur wissen willst, ob dein Webserver gerade da ist, reicht Uptime Kuma. Wenn du wissen willst, warum er aus dem Rutsch ist, fehlt dir die Ursache. Wenn du sowohl wissen willst, ob er da ist, als auch, was gerade auf dem Server passiert, brauchst du mehr als eine Komponente.

Datenschutz und Datenmenge: was lokal bleibt und was geschätzt werden darf

Monitoring erzeugt Daten. Die Frage ist nicht, ob du Daten erzeugst – die Frage ist, welche Daten du lokal behältst, wie lange, und was du daraus machen darfst.

Was du lokal behalten solltest. Metriken auf dem Host selbst gehören lokal. CPU, RAM, Plattenplatz, Netzwerk – das sind Infrastrukturmetriken, die nichts über deine Kunden oder Inhalte aussagen, und die du ohne Remote-Übermittlung lokal auswerten kannst. Auch Verfügbarkeits-Check-Ergebnisse von außen – ob ein Dienst erreichbar war – sind operational und meist unproblematisch lokal.

Was du lokal behalten sollte, aber mit Harding. Logs enthalten potenziell sensitive Inhalte – Zugriffslogs auf Webseiten können URL-Pfade, Query-Parameter, Tokens in URLs enthalten. Wenn Logs aus Anwendungen stammen, die Benutzerdaten verarbeiten, solltest du prüfen, ob die Log-Pipeline sensible Felder nicht ungefiltert weitergibt. Das betrifft besonders: Authentifizierungslogs mit erfolgreichen Login-Vorgängen, Access-Logs mit Session-IDs in URLs, Anwendungslager mit personenbezogenen Request-Parametern.

Aufbewahrungsdauern, die sich lohnen. Für Metriken: 30 Tage ist ein sinnvoller Standard für den täglichen Bedienwert. mehr als 90 Tage auf lokaler Platte sind selten nützlich für tägliches Monitoring und kosten spürbar Speicher. Für Logs: 7–14 Tage auf schnellen Storage für aktuelle Suche, dann Archive auf günstigerer Platte, falls du Compliance-Gründe hast. Wenn du keine Compliance-Anforderungen hast (z.B. Branchenvorschriften), ist 14–30 Tage auf lokalem Storage für die meisten Homelab-Setups ausreichend.

Wann Metriken geschätzt werden dürfen. Du darfst Metriken schätzen und aggregieren, wenn die ursprüngliche Granularität für den Zweck nicht nötig ist. Prometheus selbst speichert Rohzeitreihen und erlaubt Aggregation in Abfragen. Du kannst Stundenwerte aus Minutenwerten berechnen lassen, ohne die Minutenwerte dauerhaft zu speichern. Das ist kein Datenschutzverstoß, sondern eine Speicheroptimierung. Wichtig: nicht alle Echtzeitwerte zu speichern, wenn du nur trends willst, ist legitim und praktisch.

Wann du auf externe Speicherung ausweichen solltest. Wenn der lokale Storage zu klein wird, um Metriken mit sinnvoller Aufbewahrung zu halten, ist ein lokaler Object-Storage (z.B. MinIO als S3-kompatibler Storage) eine Option, bevor du nach außen gehen musst. Nur wenn der gesamte lokale Weg nicht mehr ausreicht und die Daten nicht sensitiv sind, ist ein kostenloser oder günstiger zentraler Speicher in Frage.

Zwei realistische Anleitungen

Anleitung 1: Reines Uptime Kuma – Verfügbarkeit von außen messen, Alarm per E-Mail und Push

Dies ist der Einstieg für den Fall, dass du nur wissen willst, ob deine Dienste erreichbar sind – ohne Metriken, ohne Logs.

Voraussetzungen:

Schritt 1: Uptime Kuma installieren

Über Docker ist der gängigste Weg:


docker run -d \
  --name uptime-kuma \
  --restart always \
  -v /opt/uptime-kuma:/app/data \
  -p 3001:3001 \
  louislam/uptime-kuma:1

Der Port 3001 ist der Standard-HTTP-Port von Uptime Kuma. Nach dem Start erreichst du das Webinterface unter http://<dein-host>:3001. Der erste Start öffnet einen Setup-Assistenten für einen Admin-Account.

Pfad- und Datenhinweis: Der Mount /opt/uptime-kuma:/app/data ist die Persistence. Ohne diesen Mount verlierst du alle Konfigurationen beim Container-Neustart. Die Datenbank liegt im Volume unterhalb von /app/data im Container; der genaue interne Pfad bleibt von Uptime Kuma verwaltet – du mountest das Volume, ohne in das interne Layout eingreifen zu müssen.

Schritt 2: Erste Monitore anlegen

Nach dem Login im Webinterface: Monitore → Neuer Monitor. Wichtige Typen:

Schritt 3: Alarmierungs-Kanäle einrichten

Im Webinterface: Einstellungen → Alarmierungs-Kanäle. Uptime Kuma bringt mehrere Kanäle mit:

Schritt 4: Alarmierungsrichtlinien setzen

Jeder Monitor kann mit Alarmierungsrichtlinien verknüpft werden. Du legst fest, wann Alarm ausgelöst wird: bei Statuswechsel (Up → Down) oder bei wiederholten Fehlern innerhalb eines Zeitfensters. Für produktiven Betrieb ist ein wiederholter Fehler-Fenster sinnvoller als ein einzelner Ausfall – ein einzelner Check kann flackern, ohne dass etwas wirklich ausgefallen ist.

Ein sinnvoller Minimalansatz: Alarm nach 3 fehlgeschlagenen Checks innerhalb von 5 Minuten, Wiederherstellung nach 2 erfolgreichen Checks.

Schritt 5: Erreichbarkeit prüfen

Ein schneller Test: Neue Monitor für https://brillianze.de oder einen eigenen öffentlichen Dienst, Alarmierung auf den eigenen Kanal, und beobachte, ob der Alarm kommt, wenn du den Dienst temporär runternimmst. Das ist der einzige Weg, zu verifizieren, dass die Alarmierung funktioniert – nicht durch Konfigurieren, sondern durch Auslösen.

Was Uptime Kuma nicht macht. Uptime Kuma sagt dir nicht, warum ein Dienst ausgefallen ist. Es sagt nicht, wie voll die Platte ist. Es sagt nicht, ob ein Container abstürzte. Für das brauchst du Ebene 2 und 3.

Anleitung 2: Prometheus + Node Exporter + Alertmanager + Grafana – Ressourcen und Metriken im Host

Dies ist die Ebene für Metriken – CPU, RAM, Plattenplatz, Container-Abstürze, und Alarmierung darauf.

Voraussetzungen:

Schritt 1: Node Exporter auf jedem zu überwachenden Host

Node Exporter ist eine separate Prozess-Instanz pro Host, die Metriken aus dem System ausliest und auf einem HTTP-Port ausliefert. Der Standard-Port ist 9100.


docker run -d \
  --name node-exporter \
  --restart always \
  --net host \
  -v "/proc:/host/proc:ro" \
  -v "/sys:/host/sys:ro" \
  -v "/:/rootfs:ro" \
  prom/node-exporter:latest \
  --path.procfs=/host/proc --path.sysfs=/host/sys --path.rootfs=/rootfs

Der --net host-Modus ist hier praktisch, weil Node Exporter so die Host-Identität in Metriken sieht. Die Volume-Mounts sind read-only – Node Exporter schreibt nicht auf das Host-Filesystem.

Schritt 2: Prometheus installieren und konfigurieren

Prometheus selbst läuft als separater Dienst und fragt die Node Exporter-Instanzen regelmäßig ab. Die Konfiguration liegt in einer YAML-Datei – üblicherweise /etc/prometheus/prometheus.yml oder ein Docker-mountetes Volume.

Ein minimaler Prometheus-Konfigurations-Eintrag für einen Node Exporter-Host:


global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["localhost:9100"]

Wenn du mehrere Hosts überwachst, trägst du jeden Host als Target unter static_configs ein, oder nutzt eine dynamische Entdeckung (z.B. Datei-basierte oder Kubernetes-Service-Discovery, je nach Umgebung).

Prometheus als Docker-Container:


docker run -d \
  --name prometheus \
  --restart always \
  -v /etc/prometheus:/etc/prometheus:ro \
  -v /var/lib/prometheus:/var/lib/prometheus \
  -p 9090:9090 \
  prom/prometheus:latest \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --storage.tsdb.retention.time=30d

--storage.tsdb.retention.time=30d begrenzt die Aufbewahrung auf 30 Tage. Ohne diese Angabe speichert Prometheus standardmäßig 15 Tage (einstellbar über storage.tsdb.retention in neueren Versionen). Der Wert ist nicht Konstanten-universell – er ist eine Konfiguration, die du nach Bedarf setzt.

Schritt 3: Alertmanager für Alarmierung auf Metriken

Alertmanager ist eine separate Komponente, die Prometheus-Alarme entgegennimmt und an Kanäle weiterleitet. Er hat seine eigene Konfigurationsdatei (alertmanager.yml).

Ein weitergeleiteter Alertmanager enthält mindestens einen Empfänger und eine Route. Beispiel für E-Mail-Routing:


route:
  receiver: "email-default"
  group_by: ["alertname"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
  - name: "email-default"
    email_configs:
      - to: "monitoring@brillianze.de"
        from: "prometheus-alert@brillianze.de"
        smarthost: "smtp.brillianze.de:587"
        require_tls: true

Du startest Alertmanager als eigenen Container oder Prozess und verknüpfst ihn mit Prometheus über die --alertmanager.url-Konfiguration oder über die Prometheus-Konfigurationssektion alerting:


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

Schritt 4: Regeln für CPU, RAM, Plattenplatz und Container-Abstürze

Prometheus-Regeln sind Alerting-Regeln, die in Prometheus selbst konfiguriert werden – entweder als separate Regel-Dateien, die in prometheus.yml unter rule_files eingebunden werden, oder als in der Konfigurationsdatei unter alerting.rule zugewiesen. Regeln verwenden PromQL-Ausdrücke.

Beispiele für sinnvolle Regeln (als Regel-Datei, z.B. alerts.yml):


groups:
  - name: host-metrics
    rules:
      - alert: HostHighCPU
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Hohe CPU-Auslastung auf {{ $labels.instance }}"
          description: "CPU-Auslastung über 90% für 10 Minuten auf {{ $labels.instance }}"

      - alert: HostLowMemory
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 90
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Wenig verfügbarer RAM auf {{ $labels.instance }}"
          description: "Verfügbarer RAM unter 10% auf {{ $labels.instance }}"

      - alert: HostDiskFull
        expr: (1 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"})) * 100 > 85
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Platte nahezu voll auf {{ $labels.instance }}"
          description: "Verfügbarer Platz unter 15% auf {{ $labels.instance }}"

      - alert: ContainerRestarting
        expr: increase(container_last_seen[10m]) == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Container scheint nicht mehr sichtbar auf {{ $labels.instance }}"
          description: "Container-Eintrag in cgroup nicht mehr aktiv nach 10 Minuten auf {{ $labels.instance }}"

Erläuterung zu den Regeln:

Schritt 5: Grafana Dashboard

Wenn Grafana hinzukommt, importierst du Dashboards entweder manuell (JSON-Import aus öffentlichen Quellen wie dem offiziellen Node Exporter-Dashboard, das in der Grafana-Dashboard-Sammlung verfügbar ist) oder durch Aufbau eigener Panels.

Grafana-Installation über Docker:


docker run -d \
  --name grafana \
  --restart always \
  -v /var/lib/grafana:/var/lib/grafana \
  -p 3000:3000 \
  grafana/grafana:latest

Nach dem Start trägst du Prometheus als Data Source ein (Host: http://prometheus:9090 oder die IP des Prometheus-Hosts), und importierst oder erstellst Dashboards.

Ein Standard-Node-Exporter-Dashboard zeigt unter anderem: CPU-Auslastung je Core, RAM-Nutzung, Plattenplatz je Mount, Netzwerk-I/O, Systemlast. Du erstellst zusätzliche Panels für spezifische Metriken nach Bedarf.

Authentifizierung auf Grafana: Grafana hat einen administrativen Benutzer bei der ersten Anmeldung. Du solltest das Dashboard nicht ohne Authentifizierung öffnen – das ist einer der häufigsten Fehler (siehe unten). Für Remote-Zugriff setzt du entweder einen authentifizierten Zugang, oder ein VPN/Tunnel davor.

Häufige Fehler, die man vorher merkt

Alarm-Pattern, das niemand beachtet. Der häufigste Fehler: Alarmierung steht, aber niemand schaut sie an. E-Mail-Alarme landen in einem Postfach, das niemand liest, oder in einem Kanal, der zu laut ist und ignoriert wird. Lösung: Alarmierung auf einen Kanal setzen, der tatsächlich beobachtet wird, und regelmäßig prüfen, ob Alarms den erwarteten Menschen erreichen. Ein Test-Alarm beim Einrichten ist Pflicht.

Zu knapp gewählte Schwellen. Eine Platte, die bei 90% voll alarmiert, ist zu spät, wenn die Anwendung erst bei 95% Schreibvorgänge ablehnt. Eine CPU-Regel, die bei 80% für 30 Sekunden alarmiert, produziert False Positives und wird ignoriert. Schwellen Werte sind gewählte Kompromiss-Werte – sie sollten auf der tatsächlichen Betriebskritikalität basieren, nicht auf einem willkürlichen Wert. Für Festplatten ist 80–85% eine sinnvolle Warn-Schwelle, für RAM bei 85–90% verfügbar, für CPU bei längerfristig über 90% als Warnung, wenn es als kritisch gilt.

Monitoring ohne Alarmierung. Das ist der häufigste Fall in Homelabs: Dashboards sind schön, man schaut hin und wieder, aber es gibt keine Alarmierung. Wenn du nach einem Ausfall auf das Dashboard schaust, ist es zu spät. Monitoring ohne Alarmierung ist kein Monitoring – es ist einHistorie-Anzeiger. Mindestens ein Kanal für kritische Zustände ist der minimale Betrieb.

Tokens im Klartext in Alert-Templates. Manche Alarmierungs-Kanäle (z.B. Slack, Telegram) benötigen Token oder Webhook-URLs. Diese gehören nicht in öffentlich zugängliche Konfigurationsdateien, die auf GitHub landen oder auf anderen Hosts kopiert werden. Sie gehören in die Alertmanager- oder Uptime-Kuma-Konfiguration, auf dem überwachten Host, mit Zugriffsschutz. Die gleiche Regel gilt für SMTP-Passwörter in Alertmanager-Konfigurationen.

Tote Dienste nach Monaten. Ein Uptime-Kuma-Monitor, der einen Dienst über Monate überwacht, ohne dass jemand den Monitor ernsthaft prüft, kann Fake-Sicherheit erzeugen. Wenn der Monitor nicht mehr funktioniert, weil der Uptime-Kuma-Service selbst nicht mehr läuft, oder der SMTP-Server nicht mehr erreichbar ist, erhältst du auch keine Alarmierung. Ein regelmäßiger Check der Alarmierung selber gehört zum Betrieb.

Zugriff auf das Dashboard ohne Authentifizierung. Grafana- oder Prometheus-HTTP-Ports, die ohne Authentifizierung im Netzwerk liegen, sind für jeden erreichbar, der das Netzwerk kennt. Das ist in lokalen Netzwerken mit Vertrauensbasis oft enthalten, aber nicht in allen. Für Firmenumgebungen ist eine Authentifizierung Pflicht. Für Homelabs ist es eine bewusste Entscheidung – aber eine Entscheidung, die man trifft, nicht überrascend.

Host voll, ohne dass ein einzelner Container auffällt. Das passiert: Metriken zeigen, dass RAM oder CPU hoch ist, aber kein einzelner Container ist der Grund. Das kann sein durch Sammeleffekte (viele Container, die zusammen viel nehmen), durch Host-Prozesse die nicht in Containern laufen, oder durch Kernel-Speicher. In diesem Fall helfen Metriken auf dem Host, aber nicht Container-Metriken. Node Exporter zeigt Host-Level-Metriken; Container-Metriken kommen aus einem separaten Exporter (cAdvisor, Docker-Plugin). Wenn du nur Node Exporter hast, siehst du das Problem, aber nicht die Container, die es verursachen – und musst manuell nachsehen.

FAQ

Wie überwache ich Backup und Restore automatisch?

Automatische Überwachung von Backups hat zwei Aspekte: ob das Backup erfolgt ist (Status des Backup-Jobs), und ob das Backup wiederherstellbar ist (integritätsprüfung). Für den Statusaspekt kannst du einen Uptime-Kuma-Check oder einen Prometheus-Export des Backup-Job-Status einrichten – z.B. einen Cron-Job, der nach jedem Backup eine Metrik oder einen Statuswert in eine Datei schreibt, die Node Exporter oder ein eigener Agent ausliest. Für die Wiederherstellbarkeit ist ein reguläres Restore-Test-Verfahren üblich – nicht durch Monitoring, sondern durch geplanten Test. Monitoring kann dir sagen, dass das Backup-Modul nicht mehr läuft, aber nicht, dass das Backup selbst korrupt ist. Das ist der Unterschied zwischen Prozess-Monitoring und Integrity-Testing.

Ich habe nur einen Host. Womit fange ich an?

Mit Uptime Kuma. Es ist die geringste Komplexität für einen messbaren Vorteil. Wenn du später Ressourcenbeobachtung brauchst, fügst du Node Exporter und Prometheus hinzu. Der Aufbau von Allem gleich am Anfang führt oft zu unvollendeter Konfiguration. Eines, das funktioniert, ist besser als drei, die halb konfiguriert sind.

Was ist, wenn mein Server nicht im eigenen Netzwerk läuft, sondern bei einem Provider?

Dann ist der Verfügbarkeitscheck von außen wichtiger denn je – Uptime Kuma kann auch externe Dienste überwachen, wenn der Kuma-Host eine öffentliche Verbindung hat. Metriken auf dem Server selbst sind weiterhin lokal, wenn du Zugriff auf den Host hast. Wenn der Provider den Host überwacht, ist das Metriken vom Provider – nicht von dir. Deine eigene Metrik-Sammlung gibt dir Unabhängigkeit von Anbieter-Dashboards.

Brauche ich einen separaten Host für Prometheus?

Nein, nicht zwingend. Prometheus kann auf demselben Host laufen wie Node Exporter, aber dann musst du darauf achten, dass die Prometheus-Instanz selbst nicht das ist, was alarmiert, wenn sie überlastet ist. Für den Anfang und kleine Setups auf einem Host funktioniert das. Für Firmenumgebungen mit mehreren Hosts ist ein separater Monitoring-Host üblicher.

Wie viel RAM und CPU verbraucht die Monitoring-Software?

Das ist abhängig von der Konfiguration. Uptime Kuma verbraucht im Betrieb wenige Hundert MB RAM, je nach Monitore-Anzahl. Prometheus mit 30 Tagen Aufbewahrung und einigen dutzend Metriken pro Host kann 500 MB bis mehrere GB RAM beanspruchen – abhängig von der Anzahl der Zeitreihen. Node Exporter ist sehr leichtgewichtig – ein Bruchteil einer CPU und wenige Dutzend MB RAM. Loki mit lokaler Platte und moderaten Log-Mengen ist mittleren RAM-Verbrauchs; ohne Object-Storage-Backend und bei großer Log-Menge kann der Speicher erheblich werden. Die Werte sind keine bekannten Benchmarks; sie hängen von konkreter Konfiguration, Host-Größe und Metrik-Anzahl ab.

Kann ich Loki und Vector vermeiden, wenn ich nur Metriken will?

Ja. Loki und Vector sind für die Logs-Ebene. Wenn du nur Metriken (Ebene 2) und Verfügbarkeitschecks (Ebene 1) brauchst, kannst du beide weglassen. Das ist ein legitimer Betrieb – viele Setups laufen nur mit Uptime Kuma und Prometheus.

Interne Verlinkungsvorschläge zu vorhandenen BsN-Artikeln

Bildvorschläge

Bild 1

Bild 2

Bild 3

Bild 4

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.