DevOps 8 Min Lesezeit

Grafana Dashboards für VPS-Monitoring 2026

Warum Grafana 2026 der Standard für VPS-Monitoring ist

Wer 2026 einen VPS betreibt – ob für Gameserver, Webhosting, CI-Runner oder eine LLM-Inferenz-API – braucht mehr als htop und ein gelegentliches df -h. Ausfälle kündigen sich fast immer vorher an: Die Load steigt schleichend, der freie RAM sinkt, die Disk füllt sich mit Logs. Grafana macht diese Trends sichtbar, bevor der Server kippt.

Der entscheidende Vorteil gegenüber klassischen Tools wie Munin oder Cacti ist die Kombination aus Metriken, Logs und Traces in einer Oberfläche. Du siehst in einem Dashboard, dass die CPU bei 92 % hängt – und klickst direkt in die Loki-Logs des betroffenen Zeitraums, ohne den Server zu wechseln.

Dazu kommt die Alerting-Engine: Grafana 12.x kann Regeln zentral verwalten, Schwellwerte über mehrere Panels hinweg auswerten und Benachrichtigungen per Telegram, Slack, E-Mail oder Webhook verschicken. Ein node_load1 über 8 für zehn Minuten löst dann eine Nachricht aus, bevor Nutzer etwas merken.

Der Kostenpunkt ist überschaubar. Ein Monitoring-Stack für 10 bis 20 VPS läuft problemlos auf einem 4-GB-VPS für 3,79 € bis 6,80 € im Monat (Hetzner CX22/CX32). Wer keine eigene Infrastruktur will, nutzt Grafana Cloud mit 10.000 Metrik-Serien, 50 GB Logs und 3 Nutzern im kostenlosen Tier.

Der Stack: Prometheus, Node Exporter, Loki und Grafana

Das Standard-Setup 2026 besteht aus vier Komponenten. Prometheus 3.x ist die Time-Series-Datenbank und zieht im Pull-Verfahren alle 15 Sekunden Metriken von den Zielen. Node Exporter 1.8+ läuft auf jedem überwachten Host und stellt Systemmetriken unter :9100/metrics bereit.

Grafana 12.x ist die Visualisierungsschicht und fragt Prometheus über PromQL ab. Loki 3.x sammelt Logs und indiziert nur Labels statt des Volltexts – dadurch ist der Speicherbedarf rund 10- bis 20-mal geringer als bei Elasticsearch.

Seit der Einstellung von Promtail (End-of-Life im Februar 2026) ist Grafana Alloy der offizielle Sammel-Agent. Alloy ist ein einzelnes Binary, das Prometheus-Scraping, Log-Weiterleitung und OpenTelemetry-Empfang in einer River-Konfiguration vereint.

Für Container-Umgebungen kommt zusätzlich cAdvisor dazu, der pro Container CPU, RAM und Netzwerk-Traffic liefert. Wer Kubernetes betreibt, nimmt stattdessen kube-state-metrics und den Prometheus-Operator.

Komponente	Version 2026	RAM-Bedarf	Aufgabe
Prometheus	3.2.x	600 MB – 1 GB	Metriken speichern & abfragen
Grafana	12.1.x	200 – 350 MB	Dashboards & Alerting
Loki	3.4.x	300 – 600 MB	Log-Aggregation
Node Exporter	1.9.x	15 – 30 MB	Host-Metriken
cAdvisor	0.52.x	80 – 150 MB	Container-Metriken

VPS vorbereiten und Docker installieren

Als Monitoring-Host reicht ein separater VPS, damit ein ausfallender Zielserver nicht die Überwachung mitreißt. Empfehlenswert sind mindestens 2 vCPU, 4 GB RAM und 40 GB SSD. Bei mehr als 30 überwachten Hosts oder langer Log-Retention sollten es 8 GB RAM und 80 GB NVMe sein.

Zuerst das System aktualisieren und Docker über das offizielle Repository installieren:

apt update && apt upgrade -y
apt install -y ca-certificates curl gnupg ufw
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
https://download.docker.com/linux/debian $(. /etc/os-release && echo $VERSION_CODENAME) stable" \
> /etc/apt/sources.list.d/docker.list
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Danach die Firewall konfigurieren. Nur SSH und der Reverse Proxy dürfen von außen erreichbar sein – Prometheus (9090), Grafana (3000) und Loki (3100) bleiben auf 127.0.0.1 gebunden.

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Lege außerdem ein Verzeichnis /opt/monitoring an und setze die VM-Swappiness herunter, damit Prometheus nicht in den Swap schreibt: sysctl -w vm.swappiness=10 und den Wert in /etc/sysctl.d/99-monitoring.conf persistieren.

Docker-Compose-Stack: Prometheus und Grafana

Die folgende docker-compose.yml startet Prometheus, Grafana und Loki in einem Netzwerk. Wichtig sind die Retention-Grenzen, damit die Disk nicht vollläuft:

services:
  prometheus:
    image: prom/prometheus:v3.2.1
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./rules:/etc/prometheus/rules:ro
      - prom-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
      - '--storage.tsdb.retention.size=8GB'
      - '--web.enable-lifecycle'
    ports: ["127.0.0.1:9090:9090"]

  grafana:
    image: grafana/grafana:12.1.0
    restart: unless-stopped
    environment:
      GF_SECURITY_ADMIN_PASSWORD: ${GF_ADMIN_PW}
      GF_USERS_ALLOW_SIGN_UP: "false"
      GF_SERVER_ROOT_URL: https://grafana.example.com
    volumes:
      - grafana-data:/var/lib/grafana
    ports: ["127.0.0.1:3000:3000"]

  loki:
    image: grafana/loki:3.4.2
    restart: unless-stopped
    command: -config.file=/etc/loki/loki.yml
    volumes:
      - ./loki.yml:/etc/loki/loki.yml:ro
      - loki-data:/loki
    ports: ["127.0.0.1:3100:3100"]

volumes:
  prom-data:
  grafana-data:
  loki-data:

Die Passwörter gehören in eine .env-Datei mit Dateirechten chmod 600. Starten lässt sich der Stack mit docker compose up -d, Logs prüfst du mit docker compose logs -f prometheus.

Für die Loki-Konfiguration reicht ein minimales Filesystem-Setup mit retention_period: 336h (14 Tage) und dem tsdb-Index. Ein vollständiges Beispiel liegt in der Loki-Dokumentation.

Node Exporter und cAdvisor einbinden

Auf jedem zu überwachenden VPS installierst du den Node Exporter als systemd-Service. Das ist ressourcenschonender als ein Container mit --pid=host und läuft auch nach einem Docker-Neustart zuverlässig:

NE_VER=1.9.1
wget https://github.com/prometheus/node_exporter/releases/download/v$NE_VER/node_exporter-$NE_VER.linux-amd64.tar.gz
tar xzf node_exporter-$NE_VER.linux-amd64.tar.gz
mv node_exporter-$NE_VER.linux-amd64/node_exporter /usr/local/bin/
useradd --no-create-home --shell /bin/false node_exporter

Die Unit-Datei /etc/systemd/system/node_exporter.service enthält den Dienst mit den wichtigsten Collectors:

[Unit]
Description=Node Exporter
After=network.target

