Monitoring für Self-Hosted-Stacks: Uptime Kuma, Grafana und Alerting-Strategien

Ihr Docker-Stack läuft. Die Anwendung ist erreichbar, die Datenbank antwortet, die Benutzer sind zufrieden. Bis eines Morgens nichts mehr geht — und niemand weiß, seit wann. Die Festplatte war voll. Oder der Datenbank-Container hat sich leise verabschiedet. Ohne Monitoring erfahren Sie von Ausfällen, wenn Kunden sich beschweren.

Monitoring ist kein Luxus, sondern Pflicht für jeden produktiven Self-Hosting-Stack. In diesem Artikel zeigen wir Ihnen zwei Ansätze — von der einfachen Uptime-Überwachung bis zum vollständigen Metriken-Stack — und welche Strategie zu welchem Setup passt.

Was muss überwacht werden?

Bevor wir Tools betrachten, klären wir, was überhaupt überwacht werden soll. Die Antwort hängt von Ihrem Stack ab, aber diese Basismetriken braucht jeder:

Host-Metriken

CPU-Auslastung: Dauerhaft über 80 Prozent? Ihr Server ist unterdimensioniert oder ein Prozess dreht durch.
RAM-Nutzung: Linux nutzt freien RAM als Cache — das ist normal. Kritisch wird es, wenn Swap aktiv wird.
Festplattenbelegung: Der Klassiker. Logs, Docker-Images und Datenbanken wachsen schleichend. Bei 90 Prozent sollte ein Alarm auslösen.
Netzwerk-I/O: Ungewöhnliche Spitzen deuten auf DDoS-Versuche oder fehlerhafte Cronjobs hin.

Container-Metriken

Container-Status: Läuft, gestoppt oder in einer Restart-Schleife?
Container-Restarts: Ein Container, der alle 5 Minuten neu startet, hat ein Problem — auch wenn er technisch “läuft”.
CPU und RAM pro Container: Welcher Service frisst die Ressourcen?
Docker-Disk-Usage: Alte Images, gestoppte Container und ungenutzte Volumes belegen Speicher.

Anwendungs-Metriken

HTTP-Antwortzeiten: Wird die Seite langsamer? Ab wann merken es Benutzer?
HTTP-Statuscodes: 5xx-Fehler häufen sich? Die Anwendung hat ein Problem.
Datenbank-Verbindungen: Connection-Pool ausgeschöpft? Queries dauern zu lange?
SSL-Zertifikate: Läuft das Zertifikat in 7 Tagen ab? Besser jetzt warnen als nach dem Ablauf.

Ansatz 1: Uptime Kuma — einfach, effektiv, schnell eingerichtet

Uptime Kuma ist der perfekte Einstieg ins Monitoring. Ein einzelner Docker-Container, eine übersichtliche Web-UI, und in 5 Minuten eingerichtet. Uptime Kuma ist Open Source (MIT-Lizenz) und verbraucht minimal Ressourcen.

Installation

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma-data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  uptime-kuma-data:

Nach docker compose up -d erreichen Sie die UI unter Port 3001. Beim ersten Aufruf legen Sie einen Admin-Account an.

Was Uptime Kuma kann

HTTP(S)-Monitoring: Prüft Erreichbarkeit und Antwortzeit von Webseiten und APIs. Konfigurierbar: erwarteter Statuscode, Suchstring im Response, Timeout.
TCP/UDP-Port-Checks: Datenbank erreichbar? Redis antwortet? SMTP-Port offen?
Docker-Container-Status: Über den Docker-Socket prüfen, ob Container laufen (daher das Volume-Mount oben).
DNS-Monitoring: Prüft, ob DNS-Einträge korrekt auflösen.
SSL-Zertifikatsablauf: Warnt X Tage vor dem Ablauf.
Keyword-Monitoring: Prüft, ob ein bestimmter Text auf einer Seite vorhanden ist — erkennt Defacements oder Fehlkonfigurationen.
Push-Monitor: Für Cronjobs — der Job “pusht” nach erfolgreichem Lauf an Uptime Kuma. Bleibt der Push aus, wird alarmiert.

Alerting

Uptime Kuma unterstützt über 90 Benachrichtigungskanäle: E-Mail, Telegram, Slack, Discord, Webhooks, Gotify, Ntfy, PagerDuty und viele mehr. Für die meisten Teams reichen Telegram (sofortige Push-Nachricht aufs Handy) oder E-Mail.

