美国VPS监控怎么配

一、先想清楚：监控是给谁看的

配监控之前，先回答一个问题：这套监控是给谁看的。这决定了配置复杂度、告警方式和成本。

给一个人看的（个人站长、单人开发者）：目标是「机器出问题时我能在半小时内知道」。配置可以极简，重点是外部探针加一条告警通道。这类配置的成本几乎为零，差别只在你愿不愿意每两个月检查一次探针本身是否还活着。

给一个小团队看的（2 到 5 人）：目标是「出问题时先有人认领，再排查」。除了探针，还要有值班表、告警分级、升级路径。多数人是在这一步放弃的，因为配置告警比配置服务本身更累。

给一个业务看的（有收入、有用户）：目标是「在用户投诉之前就发现」。这需要监控从「机器存活」升级到「业务健康」，指标要从 CPU、内存扩展到接口成功率、下单链路、证书有效期。

不管你是哪一种，有一个原则是通用的：监控的第一职责是发现「用户能感知到」的问题，第二职责是发现「将来会变成用户能感知到的问题」。第三位的「CPU 有点高」基本可以忽略。

这里要区分两类监控，这是整篇文章的地基：

查 spinservers 在售套餐与库存

关键认知：内部采集在机器宕机时会跟着一起消失，所以它永远不能单独构成一套监控。必须有一个部署在别处的外部探针。这句话决定了后面所有配置。

二、必须监控的指标与数字阈值

监控项不该凭感觉列。每个监控项都必须满足三个条件：能对应到用户能感知的影响、有明确的告警数字阈值、拿到告警后知道该做什么。

下面这张表是完整的基础监控清单，阈值都写成了数字：

zenlayer 官网机型与实时报价

这些阈值不是通用标准，是起步值。第一次配完以后要跑一两周的基线，观察你的机器正常运行时这些数字分别是多少，再据此调整。阈值设得比正常值还低，告警就永远在响；设得比正常值还高，告警就永远不会响。

关于为什么数字阈值如此重要：一句「内存有点高」没法判断，更没法判断该不该半夜起床。只有「连续 5 分钟内存大于 85%」才能被程序判断、被自动化处理、被写进复盘报告。

一个容易被忽略的点：内存阈值要用「连续 N 分钟」而不是瞬时值。 内存的瞬时峰值再正常不过，你的服务进程被 fork 一次就会瞬间多占几百 MB。瞬时阈值一定会产生大量误报。

另一个点：磁盘要同时监控容量和 inode。 磁盘还剩 40% 但 inode 用满是真实会发生的事故，典型场景是日志文件被删掉了但进程还持有句柄，inode 不释放。这时候 df 显示空间充足，但一个文件都写不进去。

三、外部探针：机器挂了还能报警的那一层

外部探针是整套监控里最重要的一层，因为它是唯一在目标机器完全宕机时还能发出告警的东西。

最省事的做法是用第三方免费探针。 这类服务的免费额度通常足够覆盖个人站点的需求，配置方式是填一个 URL 和检查间隔。检查间隔建议设在 60 秒，理由是：间隔太长你发现问题会晚，间隔太短会受对方服务波动影响，而且免费额度往往按次数计费。

自己搭外部探针的做法，核心是用 curl 抓三个时间点：

#!/bin/bash
# 最简可用性探针：测 DNS、连接、首字节、总耗时
TARGET="https://your-site.com"
LOG="/var/log/probe.log"

# -w 里的变量含义：
#   time_namelookup  DNS 解析耗时
#   time_connect     TCP 连接建立耗时
#   time_starttransfer 收到第一个字节的耗时（TTFB）
#   time_total       整个请求耗时
OUT=$(curl -s -o /dev/null -w "%{http_code} %{time_namelookup} %{time_connect} %{time_starttransfer} %{time_total}" "$TARGET")
CODE=$(echo "$OUT" | awk '{print $1}')
TTFB=$(echo "$OUT" | awk '{print $4}')
TOTAL=$(echo "$OUT" | awk '{print $5}')

