Zum Hauptinhalt springen

UNABHÄNGIGES WISSENSFORUM Unabhängige Hosting-Community • Keine offizielle Verbindung zur netcup GmbH.

NETCUP GUIDE
FORUM · GUTSCHEINPOOL
Tutorials Stufe: Mittelstufe Dauer: 35 Minuten // 17 Min. Lesezeit • Geprüft:

Netcup Server-Ressourcen überwachen: CPU Steal (%st), NVMe-Latenz & Prometheus + Grafana

Wenn eine Datenbankabfrage plötzlich langsam wird oder die Antwortzeit eines API-Endpunkts auf einem virtualisierten Server von 15 ms auf 600 ms springt, ist blindes Raten keine Engineering-Strategie. Auf Netcup KVM-Hosts erfordert echte Observability die saubere Unterscheidung zwischen eigener Gast-CPU-Auslastung (%usr/%sys) und Hypervisor-Nachbarschaftskonflikten (%st CPU Steal Time), das Messen der NVMe-Block-Queue-Tiefe (aqu-sz) sowie der Lese-/Schreiblatenz (r_await/w_await), die Auswertung der Linux-Kernel Pressure Stall Information (/proc/pressure/*) und die Visualisierung historischer Trends. Dieser Leitfaden kombiniert präzise CLI-Diagnosewerkzeuge mit einem abgesicherten, an Loopback gebundenen Prometheus + Node Exporter + cAdvisor + Grafana Telemetrie-Stack.

THREAD-AUTOR // OP Elena Rostova Lead Cloud Infrastructure Architect (EU KVM & Netzwerk-Engineering)
MOD-PRÜFUNG // CO-MAINTAINER Marcus Vance Senior Linux Systems & Security Auditor
BEITRAGSSTATUS // AKTUALISIERT Community-Standards →
MODERATOR-HINWEIS // TESTUMGEBUNG & TRANSPARENZ Verifiziert mit sysstat 12.6+, ioping, vnstat 2.12, Prometheus v2.54, Node Exporter v1.8, cAdvisor v0.49 und Grafana v11.2 auf Netcup VPS G11.5s/G12.5 und Root Server G12.5 Knoten.

VORAUSSETZUNGEN // ANFORDERUNGEN

CHECKLISTE
  • ✓ Ein Netcup VPS (z. B. VPS 500 G12.5 oder VPS 1000 G12.5) oder Root Server (z. B. RS 1000 G12.5) mit Ubuntu 24.04 LTS oder Debian 12
  • ✓ Installiertes Docker und Docker Compose v2 (für den Prometheus + Grafana Observability-Stack)
  • ✓ sudo-Berechtigungen per SSH

Wichtige Erkenntnisse (Key Takeaways)

KURZFAZIT
  • 01 Nutzen Sie mpstat -P ALL 1 10 und vmstat 1 zur Überwachung von %st (CPU Steal Time): Netcup Root Server mit dedizierten AMD EPYC-Kernen (wie der RS 1000 G12.5) liegen typischerweise bei 0,0 %–0,3 % Steal, während VPS-Instanzen mit geteilten vCores bei Hypervisor-Spitzen temporären Steal zeigen können.
  • 02 Messen Sie die Speichergesundheit über iostat -xz 1 (r_await und w_await in ms) sowie zerstörungsfreie Lese-Tests mit ioping -RD -c 20 / anstatt massiver dd- oder fio-Schreibschleifen, die NVMe-Lebensdauer und Produktiv-IOPS kosten.
  • 03 Fragen Sie die Linux-Kernel Pressure Stall Information (cat /proc/pressure/{cpu,memory,io}) ab, um Ressourcenengpässe im Subsekundenbereich vor einem OOM- oder I/O-Stall zu erkennen.
  • 04 Binden Sie Prometheus (9090), Node Exporter (9100), cAdvisor (8080) und Grafana (127.0.0.1:3000) strikt an Localhost bzw. ein internes Docker-Bridge-Netzwerk und greifen Sie per SSH-Port-Forwarding (ssh -L 3000:127.0.0.1:3000) sicher auf Grafana zu.
  • 05 Kombinieren Sie vnstat mit Prometheus-Alarmregeln, um das monatliche Bandbreitenvolumen sowie die Root-Partition-Auslastung (< 82 % für SCP-Snapshots) zu überwachen.
📑 Inhaltsverzeichnis (5 Abschnitte) ▼
§ 01

Schritt 1: CPU Steal Time (%st) und Kernel Pressure Stall Information (PSI) diagnostizieren

Um den architektonischen Unterschied zwischen einem Netcup VPS (geteilte vCores, die vom KVM-Hypervisor dynamisch geplant werden, wie beim VPS 500 G12.5 oder VPS 1000 G12.5) und einem Netcup Root Server (dedizierte physische AMD EPYC-Threads, die exklusiv Ihrer VM zugewiesen sind, wie beim RS 1000 G12.5) zu verstehen, ist die Metrik %st (Steal Time) entscheidend. Steal Time misst den prozentualen Zeitanteil, in dem ein virtueller CPU-Thread in Ihrem Linux-Gastsystem ausführungsbereit (runnable) war, der KVM-Hypervisor jedoch einen anderen Mandanten oder Host-Prozess auf dem physischen CPU-Kern eingeplant hat.

Zusätzlich zu mpstat und vmstat stellen moderne Linux-6.x-Kernel unter /proc/pressure/cpu, /proc/pressure/memory und /proc/pressure/io die Pressure Stall Information (PSI) bereit. PSI erfasst exakt den Prozentsatz der Echtzeit über die letzten 10, 60 und 300 Sekunden, in denen Prozesse aufgrund fehlender Hardware-Ressourcen blockiert waren.

Die PSI-Metriken unterscheiden dabei zwischen zwei kritischen Zuständen: Die Zeile some gibt an, wie viel Prozent der Zeit mindestens ein Thread auf eine Ressource (CPU, Speicher-Reclaim oder Block-I/O) warten musste, während andere Threads noch weiterarbeiten konnten. Die Zeile full hingegen zeigt den Zeitanteil, in dem sämtliche nicht-idlen Aufgaben im System gleichzeitig blockiert waren – ein Anstieg von full avg60 bei /proc/pressure/memory oder /proc/pressure/io kündigt unmittelbares Swap-Thrashing oder einen bevorstehenden Datenbank-Stillstand weit präziser an als klassische Load-Averages.

Interpretation der Linux-CPU- & NVMe-Telemetrie-Schwellenwerte auf Netcup VPS vs. Root Servern
Metrik & DiagnosewerkzeugGesunde Baseline (Root Server G12.5)Normalbereich Shared VPSKritischer Handlungsschwellenwert
CPU Steal Time (%st in mpstat)0,0 % – 0,3 %0,2 % – 3,5 %> 8,0 % dauerhaft über >15 Min. (Upgrade von VPS auf RS empfohlen)
CPU I/O Wait (%iowait in vmstat)< 1,0 %< 2,5 %> 10,0 % (iotop und Postgres-Checkpoints prüfen)
NVMe Lese-/Schreiblatenz (r_await / w_await)0,15 ms – 0,85 ms0,30 ms – 1,80 ms> 8,0 ms dauerhaft (Queue-Tiefe aqu-sz prüfen)
Memory PSI (full avg60 in /proc/pressure/memory)0,00< 0,50> 5,00 (massives Swap-Thrashing / drohender OOM)
I/O PSI (full avg60 in /proc/pressure/io)< 0,20< 1,00> 10,00 (Engpass im Storage-Subsystem)
Telemetrie-Tools installieren & Pro-Kern-CPU-Steal (%st) sowie Kernel-PSI prüfen
bash
sudo apt update
sudo apt install -y sysstat iotop ioping vnstat htop btop

# 1. Historische sysstat-Aufzeichnung alle 10 Minuten aktivieren (/var/log/sysstat)
sudo sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat vnstat

# 2. CPU-Auslastung und Steal Time (%steal) pro vCore im 1-Sekunden-Takt messen (5 Messungen)
mpstat -P ALL 1 5

# 3. Linux-Kernel Pressure Stall Information (CPU-, Memory- und I/O-Stalls) auslesen
head -n 5 /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io

Befehlserklärung: Installiert und aktiviert sysstat (mpstat, iostat, sar) sowie vnstat, misst %steal über alle vCPUs im Sekundentakt und gibt die aktuellen Kernel-PSI-Durchschnittswerte aus.

ERWARTETE AUSGABE
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:     all    4.12    0.00    1.05    0.08    0.00    0.12    0.00    0.00    0.00   94.63

==> /proc/pressure/memory <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=1420
full avg10=0.00 avg60=0.00 avg300=0.00 total=810
§ 02

Schritt 2: NVMe-Storage-Latenz (iostat & ioping) und vnstat-Bandbreite messen

Führen Sie auf einem produktiven Live-Server niemals mehrere Gigabyte große fio-Schreibtests aus, nur um zu prüfen, ob das Disk-I/O gesund ist – dies sättigt die Storage-Queue und bremst Ihre eigenen Datenbankabfragen massiv aus. Nutzen Sie stattdessen iostat -xz 1, um die Live-Blockdevice-Zähler des Kernels (r_await, w_await, aqu-sz und %util) auszulesen, sowie ioping -D, um zerstörungsfrei die 4-KiB-Direct-I/O-Latenz in Mikrosekunden zu messen.

Achten Sie in der iostat -xz-Ausgabe besonders auf das Zusammenspiel von aqu-sz (Average Queue Size) und w_await. Auf modernen virtio-scsi-NVMe-Arrays im Netcup-Rechenzentrum verarbeitet das Subsystem parallele I/O-Anfragen über mehrere Hardware-Queues gleichzeitig. Ein %util-Wert von 60 % ist daher unkritisch, solange r_await und w_await unter 1,5 ms bleiben. Steigt jedoch aqu-sz dauerhaft über 4,0 bei gleichzeitig wachsenden w_await-Werten (> 10 ms), sollten Sie mit iotop -oPa prüfen, ob ein ungedrosselter Backup-Job oder ein ungetunter PostgreSQL-Checkpoint-Prozess die Schreibwarteschlange flutet.

NVMe-Block-Queue-Latenz (iostat) & zerstörungsfreien Direct-I/O-Ping (ioping) prüfen
bash
# 1. Erweiterte Block-Device-Statistiken prüfen (1-Sekunden-Intervall, 3 Berichte)
iostat -xz 1 3

# 2. Zerstörungsfreie 4-KiB-Direct-I/O-Latenz auf dem Root-Dateisystem messen (20 Anfragen)
sudo ioping -c 20 -i 0.1 -D /

# 3. Persistente tägliche und monatliche Netzwerk-Traffic-Summen in vnstat abfragen
vnstat -d 5
vnstat -m

Befehlserklärung: Meldet r_await (Leselatenz in ms), w_await (Schreiblatenz in ms) und aqu-sz (durchschnittliche Queue-Tiefe) auf /dev/vda, testet die direkte Disk-Latenz per ioping -D und fragt den Bandbreitenverbrauch über vnstat ab.

ERWARTETE AUSGABE
Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
vda              8.50    112.00     0.00   0.00    0.28    13.18   24.20    384.50     4.10  14.49    0.41    15.89    0.01   1.20

--- / (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.18 ms, 76 KiB read, 4.54 k iops, 17.7 MiB/s
min/avg/max/mdev = 164.2 us / 220.1 us / 389.4 us / 48.3 us
Die Traffic-Fair-Use-Policy von Netcup richtig einordnen

Netcup Root Server G12.5 und VPS G11.5s/G12.5 Tarife beinhalten eine kostenlose Traffic-Flatrate. Wenn bei Root-Servern G12.5 (RS 500–8000 G12.5, 2,5 Gbit/s) der Traffic über ein rollierendes 24-Stunden-Fenster 3 TB überschreitet, drosselt Netcup den Port temporär auf 300 Mbit/s; bei VPS 500–8000 G12.5 (2,5 Gbit/s) erfolgt ab 2 TB/24h eine temporäre Drosselung auf 200 Mbit/s und wird automatisch wieder aufgehoben, sobald der 24h-Schnitt unter den Schwellenwert fällt – ohne jegliche Zusatzkosten. Mit vnstat führen Sie ein unabhängiges Traffic-Protokoll parallel zum Statistik-Tab im SCP.

§ 03

Schritt 3: Den Prometheus + Node Exporter + cAdvisor + Grafana Compose-Stack bereitstellen

Um 30 Tage lang hochauflösende Telemetriedaten im 15-Sekunden-Takt sowohl für Ihren Linux-Host als auch für jeden einzelnen Docker-Container vorzuhalten, stellen wir unter /opt/stacks/monitoring einen ressourcenschonenden Monitoring-Stack aus vier Komponenten bereit.

Ein häufiger Fehler bei Standard-Deployments von cAdvisor auf Multi-Container-Hosts ist die ungedrosselte Erfassung sämtlicher Kernel-cgroup-Slices im Sekundentakt, was selbst im Leerlauf 8–12 % CPU-Last erzeugt. Durch die Übergabe von --docker_only=true, --housekeeping_interval=15s und das gezielte Deaktivieren hochfrequenter Subsystem-Metriken (--disable_metrics=percpu,sched,tcp,udp,diskIO,hugetlb,referenced_memory) senken wir den CPU-Bedarf von cAdvisor auf unter 0,5 %, während Prometheus seine Write-Ahead-Log-(WAL)-Segmente alle zwei Stunden effizient in komprimierte TSDB-Blöcke auf dem NVMe-Laufwerk kompaktiert:

  • ▪ node-exporter (v1.8): Exportiert Host-Kernel-Metriken (/proc, /sys, CPU Steal, PSI, Disk-I/O, Dateisystem-Füllstand, Netzwerkzähler).
  • ▪ cadvisor (v0.49): Exportiert pro Container cgroupv2-CPU-, RAM-RSS-, Page-Cache- und Netzwerkmetriken.
  • ▪ prometheus (v2.54): Fragt beide Exporter alle 15 Sekunden ab, wertet Alarmregeln aus und komprimiert die Zeitreihendaten (--storage.tsdb.retention.time=30d).
  • ▪ grafana (v11.2): Stellt visuelle Dashboards bereit und ist strikt an 127.0.0.1:3000 gebunden, sodass keine Monitoring-Ports im öffentlichen Internet erreichbar sind.
/opt/stacks/monitoring/compose.yaml
yaml
name: netcup_monitoring

services:
  prometheus:
    image: prom/prometheus:v2.54.1
    container_name: mon_prometheus
    restart: unless-stopped
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
      - "--storage.tsdb.retention.time=30d"
      - "--storage.tsdb.retention.size=4GB"
      - "--web.listen-address=0.0.0.0:9090"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./prometheus/alerts.yml:/etc/prometheus/alerts.yml:ro
      - prom_data:/prometheus
    networks:
      - mon_internal
    deploy:
      resources:
        limits:
          cpus: "0.50"
          memory: 512M
    security_opt:
      - no-new-privileges:true

  node-exporter:
    image: prom/node-exporter:v1.8.2
    container_name: mon_node_exporter
    restart: unless-stopped
    command:
      - "--path.procfs=/host/proc"
      - "--path.sysfs=/host/sys"
      - "--path.rootfs=/rootfs"
      - "--collector.pressure"
      - "--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    networks:
      - mon_internal
    deploy:
      resources:
        limits:
          cpus: "0.20"
          memory: 128M
    security_opt:
      - no-new-privileges:true

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.49.1
    container_name: mon_cadvisor
    restart: unless-stopped
    privileged: true
    devices:
      - /dev/kmsg:/dev/kmsg
    command:
      - "--docker_only=true"
      - "--housekeeping_interval=15s"
      - "--disable_metrics=percpu,sched,tcp,udp,diskIO,hugetlb,referenced_memory"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    networks:
      - mon_internal
    deploy:
      resources:
        limits:
          cpus: "0.30"
          memory: 256M

  grafana:
    image: grafana/grafana-oss:11.2.2
    container_name: mon_grafana
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      GF_SECURITY_ADMIN_USER: admin
      GF_SECURITY_ADMIN_PASSWORD: ${GRAFANA_ADMIN_PASSWORD:-ChangeMeImmediately_2026!}
      GF_USERS_ALLOW_SIGN_UP: "false"
      GF_SERVER_HTTP_ADDR: "0.0.0.0"
    volumes:
      - grafana_data:/var/lib/grafana
    networks:
      - mon_internal
    depends_on:
      - prometheus
    deploy:
      resources:
        limits:
          cpus: "0.50"
          memory: 384M
    security_opt:
      - no-new-privileges:true

volumes:
  prom_data:
  grafana_data:

networks:
  mon_internal:
    driver: bridge

Befehlserklärung: Startet Prometheus, Node Exporter (mit aktiviertem --collector.pressure für PSI-Metriken), cAdvisor (optimiert mit --housekeeping_interval=15s für minimalen CPU-Verbrauch) und Grafana strikt gebunden an 127.0.0.1:3000.

SICHERHEITSHINWEIS: Weder prometheus (9090), node-exporter (9100) noch cadvisor (8080) veröffentlichen Host-ports: – sie kommunizieren ausschließlich über das isolierte Docker-Netzwerk mon_internal.

§ 04

Schritt 4: Prometheus-Scrape-Ziele & Netcup-spezifische Alarmregeln konfigurieren

Erstellen Sie /opt/stacks/monitoring/prometheus/prometheus.yml und /opt/stacks/monitoring/prometheus/alerts.yml. Diese Alarmregeln überwachen gezielt die vier kritischen Zustände auf Netcup-Servern: Root-Festplattenbelegung über 82 % (wodurch Copy-on-Write-Snapshots im Netcup SCP blockiert würden), anhaltende CPU-Steal-Time über 10 %, erhöhte NVMe-Leselatenz sowie Speicherknappheit auf dem Host.

Jede Regel nutzt eine gezielte for:-Haltezeit (5m bzw. 10m), um Fehlalarme durch kurze Lastspitzen (etwa während eines nächtlichen Datenbank-Dumps oder Container-Image-Extracts) auszufiltern. In Grafana v11 können Sie unter Alerting -> Contact points zudem direkt einen Webhook-, Telegram-, Slack- oder SMTP-Benachrichtigungskanal hinterlegen, der die von Prometheus ausgewerteten Alarme ohne separaten Alertmanager-Container weiterleitet.

/opt/stacks/monitoring/prometheus/prometheus.yml
yaml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "/etc/prometheus/alerts.yml"

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "netcup_host_node"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "netcup_docker_containers"
    static_configs:
      - targets: ["cadvisor:8080"]

Befehlserklärung: Konfiguriert 15-Sekunden-Scrape-Intervalle für Prometheus, Node Exporter und cAdvisor über die interne Docker-Bridge.

/opt/stacks/monitoring/prometheus/alerts.yml
yaml
groups:
  - name: netcup_infrastructure_alerts
    rules:
      - alert: NetcupHighCpuStealTime
        expr: avg by (instance) (rate(node_cpu_seconds_total{mode="steal"}[5m])) * 100 > 10
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "High Hypervisor CPU Steal (>10%) on {{ $labels.instance }}"
          description: "KVM CPU steal time has exceeded 10% for 10 minutes. Consider migrating workload to a dedicated-core Netcup Root Server (RS)."

      - alert: NetcupRootDiskSpaceLowForSnapshots
        expr: (1 - (node_filesystem_avail_bytes{mountpoint="/",fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{mountpoint="/",fstype!~"tmpfs|overlay"})) * 100 > 82
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Root Filesystem >82% Full (SCP Snapshots Risk)"
          description: "Disk usage exceeds 82%. Netcup SCP Copy-on-Write snapshots require free disk headroom to operate."

      - alert: NetcupHighNvmeReadAwaitLatency
        expr: (rate(node_disk_read_time_seconds_total{device="vda"}[5m]) / clamp_min(rate(node_disk_reads_completed_total{device="vda"}[5m]), 1)) * 1000 > 12
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Elevated NVMe Read Latency (>12ms) on /dev/vda"

      - alert: HostMemoryAvailableBelow10Percent
        expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 10
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Host Available RAM <10% on {{ $labels.instance }}"

Befehlserklärung: Definiert PromQL-Alarmschwellenwerte speziell für Netcup KVM-Instanzen: CPU Steal > 10 %, Root-Disk > 82 % (Sicherung der CoW-Snapshot-Reserve), NVMe-Leselatenz > 12 ms und verfügbarer RAM < 10 %.

§ 05

Schritt 5: Stack starten & sicher per SSH-Port-Forwarding auf Grafana zugreifen

Starten Sie den Observability-Stack und verbinden Sie sich von Ihrer Workstation aus über einen verschlüsselten SSH-Tunnel (-L 3000:127.0.0.1:3000) mit Grafana. Fügen Sie in Grafana (http://localhost:3000) http://prometheus:9090 als Standard-Prometheus-Datenquelle hinzu und importieren Sie die bewährten Community-Dashboards mit der ID 1860 (Node Exporter Full) sowie 14282 (cAdvisor Docker Insights).

Der Zugriff über ssh -L bietet gegenüber einer öffentlich exponierten Subdomain einen entscheidenden Sicherheitsvorteil: Selbst wenn in der Web-Oberfläche von Grafana eine Authentifizierungs-Schwachstelle bekannt wird, ist der Port 127.0.0.1:3000 von außen physisch nicht erreichbar, da der Zugriff zuvor zwingend Ihre gehärtete Ed25519-SSH-Schlüsselauthentifizierung passieren muss.

Monitoring-Stack starten & über lokalen SSH-Tunnel verbinden
bash
# 1. Auf Ihrem Netcup-Server: Monitoring-Stack im Hintergrund starten
cd /opt/stacks/monitoring
sudo docker compose up -d
sudo docker compose ps

# 2. Auf Ihrer lokalen Workstation: SSH-Tunnel auf Port 3000 öffnen
ssh -N -L 3000:127.0.0.1:3000 adminuser@203.0.113.10
# Anschließend http://localhost:3000 im lokalen Browser öffnen

Befehlserklärung: Startet den 4-Container-Monitoring-Stack auf dem Netcup-Host und tunnelt den lokalen Port 3000 per SSH direkt zum an Loopback gebundenen Grafana-Container.

Häufige Fehlerbehebung

DIAGNOSE-GUIDE

[SYMPTOM] cAdvisor-Container verursacht auf einem unbelasteten Netcup VPS dauerhaft 8–12 % CPU-Last

Ursache: Standardmäßig erfasst cAdvisor jede Sekunde hochfrequente Per-CPU-, TCP/UDP-Socket- und Scheduler-Statistiken über sämtliche systemd-Slices hinweg.

Lösung: Übergeben Sie --docker_only=true, --housekeeping_interval=15s und --disable_metrics=percpu,sched,tcp,udp,diskIO,hugetlb,referenced_memory in der compose.yaml (wie in Schritt 3 gezeigt). Dadurch sinkt die CPU-Last von cAdvisor sofort auf unter 0,5 %.

[SYMPTOM] Grafana-Dashboard 1860 zeigt 100 % Festplattenbelegung oder listet Dutzende /var/lib/docker/overlay2-Mounts auf

Ursache: Node Exporter erfasst Container-Overlayfs-Mounts oder wurde ohne --path.rootfs=/rootfs gestartet.

Lösung: Stellen Sie sicher, dass --path.rootfs=/rootfs sowie --collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/) an node-exporter übergeben werden, und filtern Sie PromQL-Abfragen mit fstype!~"tmpfs|overlay".

[SYMPTOM] vnstat meldet direkt nach der Installation Not enough data available yet

Ursache: Der Daemon vnstatd initialisiert beim ersten Start seine SQLite-Datenbank und schreibt Traffic-Zähler standardmäßig alle 5 Minuten auf die Festplatte.

Lösung: Prüfen Sie mit systemctl status vnstat, ob der Dienst aktiv ist, und kontrollieren Sie mit vnstat --iflist, ob Ihre primäre Netzwerkkarte (eth0 oder ens3) überwacht wird. Mit vnstat -l können Sie sofort den Live-Durchsatz beobachten.

[SYMPTOM] Prometheus-Container startet nicht und meldet open /prometheus/queries.active: permission denied

Ursache: Das Prometheus-Image läuft unter der Nicht-Root-UID 65534 (nobody), während ein manuell angelegtes Bind-Mount-Verzeichnis auf dem Host root:root (0755) gehört.

Lösung: Nutzen Sie entweder ein benanntes Docker-Volume (prom_data:/prometheus, wobei Docker die Berechtigungen automatisch setzt) oder führen Sie sudo chown -R 65534:65534 /pfad/zu/prometheus/data aus.

Häufig gestellte Fragen (FAQ)

GEPRÜFTE ANTWORTEN

Welcher CPU-Steal-Wert (%st) ist auf einem Netcup VPS im Vergleich zu einem Netcup Root Server normal?

Auf einem Netcup Root Server (wie dem RS 1000 G12.5 oder RS 2000 G12.5) sind physische AMD EPYC-Kerne fest Ihrer Instanz zugewiesen, sodass %st typischerweise zwischen 0,0 % und 0,3 % liegt. Auf einem Netcup VPS (z. B. VPS 500 G12.5 oder VPS 1000 G12.5) werden vCores geteilt; Werte von 0,5 %–3,5 % sind völlig normal, während dauerhafte Werte über 8 %–10 % zu Ihren Hauptlastzeiten darauf hinweisen, dass ein Wechsel auf einen Root Server mit dedizierten Kernen sinnvoll ist.

Bietet das Netcup Server Control Panel (SCP) ebenfalls Ressourcen-Graphen auf Hypervisor-Ebene?

Ja. Im Netcup SCP finden Sie unter Statistics Hypervisor-basierte RRD-Zeitreihengraphen für CPU-Auslastung, Disk-IOPS und monatlichen Netzwerk-Traffic. Allerdings kennt das SCP weder den Speicherverbrauch einzelner Prozesse noch Docker-Container-Limits, Postgres-Slow-Queries oder /proc/pressure-PSI-Werte – weshalb die Kombination aus SCP und eigenem Node Exporter + Grafana ideal ist.

Wie viel RAM und Speicherplatz benötigt dieser 4-Container Prometheus + Grafana Stack?

Mit den in Schritt 3 konfigurierten cgroupv2-Limits und dem 15-Sekunden-Intervall benötigt der gesamte Stack (prometheus + node-exporter + cadvisor + grafana) lediglich ca. 280–360 MB RAM und rund 1,2 GB NVMe-Speicherplatz für volle 30 Tage Aufbewahrungsdauer.

Kann ich Grafana statt über einen SSH-Tunnel auch über eine öffentliche HTTPS-Subdomain bereitstellen?

Ja. Hängen Sie den grafana-Container in Ihr Caddy- oder Nginx-Reverse-Proxy-Netzwerk, richten Sie eine Subdomain wie metrics.example.com ein, belassen Sie GF_USERS_ALLOW_SIGN_UP=false und schützen Sie den Zugang zusätzlich per IP-Freigabe oder OAuth2/OIDC.

QUELLEN // GEPRÜFTE TECHNISCHE DOKUMENTATION

WEITERFÜHREND // EMPFOHLENE ARCHITEKTUR-AUDITS

Gutscheine →