Grenzen von Uptime Kuma

Uptime Kuma überwacht Erreichbarkeit, nicht Performance. Es sagt Ihnen, dass die Datenbank erreichbar ist — aber nicht, dass sie 90 Prozent des RAM frisst. Für tiefere Einblicke brauchen Sie den nächsten Ansatz.

Ansatz 2: Prometheus + Grafana — der vollständige Metriken-Stack

Wenn Sie wissen wollen, warum etwas langsam ist (nicht nur, ob es läuft), führt an Prometheus + Grafana kein Weg vorbei.

Die Architektur

Prometheus: Sammelt Metriken von Exportern in regelmäßigen Intervallen (Pull-basiert). Speichert Zeitreihendaten. Unterstützt mächtige Abfragesprache (PromQL).
Grafana: Visualisiert die Prometheus-Daten als Dashboards. Konfigurierbare Alerting-Regeln.
Node Exporter: Exportiert Host-Metriken (CPU, RAM, Disk, Netzwerk).
cAdvisor: Exportiert Container-Metriken (CPU, RAM, Netzwerk pro Container).

Docker Compose für den Monitoring-Stack

services:
  prometheus:
    image: prom/prometheus:latest
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'

  grafana:
    image: grafana/grafana:latest
    restart: unless-stopped
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana
    environment:
      GF_SECURITY_ADMIN_PASSWORD: sicheres_passwort

  node-exporter:
    image: prom/node-exporter:latest
    restart: unless-stopped
    pid: host
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--path.rootfs=/rootfs'

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    restart: unless-stopped
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro

volumes:
  prometheus-data:
  grafana-data:

Prometheus-Konfiguration

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

Grafana-Dashboards

Die Community stellt fertige Dashboards bereit, die Sie per ID importieren:

Node Exporter Full (ID: 1860): CPU, RAM, Disk, Netzwerk — der Klassiker für Host-Monitoring.
Docker Container Monitoring (ID: 193): CPU, RAM und Netzwerk pro Container.
cAdvisor (ID: 14282): Detaillierte Container-Metriken mit Filesystem-Usage.

In Grafana: “Dashboards → Import → Dashboard ID eingeben → Load”. Prometheus als Datenquelle auswählen — fertig.

Alerting richtig einrichten

Monitoring ohne Alerting ist ein hübsches Dashboard, das niemand anschaut. Die Kunst liegt darin, die richtigen Schwellwerte zu setzen — zu empfindlich erzeugt Alarm-Müdigkeit, zu großzügig verpasst echte Probleme.

Empfohlene Alert-Regeln

Festplatte über 85%: Warning. Über 95%: Critical. Gibt genug Zeit zum Reagieren, bevor der Server stillsteht.
RAM über 90% (ohne Cache): Warning. OOM-Killer wird bald aktiv.
CPU über 90% für mehr als 10 Minuten: Warning. Kurze Spitzen sind normal, anhaltende Last nicht.
Container-Restart erkannt: Sofort alarmieren. Ein Restart deutet auf einen Crash hin.
HTTP-Endpoint nicht erreichbar seit 2 Minuten: Critical.
SSL-Zertifikat läuft in weniger als 14 Tagen ab: Warning.
Keine Backup-Meldung seit 25 Stunden: Critical (bei täglichen Backups).

Benachrichtigungskanäle

Bewährt in der Praxis:

Telegram: Sofortige Push-Benachrichtigung. Bot erstellen via @BotFather, Chat-ID ermitteln, in Grafana oder Uptime Kuma einrichten. Kostenlos, zuverlässig, funktioniert auf allen Geräten.
E-Mail: Für nicht-kritische Alerts (Warnungen, tägliche Zusammenfassungen).
Slack/Discord Webhooks: Für Teams, die bereits einen dieser Dienste nutzen.
Ntfy: Self-hosted Push-Benachrichtigungen. Wenn Sie auch hier die Kontrolle behalten wollen.

Health Checks in Docker Compose

Die erste Verteidigungslinie ist kein externes Tool, sondern Docker selbst. Health Checks in der docker-compose.yml erkennen, wenn ein Service intern nicht mehr funktioniert:

services:
  web:
    image: nginx:alpine
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost/ || exit 1"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

  database:
    image: mariadb:11
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

Docker markiert Container als “unhealthy” und kann über restart: unless-stopped automatisch neustarten. In Kombination mit depends_on: condition: service_healthy starten abhängige Services erst, wenn die Datenbank tatsächlich bereit ist — nicht nur, wenn der Container läuft.

Log-Aggregation: Einfach anfangen

Logs sind die dritte Säule der Observability (neben Metriken und Alerting). Für die meisten Self-Hosting-Setups reicht ein pragmatischer Ansatz:

Minimal: Docker-eigene Logs

# Alle Logs eines Stacks sehen
docker compose logs -f --tail=100

# Nur Fehler eines bestimmten Services
docker compose logs php 2>&1 | grep -i error

Docker speichert Logs als JSON-Dateien unter /var/lib/docker/containers/. Konfigurieren Sie Log-Rotation, damit die Dateien nicht unbegrenzt wachsen:

# /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Fortgeschritten: Loki + Grafana

Grafana Loki ist die Log-Aggregation-Lösung aus dem Grafana-Ökosystem. Leichtgewichtiger als Elasticsearch (ELK-Stack), integriert sich nahtlos in bestehende Grafana-Dashboards. Mit dem Loki Docker Driver werden Container-Logs automatisch an Loki gesendet:

services:
  loki:
    image: grafana/loki:latest
    restart: unless-stopped
    volumes:
      - loki-data:/loki

  # Andere Services nutzen den Loki-Log-Driver:
  web:
    image: nginx:alpine
    logging:
      driver: loki
      options:
        loki-url: "http://localhost:3100/loki/api/v1/push"

In Grafana können Sie dann Logs und Metriken auf demselben Dashboard anzeigen — sehen Sie einen CPU-Spike in einem Container, klicken Sie direkt zu den Logs dieses Containers.

Ressourcenverbrauch des Monitoring-Stacks

Monitoring verbraucht selbst Ressourcen. Eine Orientierung:

Uptime Kuma: ~150 MB RAM, minimale CPU. Ideal für Server mit wenig Reserve.
Prometheus (30 Tage Retention, 5 Targets): 300 bis 500 MB RAM, 1 bis 5 GB Disk.
Grafana: 200 bis 300 MB RAM.
Node Exporter: ~20 MB RAM.
cAdvisor: 100 bis 200 MB RAM (kann auf Low-Memory-Servern problematisch sein).
Loki (kleines Setup): 200 bis 400 MB RAM, Disk abhängig vom Log-Volumen.

Gesamter Prometheus+Grafana-Stack: ~1 GB RAM. Auf einem 4-GB-Server ist das signifikant — auf einem 8-GB-Server kein Problem.

Welcher Ansatz für welches Setup?

Einzelner Server, 1-3 Anwendungen: Uptime Kuma

Schnell eingerichtet, geringer Ressourcenverbrauch, deckt die wichtigsten Szenarien ab. Perfekt für den Einstieg und für kleine Setups.

Mehrere Server oder komplexe Stacks: Prometheus + Grafana

Sobald Sie wissen müssen, warum etwas langsam ist (nicht nur ob), ist der vollständige Stack die richtige Wahl. Unverzichtbar für produktive Setups mit SLA-Anforderungen.

Die Kombination: Beides

Uptime Kuma für schnelle Erreichbarkeitschecks und SSL-Überwachung, Prometheus + Grafana für tiefe Metriken. Die Tools ergänzen sich perfekt.

Monitoring als Managed Service

Monitoring einrichten ist eine Sache — es dauerhaft betreiben eine andere. Alert-Regeln müssen gepflegt, Dashboards angepasst und Speicher für Metriken verwaltet werden. Bei netzspitze.tech ist Monitoring integraler Bestandteil jedes Managed-Hosting-Pakets: Container-Status, Ressourcen-Metriken, SSL-Überwachung und Alerting — ohne dass Sie sich um Prometheus-Konfiguration oder Grafana-Updates kümmern müssen.

In einem kostenlosen 15-Minuten-Call besprechen wir, welche Monitoring-Strategie für Ihren Stack sinnvoll ist.

Monitoring für Self-Hosted-Stacks: Uptime Kuma, Grafana und Alerting-Strategien