[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter \
  --collector.systemd \
  --collector.processes \
  --collector.filesystem.mount-points-exclude="^/(sys|proc|dev|run)($|/)"
Restart=always

[Install]
WantedBy=multi-user.target

Danach systemctl daemon-reload && systemctl enable --now node_exporter. Der Exporter lauscht auf Port 9100. Dieser Port darf nicht öffentlich erreichbar sein – erlaube ihn nur für die IP des Monitoring-Servers per ufw allow from 10.0.0.5 to any port 9100.

Für Container-Metriken startest du cAdvisor auf dem Zielhost mit --volume=/:/rootfs:ro --volume=/var/run:/var/run:ro --volume=/sys:/sys:ro --privileged. Alternativ nutzt du den Docker-Daemon-Metriken-Endpunkt, wenn du keinen privilegierten Container willst.

Die wichtigsten Metriken und ihre PromQL-Abfragen

Ein gutes VPS-Dashboard braucht nicht 80 Panels, sondern die richtigen 12. Diese PromQL-Abfragen haben sich in der Praxis bewährt und laufen auf jedem Node Exporter ab Version 1.5:

# CPU-Auslastung in Prozent
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# RAM-Auslastung in Prozent
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# Disk-Auslastung Root-Partition
100 - ((node_filesystem_avail_bytes{mountpoint="/",fstype!~"tmpfs|overlay"}
  * 100) / node_filesystem_size_bytes{mountpoint="/",fstype!~"tmpfs|overlay"})

# Load Average 1 Minute
node_load1

# Netzwerk-Durchsatz eingehend (Bytes/s)
rate(node_network_receive_bytes_total{device!~"lo|veth.*"}[5m])

# I/O-Wait in Prozent
rate(node_cpu_seconds_total{mode="iowait"}[5m]) * 100

Achte auf die rate()-Fenster: 5 Minuten sind ein guter Kompromiss zwischen Glättung und Reaktionszeit. Für Alerting-Regeln nimmst du längere Fenster wie [10m], um Flapping zu vermeiden.

Zusätzlich lohnt sich node_systemd_unit_state{state="failed"}, um abgestürzte Dienste zu erkennen, sowie node_filesystem_avail_bytes mit einem absoluten Schwellwert – 5 GB frei ist kritischer als 85 % belegt, wenn die Partition 500 GB groß ist.

Für TLS-Zertifikate, die bald ablaufen, nutzt du den Blackbox Exporter mit dem probe_ssl_earliest_cert_expiry-Metric. Ein Alert bei weniger als 14 Tagen Restlaufzeit hat schon viele Lets-Encrypt-Ausfälle verhindert.

Dashboards: Fertige Vorlagen vs. eigene Panels

Grafana hat einen öffentlichen Dashboard-Katalog mit über 8.000 Vorlagen. Die wichtigsten IDs für VPS-Monitoring:

Dashboard-ID	Name	Einsatzzweck
1860	Node Exporter Full	Der Klassiker, 100+ Panels pro Host
12486	Node Exporter Full (modern)	Aktualisierte Variante mit Heatmaps
14282	cAdvisor / Docker	Container-CPU, RAM, Netzwerk
13639	Loki & Promtail	Log-Rate, Fehler pro Service
9578	Alertmanager	Übersicht aktiver Alarme
3662	Prometheus 2.0 Overview	Selbstmonitoring des Scrapers

Importieren geht per UI unter Dashboards → New → Import mit der ID, oder deklarativ als JSON-Datei im Provisioning-Ordner /etc/grafana/provisioning/dashboards. Der deklarative Weg ist Pflicht, wenn du den Stack reproduzierbar aufsetzen willst.

Für den Alltag empfehle ich ein eigenes, schlankes Dashboard mit maximal 15 Panels: CPU, RAM, Disk pro Mountpoint, Netzwerk, Load, I/O-Wait, Uptime, Systemd-Failures. Das lädt in unter einer Sekunde, während Node Exporter Full bei 20 Hosts schnell 4 bis 6 Sekunden braucht.

Nutze Variablen mit label_values(instance), damit du oben im Dashboard per Dropdown zwischen Hosts wechseln kannst. Vergiss nicht, refresh: 30s und einen Standard-Zeitraum von „last 6 hours" zu setzen – kürzere Fenster erzeugen bei jedem Laden unnötige Last.

Alerting: Regeln, Alertmanager und Benachrichtigungen

Seit Grafana 9 laufen Alarme in der Unified Alerting Engine. Du definierst Regeln direkt in Grafana oder als YAML-Datei im Provisioning. Letzteres ist versionierbar und gehört ins Git-Repository.

groups:
  - name: vps-alerts
    interval: 30s
    rules:
      - alert: HighCpuLoad
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 10m
        labels: { severity: warning }
        annotations:
          summary: "CPU > 90% auf {{ $labels.instance }}"

      - alert: DiskAlmostFull
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / 1024^3) < 5
        for: 15m
        labels: { severity: critical }

      - alert: HostDown
        expr: up{job="node"} == 0
        for: 2m
        labels: { severity: critical }