if [ "$CODE" != "200" ]; then
  echo "$(date -Iseconds) DOWN http=$CODE" >> "$LOG"
  # 这里接入你的告警通道
  curl -s -X POST "https://your-webhook-url" -d "msg=站点不可用 http=$CODE"
  exit 1
fi

# TTFB 超过 0.8 秒也要告警，但用不同的消息等级
if (( $(echo "$TTFB > 0.8" | bc -l) )); then
  echo "$(date -Iseconds) SLOW ttfb=${TTFB}s total=${TOTAL}s" >> "$LOG"
fi
echo "$(date -Iseconds) OK ttfb=${TTFB}s total=${TOTAL}s" >> "$LOG"

探针要放在不同的网络位置。 只在你自己电脑上跑探针没有意义，你的电脑本身可能断网、可能在公司网络后面、可能在运营商劫持的环境里。至少要覆盖两类位置：一类在境外（美国或欧洲的机器上，能反映海外访客的体验），一类在国内（反映国内访客的体验）。如果只有一台美国机器，可以在免费第三方探针里同时勾选多个地区的节点。

查 goodlyclouds 在售套餐与库存

免费第三方探针的一个坑：它测的是探针到你站点的路径，包含探针服务商的调度。 所以探针报慢的时候，要用第二层（自己机器上的 curl）交叉验证，区分是站点真的慢还是探针网络慢。

四、内部采集：CPU、内存、磁盘的采集与阈值

内部采集负责发现那些「还能访问但已经不健康」的状态。核心指标是内存、磁盘、inode 和负载。

最轻量的方案是 node_exporter 加一个文本文件收集器：node_exporter 暴露指标在 9100 端口，采集端用 curl 定时抓取并解析。

# 抓 node_exporter 的三个关键指标
curl -s http://127.0.0.1:9100/metrics | grep -E "^(node_memory_MemAvailable_bytes|node_filesystem_avail_bytes|node_load1) "

内存告警的正确算法是用 MemAvailable 而不是 MemTotal - MemFree。区别在于 MemAvailable 估算的是「在当前不触发 swap 的前提下还能分配多少」，它扣掉了缓存但保留了可回收的部分。而 MemTotal - MemFree 会把缓存也算成占用，导致几乎所有 Linux 机器都长期显示「内存使用率 90% 以上」。

# 计算真实内存使用率（MemAvailable 口径）
TOTAL=$(awk '/MemTotal/{print $2}' /proc/meminfo)
AVAIL=$(awk '/MemAvailable/{print $2}' /proc/meminfo)
USED_PCT=$(awk "BEGIN{printf \"%.1f\", (1-$AVAIL/$TOTAL)*100}")
echo "内存使用率 ${USED_PCT}%"

# 磁盘使用率与 inode 使用率（两个都要看）
df -h / | awk 'NR==2{print "磁盘已用 "$5}'
df -i / | awk 'NR==2{print "inode 已用 "$5}'

判断标准：内存连续 5 分钟大于 85% 告警，交换空间使用量大于 0 且持续 10 分钟告警，磁盘使用率或 inode 使用率任一大于 80% 告警。

为什么内存要用 MemAvailable 口径再配持续时间。 原因有两个：一是上面说的缓存误判；二是服务的内存使用是锯齿形的——高峰上去、低峰下来。如果按瞬时峰值设阈值，一台健康的机器会每天告警几次；如果按平均值设阈值，泄漏的进程会被平滑掉，等发现时已经吃满了。

swap 的告警逻辑值得单独说。 swap 使用量大于 0 本身不一定是坏事（内核把冷内存换出去是正常行为），但「持续 10 分钟不为 0」意味着系统确实在缺内存。更可靠的判据是看 vmstat 的 si/so 列（swap in / swap out）持续非零。

sakuraclouds 官网机型与实时报价

# 看 si/so 是否持续非零
vmstat 1 5 | awk 'NR>2 && ($7>0 || $8>0) {print "正在换页: si="$7" so="$8}'

五、告警噪音治理：告警一多就等于没有

监控体系失败最常见的原因不是没配，而是告警太多，团队开始无视。这叫告警疲劳，比没有监控更危险，因为它给人虚假的安全感。

