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.
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 10undvmstat 1zur Überwachung von%st(CPU Steal Time): Netcup Root Server mit dedizierten AMD EPYC-Kernen (wie der RS 1000 G12.5) liegen typischerweise bei0,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_awaitundw_awaitin ms) sowie zerstörungsfreie Lese-Tests mitioping -RD -c 20 /anstatt massiverdd- oderfio-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
vnstatmit 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
- 02 Schritt 2: NVMe-Storage-Latenz (iostat & ioping) und vnstat-Bandbreite messen
- 03 Schritt 3: Den Prometheus + Node Exporter + cAdvisor + Grafana Compose-Stack bereitstellen
- 04 Schritt 4: Prometheus-Scrape-Ziele & Netcup-spezifische Alarmregeln konfigurieren
- 05 Schritt 5: Stack starten & sicher per SSH-Port-Forwarding auf Grafana zugreifen
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.
| Metrik & Diagnosewerkzeug | Gesunde Baseline (Root Server G12.5) | Normalbereich Shared VPS | Kritischer 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 ms | 0,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) |
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.
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 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.
# 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.
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 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.
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 an127.0.0.1:3000gebunden, sodass keine Monitoring-Ports im öffentlichen Internet erreichbar sind.
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.
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.
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.
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 %.
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.
# 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 ANTWORTENWelcher 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
- [1] Prometheus Node Exporter Offizieller Leitfaden (https://prometheus.io/docs/guides/node-exporter/)
- [2] Linux-Kernel Pressure Stall Information (PSI) Dokumentation (https://docs.kernel.org/accounting/psi.html)
- [3] Google cAdvisor Runtime-Flags & Storage-Referenz (https://github.com/google/cadvisor/blob/master/docs/runtime_options.md)