Das for-Feld ist entscheidend: Ohne es feuert jeder kurze Spike einen Alarm. Bei CPU reichen 10 Minuten, bei HostDown sind 2 Minuten angemessen, weil ein echter Ausfall sofort relevant ist.

Für Benachrichtigungen nutzt du Contact Points. Telegram ist für Privatprojekte am schnellsten eingerichtet: Bot über @BotFather anlegen, Token und Chat-ID im Contact Point eintragen, fertig. Für Teams lohnt sich ein Alertmanager mit Gruppierung, damit bei einem Netzwerkausfall nicht 20 Alarme gleichzeitig eintreffen.

Ein bewährtes Muster sind zwei Eskalationsstufen: warning geht in einen Slack-Kanal, critical zusätzlich per Telegram und E-Mail. So bleibt der Kanal ruhig, ohne dass echte Notfälle untergehen.

Logs mit Loki und Grafana Alloy

Metriken zeigen das Was, Logs das Warum. Loki sammelt Logs von allen Hosts und macht sie in Grafana durchsuchbar. Auf jedem Zielserver installierst du Grafana Alloy per Paket-Repository:

apt install -y gpg
mkdir -p /etc/apt/keyrings/
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor > /etc/apt/keyrings/grafana.gpg
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" \
  > /etc/apt/sources.list.d/grafana.list
apt update && apt install -y alloy

Die Alloy-Konfiguration in /etc/alloy/config.alloy liest Journald und Nginx-Logs und schickt sie an Loki:

loki.source.journal "system" {
  forward_to = [loki.write.central.receiver]
  labels     = { host = "web-01", job = "systemd" }
}

loki.source.file "nginx" {
  targets    = [{ __path__ = "/var/log/nginx/*.log" }]
  forward_to = [loki.write.central.receiver]
}

loki.write "central" {
  endpoint { url = "http://10.0.0.5:3100/loki/api/v1/push" }
}

Wichtig ist Label-Disziplin: Jedes eindeutige Label erzeugt einen eigenen Stream und kostet Speicher. Nutze host, job und level – aber niemals Request-IDs oder User-IDs als Label. Diese gehören in den Log-Text und werden per Filterabfrage gesucht.

In Grafana verknüpfst du dann Metrik- und Log-Panel über eine Data-Link-Variable: Klickst du im CPU-Panel auf einen Spike, öffnet sich automatisch die Loki-Abfrage für genau diesen Host und Zeitraum.

Ressourcenbedarf, Retention und Kosten

Die Faustregel für Prometheus: pro aktivem Host fallen mit Node Exporter rund 1.200 Zeitreihen an. Bei 10 Hosts sind das 12.000 Serien, bei einem 15-Sekunden-Scrape-Intervall etwa 800 Samples pro Sekunde. Das entspricht ungefähr 2 bis 4 GB komprimierter Daten pro Monat.

Anzahl Hosts	RAM gesamt	Disk / 30 Tage	Empfohlener VPS	Preis/Monat
1 – 5	1,5 GB	2 GB	2 vCPU / 4 GB	3,79 €
10 – 20	2,5 GB	6 GB	4 vCPU / 8 GB	6,80 €
50 – 100	6 GB	25 GB	8 vCPU / 16 GB	15,00 €

Loki ist deutlich speicherhungriger als Prometheus: Rechne mit 0,5 bis 1 GB pro Tag und Host bei normalem Log-Aufkommen. Eine 14-Tage-Retention mit retention_period: 336h und Kompression im tsdb-Format reduziert das um 60 bis 70 %.

Alternative: Grafana Cloud im Free Tier mit 10.000 Metrik-Serien, 50 GB Logs, 14 Tagen Retention und 3 Nutzern. Für kleine Setups völlig ausreichend, aber darüber hinaus kostet es ab 29 $ pro Monat plus nutzungsbasierte Gebühren.

Wer 25 € monatlich für Managed-Monitoring sparen will, fährt mit einem eigenen 8-GB-VPS deutlich günstiger – vorausgesetzt, du rechnest die eigene Arbeitszeit nicht mit ein.

