跳转至正文内容

独立技术知识论坛 主机玩家与运维交流社区 • 与德国 netcup GmbH 无官方隶属关系。

NETCUP GUIDE
知识论坛 · 实时优惠码池
运维教程 难度:中级进阶 耗时:35 分钟 // 阅读约 17 分钟 • 核验于

如何监控 Netcup 服务器资源:CPU Steal (%st)、NVMe 磁盘延迟与 Prometheus + Grafana 观测栈

当线上数据库查询突然变慢,或者某个 API 接口的 P99 响应时间从 15 ms 飙升到 600 ms 时,凭空猜测绝不是合格的系统工程策略。在 Netcup KVM 虚拟化宿主机上,深入的可观测性(Observability)要求我们能够精确区分客户机自身的 CPU 饱和(%usr/%sys)与母机邻居争抢导致的虚拟化窃取时间(%st CPU Steal Time),实时量化 NVMe 块设备队列深度(aqu-sz)与读写等待延迟(r_await/w_await),读取 Linux 内核压力停滞信息(/proc/pressure/* PSI),并将长周期历史趋势可视化。本指南首先详解底层 CLI 性能诊断工具链,随后带您部署一套绑定在本地回环接口上的 Prometheus + Node Exporter + cAdvisor + Grafana 容器化监控告警系统。

楼主 (OP) // 实测发起人 Elena Rostova 首席云基础设施架构师(欧洲 KVM 与网络工程)
版主复核 // 共同维护 Marcus Vance 高级 Linux 系统与安全审计工程师
帖子状态 // 最后修订 社区核查规范 →
版主按语 // 实测环境与社区透明说明 已在 Netcup VPS G11.5s/G12.5 与 Root Server G12.5 生产节点上,基于 sysstat 12.6+、ioping、vnstat 2.12、Prometheus v2.54、Node Exporter v1.8、cAdvisor v0.49 与 Grafana v11.2 完成验证。

环境要求 // 前置条件清单

检查清单
  • ✓ 一台运行 Ubuntu 24.04 LTS 或 Debian 12 的 Netcup VPS 或 Root Server
  • ✓ 已安装 Docker 与 Docker Compose v2(用于运行 Prometheus + Grafana 可观测性容器栈)
  • ✓ 具备 sudo 权限的 SSH 访问能力

核心技术结论 (Key Takeaways)

核心摘要
  • 01 使用 mpstat -P ALL 1 10 与 vmstat 1 监控 %st(CPU Steal 窃取时间):配备独享 AMD EPYC 物理核心的 Netcup Root Server 通常保持在 0.0%–0.3%,而共享 vCore 的 VPS 实例在母机高负载爆发期可能会出现短暂波动。
  • 02 通过 iostat -xz 1(观察毫秒级 r_await 与 w_await)以及非破坏性的只读测试 ioping -RD -c 20 / 评估存储健康度,切勿在线上生产环境频繁运行高写入量的 dd 或 fio 压测以免损耗 NVMe 寿命并挤占业务 IOPS。
  • 03 直接读取 Linux 内核压力停滞信息(cat /proc/pressure/{cpu,memory,io}),在发生系统级 OOM 崩溃或 I/O 假死之前捕获亚秒级的资源争用指标。
  • 04 将 Prometheus (9090)、Node Exporter (9100)、cAdvisor (8080) 与 Grafana (127.0.0.1:3000) 严格隔离在本地回环或内部 Docker 网桥中,通过 SSH 本地端口转发隧道(ssh -L 3000:127.0.0.1:3000)安全访问可视化大盘。
  • 05 结合 vnstat 与 Prometheus 自定义告警规则,持续追踪月度入站/出站流量并守护根分区剩余空间(确保低于 82% 以保障 Netcup SCP 写时复制快照正常创建)。
📑 本文目录导航(共 5 节) ▼
§ 01

第 1 步:诊断 CPU 窃取时间 (%st) 与 Linux 内核压力停滞信息 (PSI)

理解 Netcup VPS(由宿主机 KVM Hypervisor 动态调度的共享 vCore)与 Netcup Root Server(专属于您虚拟机的独享 AMD EPYC 物理核心线程)之间的架构差异,首先要区分 %st(Steal Time,CPU 窃取时间)与 %iowait。CPU 窃取时间衡量的是:您的 Linux 虚拟机内部的某个虚拟 CPU 线程已经处于就绪状态(runnable)在宿主机运行队列中等待执行指令,但底层 KVM 宿主机调度器却将该物理 CPU 核心分配给了同一母机上的其他租户或宿主机内核线程所占用的时间百分比。相比之下,%iowait 则表示您的 vCPU 在当前虚拟机内部处于空闲等待状态,正在等待 /dev/vda 块设备读取或同步 fsync() 写入返回。

除了传统的 mpstat 与 vmstat 工具外,现代 Linux 6.x 内核还在 /proc/pressure/cpu、/proc/pressure/memory 和 /proc/pressure/io 下原生暴露了 压力停滞信息(Pressure Stall Information, PSI)。传统的 1 分钟系统平均负载(Load Average)将 CPU 计算需求与不可中断的磁盘休眠(TASK_UNINTERRUPTIBLE)混为一谈,且极易掩盖亚秒级的延迟尖峰;而 PSI 能够以微秒级精度统计过去 10 秒、60 秒和 300 秒滚动窗口内,进程因等待硬件资源而陷入停滞的真实墙钟时间(Wall-Clock Time)占比。

/proc/pressure/memory 与 /proc/pressure/io 均会输出两行关键数据:some 与 full。其中 some 行代表至少有一个线程因等待内存页回收(Page Reclaim)或 NVMe 磁盘 I/O 而被延迟、但其他线程仍在其他 vCore 上继续执行的时间百分比;而 full 行则代表系统或控制组(cgroup)中所有非空闲任务同时陷入停滞、没有任何计算任务能够向前推进的时间百分比。密切监控 full avg10 与 full avg60,能够在内核触发 OOM Killer 或数据库连接池耗尽前数分钟发出预警。

Netcup VPS 与 Root Server 上的 Linux CPU 及 NVMe 遥测指标健康基线对照表
遥测指标与诊断工具健康基线 (Root Server G12.5)共享型 VPS 正常波动范围告警与架构升级阈值
CPU 窃取时间 (mpstat 中的 %st)0.0% – 0.3%0.2% – 3.5%持续 15 分钟 > 8.0%(建议从 VPS 升级至独享核心 RS)
CPU I/O 等待 (vmstat 中的 %iowait)< 1.0%< 2.5%> 10.0%(使用 iotop 排查并优化 Postgres 检查点)
NVMe 读写响应延迟 (r_await / w_await)0.15 ms – 0.85 ms0.30 ms – 1.80 ms持续 > 8.0 ms(检查块设备队列深度 aqu-sz)
内存压力停滞 (/proc/pressure/memory full avg60)0.00< 0.50> 5.00(严重的内存页交换抖动 / 濒临 OOM 崩溃)
I/O 压力停滞 (/proc/pressure/io full avg60)< 0.20< 1.00> 10.00(存储子系统带宽或 IOPS 达到瓶颈)
安装底层性能诊断工具集并采样多核 CPU Steal (%steal) 与内核 PSI 指标
bash
sudo apt update
sudo apt install -y sysstat iotop ioping vnstat htop btop

# 1. 开启 sysstat 每 10 分钟一次的历史性能归档采集 (/var/log/sysstat)
sudo sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat vnstat

# 2. 以 1 秒间隔连续采样 5 次每个 vCore 的 CPU 利用率与窃取时间 (%steal)
mpstat -P ALL 1 5

# 3. 读取 Linux 内核压力停滞信息(CPU、内存与 I/O 阻塞均值)
head -n 5 /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io

命令与参数详解: 安装并激活 sysstat(包含 mpstat、iostat、sar 历史性能归档)与 vnstat 流量监控守护进程,以 1 秒间隔连续采样所有虚拟核心的 %steal 指标,并输出实时内核 PSI 阻塞均值。

预期终端输出
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

第 2 步:无损测量 NVMe 存储延迟 (iostat & ioping) 与 vnstat 月度流量审计

切勿在正在承载生产业务的 Netcup 服务器上随意运行写入量高达数十 GB 的 fio 或 dd 极限压测脚本来检验磁盘状态——这种破坏性压测会打满虚拟块设备的 I/O 队列,触发宿主机 IOPS 限流器,直接导致线上数据库事务超时。

工程上推荐的无损诊断方法是:使用 iostat -xz 1 观察 Linux 内核块设备驱动层在 /dev/vda 上实时汇总的三项核心指标,而非仅看具有误导性的 %util(在支持多队列并行提交的 virtio-blk/virtio-scsi NVMe 设备上,%util 无法反映队列余量):重点查看 r_await(平均每次读操作耗时,单位毫秒,含队列排队与物理完成时间)、w_await(平均每次写操作耗时,单位毫秒)以及 aqu-sz(平均请求队列深度)。亚毫秒级数值(0.15 ms – 0.90 ms)表明企业级 NVMe 阵列处于健康无争用状态;同时配合 ioping -c 20 -i 0.1 -D / 发起仅 76 KiB 的 4K 直接 I/O(O_DIRECT)探测,即可测出真实的底层存储响应微秒数。

为了在不依赖登录 Netcup SCP 面板的前提下持续审计带宽消耗,我们同时启用 vnstat。其后台守护进程(vnstatd)每 30 秒轮询一次内核 /proc/net/dev 网卡字节计数器,并将统计汇总持久化写入轻量的 SQLite 数据库(/var/lib/vnstat/vnstat.db)中,几乎不消耗任何 CPU 资源,随时可通过 vnstat -d(按天)与 vnstat -m(按月)调阅双向流量报表。

检查 NVMe 块设备队列延迟 (iostat)、无损 Direct I/O 延迟 (ioping) 与 vnstat 流量报表
bash
# 1. 检查块设备扩展 I/O 统计信息(1 秒间隔,连续输出 3 次报告)
iostat -xz 1 3

# 2. 对根文件系统执行 20 次无损 4 KiB 直接 I/O (Direct I/O) 延迟探测
sudo ioping -c 20 -i 0.1 -D /

# 3. 查询 vnstat 持久化记录的最近 5 天及月度网络流量总计
vnstat -d 5
vnstat -m

命令与参数详解: 输出 /dev/vda 虚拟磁盘的毫秒级读写延迟(r_await / w_await)与平均队列深度(aqu-sz),使用 ioping -D 测量绕过缓存的真实 4 KiB 磁盘响应微秒数,并查询 vnstat 持久化的每日与每月流量消耗统计。

预期终端输出
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 的不限流量公平使用政策 (Fair-Use Policy)

Netcup 的 Root Server G12.5 与 VPS G11.5s/G12.5 方案均免费包含不限流量包(Traffic Flatrate)。在配备 2.5 Gbit/s 高速网卡的 Root Server G12.5(RS 500–8000 G12.5)上,若过去 24 小时滚动流量超过 3 TB,系统会将端口临时平滑限速至 300 Mbit/s;在配备 2.5 Gbit/s 网卡的 VPS 500–8000 G12.5 上,若过去 24 小时滚动流量超过 2 TB,则临时平滑限速至 200 Mbit/s;一旦 24 小时流量回落至阈值以下即自动恢复 2.5 Gbit/s 全速,且绝不会产生任何超额流量账单费用。在宿主机内运行 vnstat 能够为您提供一份与 SCP 后台统计图表相互印证的独立流量审计日志。

§ 03

第 3 步:部署加固的 Prometheus + Node Exporter + cAdvisor + Grafana 容器化监控栈

为了在单台 Netcup 服务器上以 15 秒的采样精度保留 30 天的历史性能遥测数据(同时涵盖 Linux 宿主机内核指标与每一个 Docker 容器的资源消耗),我们在 /opt/stacks/monitoring 目录下部署一套四组件监控栈。在 4 GB 或 8 GB 内存的 Netcup VPS(如 VPS 500 G12.5 或 VPS 1000 G12.5)上运行时,有两项关键的参数调优能够防止监控组件自身反过来消耗过多系统资源:

第一,cAdvisor 在默认配置下会以 1 秒一次的高频轮询(Housekeeping)遍历 /sys/fs/cgroup 下的每一个 systemd 切片,并解析每个容器的 /proc/<pid>/net/tcp 套接字表,在运行十几个容器的宿主机上往往会平白消耗 8% 到 12% 的单核 CPU。通过显式传入 --docker_only=true、--housekeeping_interval=15s(与 Prometheus 抓取周期对齐)以及 --disable_metrics=percpu,sched,tcp,udp,diskIO,hugetlb,referenced_memory,可以将 cAdvisor 的 CPU 占用率直接压低至 0.4% 以下,同时完整保留容器核心 CPU、常驻内存(RSS)、工作集内存与网络吞吐指标。

第二,Prometheus TSDB(时间序列数据库)会将实时抓取的样本先缓冲在内存 Head Block 中并顺序追加写入磁盘上的预写式日志(wal/ 目录),随后每满 2 小时将内存数据压缩合并为不可变的磁盘块文件。在 Netcup 的高速 NVMe 存储上,顺序追加 WAL 仅需微秒级时间,但如果不限制保留体积,长期累积的块文件可能逐渐占满小型 VPS 的根分区。同时声明 --storage.tsdb.retention.time=30d 与 --storage.tsdb.retention.size=4GB 可以将单节点监控数据体积稳定控制在约 1.2 GB 左右:

  • ▪ node-exporter (v1.8): 只读挂载宿主机的 /proc、/sys 与 /rootfs,采集并导出宿主机内核指标(包括 CPU Steal %st、/proc/pressure PSI 阻塞指标、NVMe 磁盘 I/O、文件系统容量与网卡流量计数器)。
  • ▪ cadvisor (v0.49): 直接读取内核 cgroupv2 层级树,导出每个独立 Docker 容器的 CPU 占用、常驻内存(RSS)、页缓存(Page Cache)以及网络吞吐指标,并通过 --disable_metrics 关闭高开销冗余采集项。
  • ▪ prometheus (v2.54): 每 15 秒自动拉取(Scrape)上述两个 Exporter 的指标数据,实时评估告警规则,并使用时间序列数据库(TSDB)压缩存储最近 30 天(或最大 4 GB)的历史数据。
  • ▪ grafana (v11.2): 提供可视化分析仪表盘,其端口映射被严格锁定在宿主机回环地址 127.0.0.1:3000 上,确保没有任何一个监控端口暴露在公网扫描器视野中。
/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

命令与参数详解: 编排运行 Prometheus、开启了 --collector.pressure PSI 采集器的 Node Exporter、经过 --housekeeping_interval=15s 降载调优的 cAdvisor,以及严格绑定在 127.0.0.1:3000 上的 Grafana。

安全与生产运维提示: 请注意,prometheus (9090)、node-exporter (9100) 与 cadvisor (8080) 均未声明任何宿主机 ports: 映射——它们仅在隔离的 mon_internal 容器网桥内部通信,阻断了未授权的外部数据抓取。

§ 04

第 4 步:编写 Prometheus 抓取配置与针对 Netcup 架构的专属告警规则

接下来创建 /opt/stacks/monitoring/prometheus/prometheus.yml 与 /opt/stacks/monitoring/prometheus/alerts.yml。由于三个采集组件共享同一个 mon_internal 内部 Docker 网桥,Prometheus 可以直接通过容器服务名(node-exporter:9100 与 cadvisor:8080)完成内网拉取,无需经过宿主机端口映射。

我们在告警规则中专门针对影响 Netcup 服务器稳定运行的四大核心风险设定了 PromQL 阈值:根分区磁盘使用率超过 82%(预留充足的未分配空间以确保 Netcup SCP 写时复制快照能够正常创建)、CPU Steal 窃取时间持续 10 分钟超过 10%、NVMe 磁盘读取延迟超过 12 ms,以及宿主机可用内存低于 10%。

/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"]

命令与参数详解: 配置 Prometheus 以 15 秒间隔通过内部 Docker 网桥抓取自身、Node Exporter 与 cAdvisor 的实时遥测指标。

/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 }}"

命令与参数详解: 定义专为 Netcup KVM 实例量身定制的 PromQL 告警规则:涵盖 CPU 窃取时间 >10%、根磁盘占用 >82%(保护 CoW 快照余量)、/dev/vda NVMe 读取延迟 >12ms 以及宿主机可用内存 <10%。

§ 05

第 5 步:启动监控栈、导入大盘并配置 Grafana Unified Alerting 推送通道

启动整个可观测性容器栈后,无需在防火墙上打开任何额外端口,直接在您的本地办公电脑终端上建立一条加密的 SSH 本地端口转发隧道(-L 3000:127.0.0.1:3000)。在本地浏览器打开 http://localhost:3000 登录 Grafana 后,添加 http://prometheus:9090 作为默认数据源,随后一键导入社区经典仪表盘 ID 1860(Node Exporter Full,完整展示宿主机 CPU Steal、PSI 与磁盘延迟)以及 14282(cAdvisor Docker Insights,展示所有容器的实时内存与 CPU 曲线)。

可视化图表只有在配备主动告警推送时才能真正防范夜间故障。进入 Grafana v11 左侧菜单的 Alerting -> Contact points(联系点),配置您的外部通知渠道——例如填入 Telegram Bot API Token 与 Chat ID、Slack/Discord Webhook 地址,或配置外部事务型 SMTP 发信参数——随后在 Alert rules 中开启对 Prometheus 数据源告警规则的接管(或直接将上方 alerts.yml 中的 PromQL 表达式配置为 Grafana 托管告警规则,设置 1m 评估周期与 5m 持续触发窗口)。这样一旦夜间日志暴涨导致 /dev/vda1 使用率突破 82% 或容器发生内存泄漏,您的手机将在第一时间收到附带具体指标数值的告警推送。

启动监控容器栈并通过本地 SSH 隧道连接 Grafana
bash
# 1. 在您的 Netcup 服务器上:后台启动监控容器栈
cd /opt/stacks/monitoring
sudo docker compose up -d
sudo docker compose ps

# 2. 在您的本地笔记本电脑/工作站上:建立指向 3000 端口的 SSH 加密隧道
ssh -N -L 3000:127.0.0.1:3000 adminuser@203.0.113.10
# 随后在本地浏览器中打开 http://localhost:3000 即可安全访问

命令与参数详解: 在 Netcup 宿主机上后台启动 4 容器监控栈,并在本地工作站上通过 SSH 隧道将本地 3000 端口直接安全映射至服务器回环地址上的 Grafana 容器。

常见故障排查方案

排障手册

[故障现象] 在空闲的 Netcup VPS 上,cadvisor 容器却持续占用 8%–12% 的 CPU 资源

根本原因: 在默认参数下,cAdvisor 会以 1 秒的高频率遍历宿主机上的每一个 systemd 切片(Slice),并采集高开销的每核 CPU、TCP/UDP 套接字状态以及调度器统计信息。

解决方案: 如本文第 3 步所示,在 compose.yaml 中为 cAdvisor 显式传入 --docker_only=true、--housekeeping_interval=15s 以及 --disable_metrics=percpu,sched,tcp,udp,diskIO,hugetlb,referenced_memory,即可将其 CPU 占用率立刻降至 0.5% 以下。

[故障现象] Grafana 仪表盘 1860 显示根磁盘使用率为 100%,或者列出了数十个 /var/lib/docker/overlay2 挂载点

根本原因: 在容器内运行的 Node Exporter 未正确指定 --path.rootfs=/rootfs,或者抓取了 Docker 容器的 overlayfs 联合挂载层。

解决方案: 确认已为 node-exporter 传入 --path.rootfs=/rootfs 与 --collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/),并在 PromQL 查询中通过 fstype!~"tmpfs|overlay" 过滤虚拟文件系统。

[故障现象] 刚安装完 vnstat 后执行查询报错 Not enough data available yet

根本原因: vnstatd 守护进程在首次安装时刚刚初始化其 SQLite 数据库,默认每 5 分钟才将内核网卡计数器刷新写入磁盘一次。

解决方案: 运行 systemctl status vnstat 确认服务处于 active (running) 状态,并通过 vnstat --iflist 核对主网卡名(eth0 或 ens3)。若需立即观察实时带宽速率,可直接运行 vnstat -l。

[故障现象] Prometheus 容器启动失败并报错 open /prometheus/queries.active: permission denied

根本原因: Prometheus 官方镜像默认以非特权用户 UID 65534 (nobody) 运行,若您使用了手动创建的宿主机绑定挂载目录(属主为 root:root),容器将无权写入数据。

解决方案: 优先使用 Docker 命名卷(prom_data:/prometheus,Docker 会自动处理目录属主初始化),或者手动将宿主机目录属主修改为 65534:sudo chown -R 65534:65534 /path/to/prometheus/data。

常见问题解答 (FAQ)

权威解答

在 Netcup VPS 与 Netcup Root Server 上,正常的 CPU Steal (%st) 百分比分别是多少?

在 Netcup Root Server(如 RS 1000 G12.5、RS 2000 G12.5)上,由于底层 AMD EPYC 物理核心是专属于您的实例独享的,%st 通常常年保持在 0.0% 到 0.3% 之间。而在 Netcup VPS(如 VPS 500 G12.5 或 VPS 1000 G12.5)上,虚拟核心在租户间动态共享,日常出现 0.5%–3.5% 的窃取时间完全正常;但如果您的业务高峰期持续出现超过 8%–10% 的 %st,则说明您的计算密集型负载非常适合升级至 Root Server。

Netcup 官方的服务器控制面板 (SCP) 是否也提供宿主机层面的监控图表?

是的。登录 Netcup SCP 后台并进入 Statistics(统计信息) 标签页,您可以直接查看由母机 Hypervisor 采集的 CPU 利用率、磁盘读写 IOPS 以及月度入站/出站流量历史图表。不过,SCP 无法透视虚拟机内部的进程级内存占用、Docker 容器 cgroup 上限、PostgreSQL 慢查询或 /proc/pressure PSI 阻塞指标——因此将 SCP 宏观图表与实例内部的 Node Exporter + Grafana 结合使用才是完整的生产级方案。

这套包含 4 个容器的 Prometheus + Grafana 监控栈本身会消耗多少内存和磁盘空间?

得益于本文第 3 步中的 cgroupv2 配额限制、cAdvisor 指标精简以及 15 秒抓取间隔,整个四容器监控栈(prometheus + node-exporter + cadvisor + grafana)在日常运行时的总内存占用仅为 280–360 MB,完整保留 30 天历史指标仅消耗约 1.2 GB 的 NVMe 磁盘空间。

除了使用 SSH 隧道,我可以将其通过 HTTPS 子域名公开暴露访问吗?

可以。您可以将 grafana 容器接入您的 Caddy 或 Nginx 反向代理网络,配置一个专属子域名(如 metrics.example.com),确保环境变量 GF_USERS_ALLOW_SIGN_UP="false" 保持关闭以禁止陌生人注册,并配合高强度密码、双因素认证(2FA)或客户端 IP 白名单进行访问控制。

参考资料 // 官方技术文档与核验来源

延伸阅读 // 核心架构评测与买前必读

领取优惠码 →