治理原则：一条告警必须对应一个明确的处置动作。 如果收到告警后你不需要做任何事（因为它会自动恢复、或者它不值得半夜处理），那它就不该是告警级别，应该是记录级别。

具体做法有四层：

第一层，恢复后才通知。 持续 3 次失败才报警，恢复后再发一条「已恢复」消息。这是最重要的一条，能消掉绝大部分网络抖动导致的误报。

第二层，维护窗口静默。 计划内的重启、升级、迁移期间不要报警。

# 维护窗口静默的典型写法：改一个静默标记文件
echo "1" > /var/run/monitoring_silenced
# 维护结束后
rm -f /var/run/monitoring_silenced

第三层，按严重度分级。 至少分三级：

查看 serverfield 当前月价与库存

第四层，定期清理。 每月花半小时看一遍告警统计，把一个月内没有触发过、或者触发后没人处理的规则关掉或调整阈值。

这条规则为什么这么重要，可以算一笔账。假设你配了 20 条监控规则，其中 15 条是过去三个月一次都没触发过的，另外 5 条每月触发 40 次但每次都能自愈。真正需要人介入的告警混在这 45 次里。也就是说 97% 的告警是噪音，而噪音不会自动消失——它只会让你的阈值越来越松，最后连真问题也一并放过。所以定期清理不是可选项，是监控体系维持信噪比的唯一手段。

告警通道的选择：告警通道的可靠性排序是「电话 > 即时通讯 > 邮件 > 短信」。邮件是最容易被规则过滤掉的，凌晨三点躺在收件箱里的邮件基本等于没有。如果你的站点有真实收入，配置一个能打电话的通道是值得的。

第五层：把告警和处置动作写在一起。 告警消息本身应该包含足够的信息，让人不用登录服务器就能开始排查。至少包含四项：哪个站点或哪台机器、是哪个指标超标、超标到什么数值、过去 30 分钟同指标的曲线。一个合格的四行告警长这样：

[site-a] 磁盘使用率 92%
位置: 10.0.0.5 (us-west-2)
阈值: >80% 持续 15 分钟
趋势: 60 分钟内从 71% 升到 92%
建议: 检查日志目录与备份临时文件

有了趋势那一行，你甚至不用登录就能判断这是缓慢增长（多半是日志没轮转）还是突然跳变（多半是某个任务写爆了）。这两种原因的处理方式完全不同，趋势行把判断时间从五分钟压缩到十秒。

六、证书、流量额度与备份：三类必须提前预警的非性能问题

前面几节监控的是性能。还有三类问题不会让机器变慢，但会直接造成损失：证书过期、流量超额、备份中断。

证书到期监控。 证书过期是典型的「毫无征兆的一次性事故」，而且浏览器会把警告显示给每一个访客。检查命令：

# 查看证书剩余天数
echo | openssl s_client -servername your-site.com -connect your-site.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