Sicherheit, Alternativen und Ausblick 2026

Grafana darf niemals ungeschützt im Internet stehen. Setze einen Reverse Proxy wie Caddy davor, der TLS automatisch per ACME bezieht:

grafana.example.com {
    reverse_proxy 127.0.0.1:3000
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
    }
}

Zusätzlich: GF_USERS_ALLOW_SIGN_UP=false, starke Admin-Passwörter, 2FA über TOTP aktivieren und Rollen nach Least-Privilege vergeben. Für Teams lohnt sich OAuth über GitHub oder Keycloak statt lokaler Nutzerverwaltung.

Als Alternativen haben sich VictoriaMetrics (sparsamer als Prometheus, PromQL-kompatibel, ideal ab 100 Hosts), Netdata (Sofort-Setup ohne Konfiguration, aber begrenztes Alerting) und Uptime Kuma (reines Blackbox-Monitoring) etabliert. Für reine Erreichbarkeitsprüfungen ist Uptime Kuma in 10 Minuten aufgesetzt und schlägt Grafana in der Einfachheit.

Der Trend 2026 geht klar zu OpenTelemetry als einheitlichem Protokoll. Grafana Alloy unterstützt OTLP nativ, sodass du Metriken, Logs und Traces mit einem Agenten einsammeln kannst. Wer heute neu aufsetzt, sollte Alloy statt Promtail und Node-Exporter-Kombination planen – das spart langfristig Migrationsaufwand.

FAQ

Wie viel RAM braucht Grafana mit Prometheus auf einem VPS?

Für 1 bis 5 überwachte Hosts reichen 1,5 GB RAM, für 10 bis 20 Hosts solltest du 2,5 GB einplanen. Prometheus belegt dabei den größten Anteil (600 MB bis 1 GB), Grafana rund 300 MB und Loki 300 bis 600 MB. Ein VPS mit 4 GB RAM und 2 vCPU für 3,79 € im Monat ist ein solider Einstieg.

Kann ich Grafana ohne Prometheus betreiben?

Ja. Grafana unterstützt über 150 Datenquellen, darunter InfluxDB, VictoriaMetrics, Elasticsearch, MySQL und CloudWatch. Wenn du bereits InfluxDB für IoT-Daten nutzt, kannst du Grafana direkt daran anbinden. Prometheus ist nur dann die erste Wahl, wenn du viele Hosts mit Standard-Hostmetriken überwachst, weil Node Exporter und die fertigen Dashboards perfekt zusammenspielen.

Welche Dashboard-ID ist die beste für Node Exporter?

Dashboard 1860 („Node Exporter Full") ist der Klassiker mit über 100 Panels und funktioniert mit allen Node-Exporter-Versionen ab 1.0. Die modernere Variante 12486 bietet Heatmaps und bessere Perzentil-Visualisierungen. Für den täglichen Gebrauch empfehle ich, eines der beiden zu importieren und daraus ein eigenes, auf 15 Panels reduziertes Dashboard abzuleiten.

Wie sichere ich Grafana im Internet ab?

Binde Grafana ausschließlich an 127.0.0.1, setze einen Reverse Proxy mit TLS davor und aktiviere GF_USERS_ALLOW_SIGN_UP=false. Ergänze HSTS-Header, aktiviere 2FA über TOTP und vergebe Rollen nach Least-Privilege. Wenn möglich, beschränke den Zugriff zusätzlich per VPN oder IP-Allowlist im Reverse Proxy – das eliminiert die meisten Angriffsflächen.

Lohnt sich Grafana Cloud oder ein eigener Monitoring-VPS?

Bis 10.000 Metrik-Serien und 50 GB Logs ist Grafana Cloud kostenlos und wartungsfrei – ideal für kleine Projekte. Ab etwa 20 Hosts oder langen Retention-Zeiten wird der eigene VPS günstiger: Ein 8-GB-Server für 6,80 € im Monat ersetzt schnell 29 $ plus nutzungsbasierte Kosten. Der eigene Stack kostet dafür Einrichtungs- und Wartungszeit.