这和 Uptime Kuma 有什么不同？

Uptime Kuma 回答的是“它还在线吗？”。Prometheus 和 Grafana 回答的是“它为什么慢、从什么时候开始的？”：CPU、内存、磁盘、网络和应用指标随时间的变化。很多人两者都用：Kuma 负责故障告警，Grafana 负责趋势分析和容量规划。

Prometheus 要用多少磁盘？

压缩后每个样本约 1–2 字节。十台服务器、每台导出一千个序列、每 15 秒采集一次，一天大约 6000 万个样本，约 100 MB。按默认的 15 天保留期，总共几个 GB。

能监控 NAT 套餐上的服务器吗？

能，但不是靠拉取：NAT 服务器不接受指向其 exporter 的入站连接。在 NAT 机器上以 agent 模式运行 Prometheus，用 remote_write 把指标推送到你的监控服务器。监控服务器本身应该放在带独立 IP 的套餐上。

监控服务器该用哪个套餐？

Micro-IP（2 GB 内存，每月 $10）可以轻松监控一两打主机。如果你加入高基数的应用指标，或要保留几个月的数据，就换成 Small-IP。独立 IP 让 Grafana 能用 HTTPS，也给你一个可以在被监控端加入白名单的固定地址。

监控服务器应该和被监控的机器分开吗？

应该。如果 Grafana 就跑在刚刚耗尽内存的那台服务器上，你会在最需要的时候失去对问题的可见性。一台单独的小 VPS 在生产机器倒下时仍能继续工作。

用 Grafana + Prometheus 监控服务器的 VPS

把所有服务器的 CPU、内存、磁盘和服务指标汇集到一处：在一台 VPS 上、HTTPS 之后运行 Prometheus、node_exporter 和 Grafana。

“服务器很慢”是一份毫无用处的故障报告，除非你能打开一张图，看到内存在崩溃前连续三天不断上涨。这正是 Prometheus 和 Grafana 能给你的：每台服务器的 CPU、内存、磁盘和网络，每 15 秒记录一次，并绘成可以往回翻看的图表。把它们放在一台专门的小 VPS 上，即使生产机器倒下，它们也会继续盯着。

组成部分

node_exporter：在你想观察的每台服务器上运行，通过 9100 端口暴露系统指标。
Prometheus：在监控 VPS 上拉取（scrape）这些指标并存储。
Grafana：放在 HTTPS 之后的仪表板。
可选的 Alertmanager 或 Grafana 告警，在指标越过阈值时给你发消息。

你需要准备

Micro-IP（每月 $10，2 vCPU、2 GB 内存、25 GB）可以监控一两打服务器。主机更多、有自定义应用指标或要保留几个月数据的话：选 Small-IP。
监控服务器需要一个独立 IPv4：Grafana 通过 HTTPS 提供服务，被监控端也可以只为 9100 端口放行一个固定地址。

1. 在每台被监控机上安装 node_exporter

apt install -y prometheus-node-exporter
# allow only the monitoring server to scrape it
ufw allow from 203.0.113.10 to any port 9100 proto tcp

把 203.0.113.10 换成你监控 VPS 的地址。千万别让 9100 对全世界开放：它会泄露大量关于你服务器的信息。

2. 在监控 VPS 上部署 Prometheus 和 Grafana

apt update && apt install -y docker.io docker-compose-v2 caddy
mkdir -p /opt/monitoring && cd /opt/monitoring

cat > prometheus.yml <<'EOF'
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: nodes
    static_configs:
      - targets: ['198.51.100.21:9100', '198.51.100.22:9100']
EOF

cat > compose.yml <<'EOF'
services:
  prometheus:
    image: prom/prometheus
    volumes: [ "./prometheus.yml:/etc/prometheus/prometheus.yml:ro", "prom:/prometheus" ]
    command: [ "--config.file=/etc/prometheus/prometheus.yml", "--storage.tsdb.retention.time=15d", "--web.enable-remote-write-receiver" ]
    ports: [ "127.0.0.1:9090:9090" ]
    restart: unless-stopped
  grafana:
    image: grafana/grafana
    volumes: [ "grafana:/var/lib/grafana" ]
    ports: [ "127.0.0.1:3000:3000" ]
    restart: unless-stopped
volumes: { prom: {}, grafana: {} }
EOF

docker compose up -d

在 Grafana 前面加上 HTTPS：

echo 'grafana.example.com {
    reverse_proxy 127.0.0.1:3000
}' > /etc/caddy/Caddyfile && systemctl reload caddy

登录（admin / admin，然后修改密码），在 http://prometheus:9090 添加 Prometheus 数据源，再导入社区仪表板 “Node Exporter Full”（ID 1860）。大约一分钟，你就有了一个完整的系统仪表板。

NAT 套餐上的服务器

NAT 服务器只在其专属 SSH 端口上接受入站连接，所以 Prometheus 无法拉取它的 exporter。那就反过来：在 NAT 机器上以 agent 模式运行 Prometheus，把数据推送到监控服务器，而监控服务器已经在接受远程写入（上面的 --web.enable-remote-write-receiver 参数）。

# /etc/prometheus/agent.yml on the NAT server
scrape_configs:
  - job_name: self
    static_configs: [ { targets: ['127.0.0.1:9100'] } ]
remote_write:
  - url: https://prom-push.example.com/api/v1/write

通过 Caddy 加上 basic auth 暴露这个推送端点，而不是直接裸开 9090 端口。

坦诚的说明

Prometheus 是拉取式的：非常适合你掌控的一组服务器，对 NAT 后面的一切则很别扭，所以才需要 agent 这个办法。它的本地存储并不是为多年历史设计的；需要长期保留时，以后再加远程存储。而且仪表板只占价值的一半：第一天就至少设置三条告警（磁盘超过 85%、内存紧张、目标下线），否则你只会在出事之后才去看图。