# 算剩余天数
END=$(echo | openssl s_client -servername your-site.com -connect your-site.com:443 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
DAYS=$(( ( $(date -d "$END" +%s) - $(date +%s) ) / 86400 ))
echo "证书剩余 $DAYS 天"
[ "$DAYS" -lt 21 ] && echo "告警：证书即将到期"

阈值定在 21 天，是因为自动续期任务偶尔会因为 DNS 验证失败、DNS 服务商接口变更、账户欠费而失败，两到三周的窗口足够你发现并手工处理一次。

流量额度监控。 商品库里的机型都写明了月流量额度，这是硬约束，超了要么被限速要么产生额外费用。监控方法是从网卡计数器累加：

# 累计出站字节（单位 KB）
TX=$(awk '/eth0|ens/{print $10}' /proc/net/dev | head -1)
# 换算成 GB
echo "$TX" | awk '{printf "%.2f GB 已用\n", $1/1024/1024}'

注意网卡计数器是开机以来的累计值，重启会清零，所以要么在重启后从 0 重新算，要么用持久化计数器。

这里可以引入一个真实的算账例子。 拿商品库里的 sixtynet LAX-MEDIUM 举例：年付 800 美元，折合每月 66.67 美元，配置是 8 核、8 GB 内存、160 GB 硬盘、10000 Mbps 带宽、每月 20000 GB 流量。折算下来每 TB 流量成本约 3.41 美元，每 GB 内存成本约 8.33 美元，每 GB 硬盘成本约 0.417 美元。

再看 LAX-LARGE：年付 1600 美元，折合每月 133.33 美元，8 核、16 GB 内存、320 GB 硬盘、10000 Mbps 带宽、每月 40000 GB 流量。单位成本几乎完全一样，每 TB 流量约 3.41 美元，每 GB 内存约 8.33 美元，每 GB 硬盘约 0.417 美元。

这个对比说明什么：这条产品线的扩容是等比例的，流量翻倍时钱也正好翻倍，没有规模折扣也没有溢价。所以监控流量占用的意义不在于「精打细算省一点」，而在于提前知道自己离限速或超额还有多远。流量用量的告警阈值设在配额的 80% 和 95% 两档。

备份任务监控。 备份脚本成功不等于备份可用，中间的静默失败（磁盘满、密码文件丢失、仓库损坏）最常见。监控方式是把退出码和产物大小写进状态文件：

# 在备份脚本末尾
if [ $? -ne 0 ]; then
  echo "failed $(date -Iseconds)" > /var/run/backup_status
  curl -s -X POST "https://your-webhook-url" -d "msg=备份失败 $(hostname)"
else
  echo "ok $(date -Iseconds) size=$(du -sb /backup/latest | cut -f1)" > /var/run/backup_status
fi

查看 干杯cloud 当前月价与库存

再加一个每小时检查状态文件的独立任务，状态不是 ok 就告警。

七、把一套完整监控栈的成本算清楚

监控本身要花钱吗？分四块算。

第一块：外部探针。 第三方免费探针的基础额度通常够个人站点用，成本是 0 美元。付费版一般按探针数或请求次数计费，几十美元一个月能覆盖多个地区多点。自建探针的成本就是你那台跑探针的机器的资源占用。

第二块：内部采集。 node_exporter 本身免费，它占的资源是几十 MB 内存和极少的 CPU，可以忽略不计。存储历史指标才是真正的成本所在。

第三块：历史指标存储。 存储量可以直接算出来。每个指标样本按一条时序算，一条时序每秒一个点，一天的点数是 86400，一个点按 2 字节算，一条时序一天约 173 KB。

查 cubecloud 在售套餐与库存

一台机器上要采的指标通常在 200 到 500 条之间，取 300 条算：保留 30 天约 1.6 GB，保留 90 天约 4.7 GB。用商品库里最低配的机型当监控机，磁盘都装不下 90 天的历史数据。

拿商品库的真实价格算一下监控机的账：RosCloud-01 是 19.99 美元每月，2 核 1 GB 内存、20 GB 硬盘、500 Mbps 带宽、每月 1024 GB 流量，每 GB 内存成本 19.99 美元、每 GB 硬盘成本约 0.999 美元、每 TB 流量成本约 19.99 美元。它装得下 7 天的历史数据，但 1 GB 内存跑采集加存储加查询会比较紧张。

RosCloud-02 是 29.99 美元每月，3 核 2 GB 内存、40 GB 硬盘、500 Mbps 带宽、每月 2048 GB 流量，每 GB 内存成本 14.99 美元、每 GB 硬盘成本 0.75 美元、每 TB 流量成本约 15 美元。40 GB 硬盘能存约 30 天的数据，2 GB 内存足够跑采集加轻量查询。

结论：如果要自建，用 RosCloud-02 这一档起步，长期留存则需要更大的盘或把历史数据写到对象存储。 而更省事的选择是用云厂商托管的监控服务，把存储成本交给对方。

第四块：告警通道。 消息推送类工具的免费额度通常够用，付费版把短信和电话呼叫纳入，一般几美元到几十美元一个月。

四项加起来，个人站点的完整监控栈可以做到每月 0 美元（第三方免费探针加自采加日志文件告警），做到每月 30 美元以内也很容易（加付费探针和历史存储），做到每月 100 美元以上通常意味着你要的是多节点、拨测、SLO 报告这类企业功能。

八、什么情况下不该自己搭这套监控

这一节按要求说明不适用的场景，依据只讲公开事实——机房位置、线路类型、计费方式、IP 资源，不评价任何商家的好坏。

场景一：机器只用来跑一次性的测试或爬虫任务，挂了也不影响任何人。 这类任务的特征是任务结束就销毁机器，价值随时间衰减。给它配一整套监控加告警，投入的运维时间超过收益。替代方案：用一条 cron 检查任务退出码，失败时发一条消息，甚至只在下次运行时检查上一次的结果，不做实时监控。

场景二：站点是纯静态内容且已经挂在 CDN 上。 静态资源的可用性由 CDN 承担，源站故障时 CDN 仍能返回缓存内容。给源站配高强度实时监控意义有限。替代方案：只保留一个每小时一次的源站存活检查，加上 CDN 侧的可用性监控，因为 CDN 缓存过期后仍需要源站能拉取新内容。

场景三：访客全在境外，且你的业务已经依赖云厂商的负载均衡和自动扩容。 云负载均衡自带健康检查和指标输出，你再自建一套是在重复劳动。替代方案：直接用云监控的告警能力，把阈值配成本文第二节那张表的数字即可。

场景四：预算只够一台最低配机器。 RosCloud-01 这一档是 19.99 美元每月、1 GB 内存、20 GB 硬盘。监控栈本身在这台机器上会挤占业务资源，典型的表现是采集进程和业务进程抢内存触发 swap。替代方案：不要在业务机上装采集，把采集放在另一台便宜机器上，只通过公网拉取业务机的指标端点；或者干脆用第三方托管探针加你手头已有的外部机器。

场景五：你需要的是「打开快」而不是「挂了知道」。 实时告警解决的是故障响应，解决不了性能优化。替代方案：这类需求应该配的是拨测加趋势图（TTFB 每天一个数据点、看 30 天曲线），而不是秒级告警，配置完全不同。

场景六：IP 资源紧张的场景。 有些场景需要多个独立 IP 才能跑（比如多账号运营、爬虫轮换），监控如果需要从多个来源 IP 拨测，IP 成本会被拉高。替代方案：用不同网络位置的免费第三方探针代替自建多 IP 拨测节点。

场景七：机房位置决定了监控要盯哪一条链路。 一台在美西的机器，回国内访客的路径要经过国际出口和骨干网，跳数多、抖动大是线路类型的固有属性，不是配置问题。这种情况下给延迟设一个绝对阈值（比如「TTFB 必须小于 300 毫秒」）会在晚高峰长期误报。替代方案：把 TTFB 阈值拆成两组，一组是「源站自身响应时间」（在服务器本机测，绕开网络，这部分必须小于 300 毫秒），另一组是「端到端 TTFB」（包含网络，阈值按你实测的晚高峰基线设，通常是基线的一到两倍）。这样告警只在源站自己出问题时才响。

查看 zorocloud 当前月价与库存

场景八：计费方式是流量计费的机器，监控本身会消耗配额。 商品库里很多机型按月流量计费，监控系统的采集流量、告警通道的请求、日志上传的流量都从同一个配额里扣。RosCloud-01 每月只有 1024 GB 流量，LAX-STARTER 是 5000 GB，而 LAX-LARGE 有 40000 GB。替代方案：监控流量大时选流量配额宽裕的机型（LAX 系列每 TB 流量成本约 3.41 美元这一档），或者把日志采集降采样到 30 秒一次、把历史数据写到对象存储而不是回传原始数据。

九、给四类人的具体配置方案

结论分成四类人，每类给出可以直接照抄的配置，不写「视情况而定」。

第一类：个人站长、静态博客或单站点。 选 1 GB 内存机型就够，业务本身就轻。配置方案：第三方免费探针一份，检查间隔 60 秒，探针位置至少选两个不同地区；证书到期检查每周跑一次；磁盘使用率用一条 cron 每小时检查，超过 80% 发消息。预算 0 美元。不要装面板，不要装全套 node_exporter，那对你来说是浪费。

第二类：跑 WordPress 或小型电商的中小站长。 需要 2 GB 内存起步。配置方案：在第一类基础上加 node_exporter 做内部采集，重点看 MemAvailable 口径的内存使用率和磁盘 inode；告警分三级，站点不可用是 P1，内存连续 5 分钟大于 85% 是 P2，CPU 短时高峰不告警只记录。预算 0 到 10 美元每月，主要支出是告警通道的付费档和一台放探针的低配机器。

第三类：有真实收入、跑多站点或有后台系统的团队。 需要 4 GB 内存起步。配置方案：内部用完整的指标采集加时序存储，保留 30 天以上；外部探针自己部署在两台不同机房的机器上，位置一境内外；告警通道必须包含电话呼叫这一档；备份任务和流量额度纳入同一套告警看板，每周一出一次周报。监控机可以直接选 LAX-MICRO 或 LAX-STARTER 这类年付机型，每 TB 流量成本约 3.41 美元这一档流量非常充裕，不会在采集自身流量上超限。预算每月 30 到 100 美元。

第四类：面向海外用户、收入规模大、需要对外承诺可用性的业务。 这一类应该直接选云厂商的托管监控和负载均衡，而不是自建。配置方案：用云监控的告警能力，阈值照搬本文第二节的表格；SLO 定 99.9% 时对应每月不可用时间约 43 分钟，把这个数字写进对外条款；自建部分只保留一个异地灾备站点的存活探针。预算每月 100 美元以上。

野草云 官网机型与实时报价

最后三条通用建议：第一，监控配置完成后的第一周每天看一次图，第二周开始只看告警，第三周开始只信告警不看图——这是让告警成为唯一入口的标准做法。第二，任何告警都要在处理后写一行处置记录，三个月后你会发现哪类问题最常发生。第三，监控的阈值要在每次扩配置后重新校准一次，机器规格变了，旧的阈值就失效了。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 spinservers 当前机型与价格
• 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 zenlayer 当前机型与价格
• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 goodlyclouds 当前机型与价格
• 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 sakuraclouds 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、常见问题

问题一：监控装在自己电脑上可以吗？ 不可以。电脑会关机、会切网络、会被系统更新打断，只能当临时排查工具。至少要有一份部署在目标机器之外的监控。

问题二：node_exporter 端口要不要限制访问？ 要。9100 端口暴露在公网等于把所有指标公开。建议绑定内网地址，或者用防火墙只允许采集端 IP 访问。

问题三：为什么我的 CPU 使用率经常 90% 以上却没人抱怨？ 因为 CPU 是共享核，百分比高不代表慢。判断慢不慢要看延迟指标（TTFB、接口耗时），不看使用率。

问题四：告警发到微信或邮件，收不到怎么办？ 检查通道服务的每日发送额度，很多工具在超额后静默丢弃。至少配置两种通道，一种主用一种备用，并定期用测试消息验证链路通。

问题五：监控会不会影响机器性能？ node_exporter 加采集脚本的典型开销是几十 MB 内存和不到 1% 的 CPU。但历史存储进程（数据库）可能吃得多，所以要把存储放到另一台机器上。

问题六：内存一直显示 90% 需要处理吗？ 看 MemAvailable 口径。MemAvailable 充足就不需要处理，那是缓存。真正需要处理的是 MemAvailable 不足且 swap 在持续换页。

问题七：一次配多少个监控项合适？ 起步阶段 10 到 15 个，覆盖第二节表格里的 P1 和 P2 项就够。监控项越多，告警噪音越大。先跑一个月，再按实际需要加。

问题八：怎么判断我现在的监控是够用的？ 做一次故障演练：把目标机器重启或把防火墙规则改错，看多久收到告警、多久有人开始处理、恢复后多久收到恢复通知。这三个数字是监控体系的真实指标。

问题九：监控数据能存多久？ 取决于磁盘和保留策略。按第二节之前的算账，300 条时序保留 30 天约需 1.6 GB，保留 90 天约需 4.7 GB。历史数据超过 90 天的价值很低，通常只做汇总统计后删除原始数据。

问题十：不同地区部署探针，告警怎么避免重复？ 用去重规则：同一根因在短时间内的多条告警合并成一条，附上受影响的探针位置列表。