這和 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%、記憶體緊張、目標下線），否則您只會在出事之後才去看圖。