一、韩国VPS监控到底要盯哪些指标
先说结论：盯四个数就够了，其余都可以往后放。 很多人买韩国VPS之后第一反应是装一堆监控 Agent，结果 Agent 自己把内存吃掉了三分之一，真正出事的时候还没收到告警。监控的第一原则是「少而准」，不是「多而全」。
第一类是可用性，也就是「这台机器还在不在」。 表现形式有三种：ping 不通、HTTP 探测返回非 200、以及 SSH 端口连不上。这三个必须分开监控，因为它们指向的故障完全不同。 ping 通但 HTTP 挂，说明机器活着但 Web 服务或 PHP 崩了；HTTP 返回 200 但 SSH 连不上，说明是防火墙或 SSH 配置的问题，不是机器宕机。只盯 ping 的话，Web 服务全挂了你的告警不会响。
第二类是延迟，具体拆成首字节时间和完整下载时间两个数。 首字节时间反映的是「用户点下去到看到第一帧」，这是体验差异最大的地方；完整下载时间反映的是带宽是否被占满。韩国节点的优势在于地理距离近，这两个数应该落在很低的区间，一旦出现持续性的抬升，说明线路或者负载出了问题。
第三类是资源水位，主要是内存、磁盘和 CPU。 内存是最容易出事的一个，因为它有非线性效应：内存吃满会触发 swap，swap 一开磁盘 IO 飙升，磁盘满了网站直接挂。磁盘是唯一一个「不可逆」的，内存涨了可以重启释放，磁盘涨了是数据本身变多，不清理就永远占着。
第四类是证书和服务的有效期。 这一类最容易被忽略，也最容易造成大面积故障。 HTTPS 证书过期、域名过期、备份保留期到了自动删除旧备份——这三种事的共同点是：它们不会产生任何异常流量，只会在某一天突然让整站不可用。
| 监控类别 | 具体指标 | 数值阈值 | 不达标时的第一动作 |
|---|---|---|---|
| 可用性 | HTTP 状态码探测 | 连续 3 次非 200 即告警 | 查 Nginx 错误日志最后 50 行 |
| 可用性 | SSH 端口连通 | 连续 3 次超时即告警 | 查防火墙规则和 sshd 状态 |
| 延迟 | 首字节时间 TTFB | 大于 300ms 持续 5 分钟 | 查 PHP-FPM 队列与数据库慢查询 |
| 延迟 | 下载 1MB 耗时 | 大于 2s 持续 5 分钟 | 查带宽占用与出站流量 |
| 资源 | 内存使用率 | 谷值高于 15% 需处理 | 查进程排行，定位泄漏 |
| 资源 | 磁盘使用率 | 高于 80% 需处理 | 查大文件与日志轮转 |
| 有效期 | HTTPS 证书剩余天数 | 少于 30 天提醒 | 签发新证书并 reload |
这张表就是你的验收标准表，也是本文的核心。 下面几节分别把它拆开讲：阈值为什么是这些数、每台机器的监控成本怎么算、噪音怎么消、以及什么情况下这套方案对你是浪费。
二、阈值怎么定：为什么是300毫秒和2秒
上一节的数字不是拍脑袋来的，每一个都对应一个「用户会做判断」的时间点。 监控阈值定得没道理，告警就变成装饰。
首字节 300ms 是怎么来的。 浏览器发起到收到第一帧，用户的主观等待感知分三段：100ms 以内感觉「秒开」；100 到 300ms 能接受；超过 300ms 会开始怀疑页面坏了。 这个 100ms 和 300ms 是人机交互研究里反复出现的分界点，不是网络行业的玄学。所以 300ms 定成「持续超标就告警」是合理的——单次抖动不代表问题，但连续 5 分钟都超，说明有稳定的瓶颈。
1MB 下载 2 秒的逻辑是把它折算成带宽。 1MB 除以 2 秒等于 4Mbps。换句话说，2 秒这条线，测的其实是「这段时间里你实际能拿到 4Mbps 以上的有效速率」。 韩国节点面向的主要是国内访客，4Mbps 这个数对应的是「一个普通页面（HTML 加 CSS 加 JS 加图片，通常 1MB 上下）能在两秒内下完」。
内存谷值 15% 这条要解释一下「谷值」。 谷值不是峰值，是「一段时间内的最低点」。为什么看最低点而不是平均值？因为内存泄漏的表现恰恰是：平时（谷值）越来越低，一旦被高峰流量压上去，就再也回不来了。 如果只看平均值，泄漏早期会被业务高峰掩盖过去，等你发现时已经是 OOM。谷值高于 15% 意味着「最闲的时候也有 15% 内存被非业务进程占着」，这是排查内存泄漏最灵敏的指标。
磁盘 80% 这个数字来自写入放大。 你以为磁盘还够，其实不是——日志、数据库 binlog、临时文件都在持续写入，而且这些写入量往往比你想的大。 从 80% 到 100% 的过程里，数据库可能因为无法扩展写入而卡死，业务直接停摆。留 20% 是给写入和临时空间留的余量。
证书剩余 30 天提醒，是因为续签流程本身要时间。 你要签发新证书、验证域名归属、reload Nginx、验证生效——这一套走完通常要几天，而且中间可能遇到验证服务不稳定。 30 天提醒加上 15 天二次提醒，基本能覆盖任何一次验证失败后的重试窗口。
最后一条：所有阈值都必须是「持续多久」而不是「单次」。 上面表格里每一行都带时间窗口，单次超标只能记录，不能告警。这是整套阈值设计里最重要的一条纪律，也是下一节要解决的问题。
三、告警噪音怎么消：只有持续超标才算数
监控系统的死亡方式是「告警太多」，不是「告警太少」。 一天收到三百条告警，和一天收到零条告警，实际效果是一样的——你都会忽略它。
噪音的三个主要来源，每一个都有对应的处理办法。
第一个来源是瞬时抖动。 一次网络重传、一台机器正好在跑备份、一次数据库的自动维护，都会让某个指标瞬间越线几秒钟。处理办法是给每条告警加一个「持续时间」条件，比如「内存高于 80% 且持续 10 分钟」。代价是发现延迟变大——你会在 10 分钟后才收到告警，而不是立刻。 这个代价通常值得付，因为真故障持续不止 10 分钟。
第二个来源是探测点本身的问题。 你的监控服务从某个机房往外探测，探测线路出问题时，所有被监控的机器会同时报警，看起来像是集体宕机。这个要用「多探测点 + 一致性判断」来治：至少两个独立探测点同时报才算真故障，只有一个探报错就归到「探测异常」。
第三个来源是告警风暴。 一台机器的数据库连不上，会同时触发「HTTP 探测失败」「应用健康检查失败」「依赖服务告警」三条通知，而且往往是同一分钟。这个要用「告警聚合」来治：把同一台机器在同一时间窗口内的所有告警合并成一条，其余变成折叠项。
| 噪音来源 | 典型表现 | 处理办法 | 代价 |
|---|---|---|---|
| 瞬时抖动 | 单次指标越线几秒 | 加持续时间条件，如持续 10 分钟 | 发现延迟增加 10 分钟 |
| 探测点故障 | 全部机器同时报警 | 至少两个独立探测点一致才算数 | 需要双倍探测资源 |
| 告警风暴 | 同一分钟收到多条同类告警 | 同机器同窗口告警聚合 | 需要配聚合规则 |
还有一个容易被忽略的噪音源：阈值定得太紧。 如果你把「首字节大于 300ms」设成告警线，那么任何一次访客从欧洲访问你的韩国节点都会触发一次。这不是故障，这是业务本身。 阈值必须按「你的主要访客在哪」来定，而不是按「理论上最好能到多少」。
判断噪音是否已经控制住，有一个简单标准：告警的「有效率」。 如果一周内收到的告警里，有一半以上需要人工判断「其实没问题」，说明阈值太紧或者持续时间条件太短。正常状态下，健康的机器应该让监控系统处于完全安静的状态。 一个安静的系统和一个不停叫的系统，可靠性是一样的——因为后者最终会被屏蔽。
四、监控成本怎么算：每台机器每月留多少预算
这一节给具体数字。 监控成本分三块：Agent 占用的资源、监控服务本身的订阅、以及外部探测的流量。
先算 Agent 占的资源。 常见的轻量 Agent（Prometheus node_exporter 类）常驻内存大致在 20 到 40MB 之间，CPU 占用在空闲时低于 1%。按 1GB 内存的机器算，Agent 吃掉 40MB 就是总内存的 4%；按 2GB 算就是 2%。 这就是为什么本文第一节说「别装一堆 Agent」——装五个，每个 40MB，在 1GB 机器上就是 200MB，占 20% 内存，直接触发你刚才设定的 15% 谷值告警线。 讽刺的是，监控自己触发了自己的告警。
再算监控服务订阅。 自建 Prometheus 加 Grafana 加 Alertmanager 这套开源栈，硬件成本可以压到很低，但它的真实成本是人力：一台 1GB 机器跑这套组件本身就很勉强，通常需要单独准备一台 2GB 以上的机器专门跑监控。按 VPS 市场里 2GB 内存机型的大致价格区间，这台「监控机」的月成本大致等于你被监控机器总成本的十分之一到五分之一。 也就是说，如果你只监控 1 到 2 台机器，自建监控在经济上是不划算的，用托管服务更合适。
最后算外部探测的流量。 外部探测要从站外拉你的页面，这是真实消耗你的出站流量的。一次完整的页面探测通常会下载整个页面，按 1MB 算。 如果你的监控服务每分钟探测一次，一天就是 1440 次，一个月就是 43200 次乘 1MB，也就是 42GB 左右的流量消耗。 拿这个数字去对照套餐流量包：
| 机器档位 | 月价（美元） | 内存 | 磁盘 | 月流量 | 每 GB 内存单价 | 监控占用流量占比 |
|---|---|---|---|---|---|---|
| RosCloud-01 | 19.99 | 1GB | 20GB | 1024GB | 19.99 | 4.1% |
| RosCloud-02 | 29.99 | 2GB | 40GB | 2048GB | 14.99 | 2.1% |
| RosCloud-03 | 39.99 | 4GB | 80GB | 3072GB | 10.00 | 1.4% |
| RosCloud-04 | 49.99 | 8GB | 160GB | 4096GB | 6.25 | 1.0% |
注意最后两列的关系：机器配置越高，监控流量的占比越低。 在 RosCloud-01 上，每分钟探测一次的监控方案要吃掉你 4.1% 的月流量；在 RosCloud-04 上只要 1.0%。这个结论很反直觉但很重要——配置越高档的机器，监控越便宜。
如果用云途的机型做对比，比例会明显不同，因为它是人民币计价且流量额度更大： 云途 HK.DS.M 每月 350 元，32GB 内存、480GB 硬盘、1000Mbps 带宽、月流量 10000GB，超额流量重置价 200 元。按每分钟探测一次算，42GB 流量占它月额度的 0.42%。 同一套监控方案，在这两家身上的流量成本占比差了将近十倍。
怎么用这张表做决策？算一个叫「监控流量占比」的数：你的月流量额度除以探测次数。 如果这个数超过 1%，就要把探测频率从每分钟降到每 5 分钟；如果降到每 5 分钟你还嫌告警太慢，那说明你需要的是更好的探测点，而不是更高的频率。
具体的调整公式：每天的探测次数等于探测间隔的分钟数的 1440 倍。 每分钟一次是 1440 次，每 5 分钟一次是 288 次，流量占用直接降到五分之一。 288 次探测对于「首字节是否异常」这种判断依然足够。
五、告警发到哪里：通道选择和响应时间
监控的最后一环是「人多久能知道」。 指标采集得再准，告警发到没人看的地方，等于没监控。
常见的告警通道有五类，按响应速度排序：
| 通道 | 典型到达时间 | 适合什么级别的告警 | 局限 |
|---|---|---|---|
| 电话语音 | 30 秒内 | 站点完全不可用 | 费用最高，不能滥用 |
| 短信 | 1 分钟内 | 核心服务中断 | 按条计费，长文本要截断 |
| 即时通讯机器人 | 1 到 3 分钟 | 资源水位、水位告警 | 可能被折叠到静音分组 |
| 邮件 | 5 分钟内 | 证书到期、趋势类告警 | 容易被当垃圾邮件 |
| Webhook 集成 | 取决于你的工单系统 | 需要人工介入的流程 | 需要自己搭接收端 |
一个实用的分级原则是：不可用的告警用最吵的通道，可用水位用安静的通道。 站点完全挂掉的时候打电话，没人接才是问题；磁盘到了 80% 这种还没到危险线的事，发封邮件就够了。把两类混在一起，接收者很快会对所有通知脱敏。
再定响应时间。 每一级告警都要写清楚「多久没人处理就升级」：
- P0（服务不可用）：15 分钟未确认，自动升级到电话。
- P1（功能异常但可用）：1 小时未处理，升级到短信。
- P2（水位偏高、证书临近到期）：一个工作日未处理，升级到邮件。
「确认」不等于「解决」。 收到告警的人点一下「已知」，P0 的计时器就停——这样你得到的是「有人看到了」这个保证，而不是「有人修好了」。 至于修复另设一个工单追踪。
还有一个容易被忽略的细节：告警要带上下文。 一条只写「host-01 内存 87%」的通知，你会花两分钟去猜是哪台机器、哪个业务。一条写「host-01（韩国首尔 / 商城站）内存 87%，已持续 12 分钟」的，你立刻知道该找谁。 上下文成本为零，收益极高。
最后是静默规则。 计划内维护必须静默，否则你会在凌晨两点被自己的重启脚本吵醒——而收到告警却发现是自己干的，这是最消耗信任的事情。 静默规则要用标签匹配，比如「计划维护」标签下的主机在静默窗口内不告警。
六、外部监控怎么选：自建、托管还是混合
这一节给一个明确的选择路径，不要在「自建还是用现成的」之间反复纠结。
先按被监控机器的数量分界。这个数量直接决定了自建的硬件成本占比。
1 到 3 台机器：用托管服务。 理由很直接——托管服务按台订阅，你付的钱和你的机器数量成正比；而自建你要额外养一台机器，不管你监控一台还是十台。 在数量少的时候，托管的单位成本一定更低。这和上一节的流量逻辑是一致的：规模不够，自建摊不薄。
4 到 20 台机器：托管服务加自建采集器的混合模式。 具体做法是：在被监控的机器上只装轻量 Agent 采集数据，把数据推到一台托管的时序数据库，你自己的机器上跑 Grafana 做展示和告警规则。这样你既省掉了「存储和查询」这块最重的基础设施，又保留了告警规则的自定义能力。 按每 GB 内存单价从 19.99 美元降到 6.25 美元的档位梯度看，这个区间的机器总成本已经足够支撑一台专用监控机。
20 台以上：自建全套。 有了规模，Prometheus 加 Grafana 加 Alertmanager 加时序数据库这套栈的固定成本被摊薄，而且规模越大，自建的边际成本越接近零。 此时的收益不只是省钱，还有数据不出网的合规价值。
| 被监控机器数 | 推荐方案 | 理由 | 月成本量级 |
|---|---|---|---|
| 1 到 3 台 | 全托管服务 | 自建固定成本无法摊薄 | 按台订阅，通常几美元起 |
| 4 到 20 台 | 混合模式 | 托管存储加自建告警规则 | 一台专用监控机加少量订阅 |
| 20 台以上 | 全自建 | 边际成本接近零 | 一台监控机加大容量存储 |
不管选哪种，有一件事必须做：外部探测点必须独立于被监控机器。 如果探测程序跑在你自己被监控的那台机器上，那么机器挂掉的时候，探测也一起挂了，你会收到「一切正常」而不是告警——这是监控系统最经典的自杀式故障。 至少要有一个探测点跑在不同的机房、不同的网络里。
关于数据保留期，也要算一笔账。 保留 15 天的原始数据，配 5 分钟粒度，一天是 288 个采样点，每台机器一天就是 4320 个点。这个数据量对单台机器很小，但机器一多就不可忽略。 常见的做法是原始数据保留 15 到 30 天，之后降采样成每小时一个点保留一年。降采样这一步能砍掉 95% 以上的存储量，而对于「看趋势」这个用途来说，一小时粒度完全够用。
最后一个选型要点：确认它支持韩国节点的外部探测。 很多托管监控服务的免费探测点在境外，如果你的站是面向国内访客的，探测数据反映的是境外视角。要选能指定探测区域或者提供国内探测节点的服务，否则你测出来的延迟和你的真实用户感受对不上。
七、外部监控之外，本机自监控怎么装
外部监控能告诉你「站点挂了」，但不能告诉你「为什么快挂了」。 这两件事需要分开做。
外部监控和本机监控的分工是这样： 外部监控负责「用户视角是否正常」，本机监控负责「内部资源水位如何」。两者缺一不可：只有外部监控，你的站点可能已经变慢到不可用但还没挂；只有本机监控，Agent 自己挂了或者机器断网了你都不知道。
本机监控的部署方式，按复杂度从低到高有三档：
第一档，用系统自带的工具，不装任何 Agent。 Linux 上的 vmstat、iostat、free、ss 这些命令都在。你完全可以用一个简单的 cron 脚本每隔几分钟把这些数字记到日志里，然后在脚本里做阈值判断。 这种方式几乎零资源占用，对 1GB 机器最友好：
#!/bin/bash
# 每分钟记录一次关键水位，超阈值写进告警日志
LOG=/var/log/monitor.log
MEM=$(free -m | awk '/Mem:/ {print $3/$2*100}')
DISK=$(df -h / | awk 'NR==2 {gsub("%","",$5); print $5}')
LOAD=$(awk '{print $1}' /proc/loadavg)
echo "$(date '+%F %T') mem=${MEM}% disk=${DISK}% load=${LOAD}" >> $LOG
# 超过 80% 记一条告警，交给外部脚本或 cron 任务处理
if (( $(echo "$MEM > 80" | bc -l) )); then
echo "$(date '+%F %T') WARN mem=$MEM% host=$(hostname)" >> /var/log/alert.log
fi注意这段脚本里没有尖括号。 用 bc -l 做浮点比较比 shell 内建更稳，也避免了重定向符号被误解析。
第二档，装轻量 Agent，把数据推到远程。 这是上一节说的混合模式里被监控端要做的事。关键是要限制 Agent 的资源上限，否则它会成为被监控对象自己最大的负载源。
第三档，装完整栈。 Prometheus 抓取加 Exporter 加 Grafana 展示，能力最强但需要足够资源。在 1GB 机器上不要试，会直接把机器拖垮。
| 方案 | 资源开销 | 能力 | 适合的机器档位 |
|---|---|---|---|
| shell 脚本加 cron | 内存占用接近零 | 只有水位记录和阈值判断 | 1GB 内存的入门档 |
| 轻量 Agent 推远程 | 约 20 到 40MB 内存 | 有历史数据和多维度指标 | 2GB 及以上 |
| 完整 Prometheus 栈 | 数百 MB 内存 | 有完整查询和告警规则 | 4GB 及以上 |
本机监控还有一个容易被忽略的用途：它能发现外部监控发现不了的问题。 典型的三个是：磁盘 inode 用尽（明明还有空间却写不进去）、文件描述符耗尽（连接数上不去）、进程数超限。这些在外部探测里全都表现为「站点变慢」，但根因完全不同，只有本机数据能区分。
排查 inode 用尽的命令是：
# 查看 inode 使用率，满了会出现 No space left on device 但 df 显示还有空间
df -i /
# 查看当前打开的文件描述符数量
ss -s
# 查看进程数
ps -eLf | wc -l最后一条纪律：本机监控的 Agent 必须限制自己的重启频率。 一个配置写错的 Agent 如果每次崩溃都自动重启，会变成一个持续消耗 CPU 和 IO 的元凶——而这正是你刚才设定的 CPU 告警会捕捉到的现象。 给 Agent 加上退避重启策略，别让它变成噪音源。
八、什么情况下不该配这套监控
这一节讲的是反面：什么情况下上面这套是浪费。 依据只讲公开事实——机房位置、线路类型、计费方式、IP 资源，不评价任何商家好坏。
第一种情况：你的机器连访问量都还没有。 如果一台 1GB 内存的机器只跑一个静态页面，日均访问量几十次，那你需要的监控只是「Cron 定时跑一次 curl 看状态码」，不需要时序数据库、不需要 Grafana、不需要多探测点。 上整套系统的成本远超收益。
第二种情况：你的计费方式让流量变得敏感。 按流量计费的机器上，外部探测的流量是真金白银。按第四节算出来的数字，每分钟探测一次在 RosCloud-01 上要吃掉 4.1% 的月流量，在按 GB 计费且单价不低的方案上，这个比例是需要认真对待的。 这种情况下应该把探测间隔拉到 5 分钟以上，或者让探测点只请求一个不加载静态资源的小页面。
第三种情况：你在做的是一次性的临时任务。 如果这台机器的用途是跑个两小时的压测、验证一个部署方案，那监控的价值几乎为零——因为你会在任务结束后直接销毁它。 这种场景用本地脚本记日志就够了。
第四种情况：你的业务对延迟极度敏感，但你在用按月固定流量的套餐。 这里有个容易忽略的矛盾：如果你的套餐给了 1000Mbps 甚至更高的带宽，但月流量额度很小，那说明你买的是「突发大带宽、小流量」的类型，适合短时大流量传输，不适合持续的网页服务。 这种情况下监控应该重点看带宽占用峰值和流量余量，而不是延迟。
第五种情况：你有更可靠的上游。 如果你的站点挂在有 SLA 保障的托管平台上，那么「服务不可用」这一类告警上游已经覆盖了，你自建监控的边际价值只剩「内部资源水位」这一小块。这时候把监控范围缩到资源水位，砍掉外部探测，能省下 42GB 流量和大部分配置工作。
| 不该配的场景 | 原因 | 替代方案 |
|---|---|---|
| 日访问量几十次的静态站 | 监控系统的固定成本远超收益 | Cron 加 curl 脚本，每 5 分钟一次 |
| 按流量计费的入门档套餐 | 探测流量占月额度比例过高 | 探测间隔放宽到 5 分钟以上 |
| 一次性临时任务 | 用完即销毁，没有连续性价值 | 本地日志文件即可 |
| 突发大带宽小流量套餐 | 监控重点和套餐特性不匹配 | 改看带宽峰值和流量余量 |
| 已有 SLA 上游的平台 | 可用性告警重复覆盖 | 只保留资源水位监控 |
最后提醒一句： 判断该不该配监控，看的不是「技术上能不能配」，而是「配了之后有没有人会看」。一个没人看的告警系统，不管多精确，都是在消耗你的内存、流量和注意力。 先想清楚告警发给谁、多久处理一次、谁来兜底，再决定配多复杂的方案。
九、值班流程怎么定：谁来接告警
监控配置得再好，如果没人接告警，它依然是个空转系统。 这一节讲流程。
第一步，把告警分级和响应时限写成一页纸。 这一页纸要贴在你每天能看到的地方。内容只有三列：告警级别、谁负责、多久内必须响应。 举例：
| 级别 | 触发条件 | 负责人 | 响应时限 | 超时升级 |
|---|---|---|---|---|
| P0 | HTTP 探测连续失败 | 当班运维 | 15 分钟 | 电话呼叫负责人 |
| P1 | 内存持续超限 | 当班运维 | 1 小时 | 短信通知负责人 |
| P2 | 证书剩余不足 30 天 | 值班主管 | 1 个工作日 | 邮件抄送主管 |
第二步，做一次真实的故障演练。 演练的意思是：你主动把网站关掉，看告警多久到、到没到、收到的人多久确认、确认后多久恢复。 这个过程的真实结果经常和纸面计划差很远——最常见的问题是「告警发到了一个没人负责的群」或者「确认按钮在手机上找不到」。
# 演练：临时停掉 Web 服务，触发 P0 告警
sudo systemctl stop nginx
# 观察告警到达时间与确认时间
# 恢复
sudo systemctl start nginx第三步，定「无人在岗」时怎么办。 半夜的 P0 怎么办？可选方案就三个：认领轮值（有人拿固定的钱）、自动响应（写脚本做常见故障的自愈）、或者明确接受「夜间响应慢」并写下来。 关键不是选哪个，而是必须明确选一个并写下来。没有写下来的默认状态是「大家以为有人管，实际上没人管」。
第四步，给常见故障准备自愈脚本。 最有价值的两个自愈场景是「磁盘写满」和「服务进程挂了」：
# 服务挂了自动拉起（放到 crontab，每分钟检查一次）
* * * * * systemctl is-active nginx || systemctl restart nginx注意这个自愈的前提是你已经排查过「为什么会挂」。 如果根因是内存不足或者磁盘写满，重启只会让问题循环出现，而循环重启本身会掩盖真实的告警信号。 自愈脚本只能用在「原因明确、重启即可恢复」的场景。
第五步，每季度做一次告警复盘。 统计三个数：这个季度收到多少条告警、其中多少条是真问题、多少条是噪音。噪音占比持续超过一半，就说明阈值需要重调。 复盘的目标不是追责，是让告警系统重新变得可信——一个大家开始忽略的告警系统，等于没有告警系统。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 justg 当前机型与价格
- 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 vpckr 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十、上线前必须跑完的六项验收
最后给一张可以直接照着做的验收清单。 买完机器、装完监控、按下第一个告警之前，把这六项逐条跑完，每条都要留下实际数字。
| 验收项 | 操作 | 合格标准 | 留存的证据 |
|---|---|---|---|
| 可用性探测 | 连续 7 天外部探测成功率 | 不低于 99.5% | 探测报表截图 |
| 首字节延迟 | 白天与晚高峰各测 20 次 | 中位数小于 300ms | 20 次实测数据 |
| 下载速度 | 下载 1MB 耗时测 20 次 | 中位数小于 2s | 20 次实测数据 |
| 内存谷值 | 连续 24 小时记录 | 谷值不高于 15% | 24 小时曲线 |
| 磁盘余量 | 观察 7 天增长率 | 30 天内不会到 80% | 增长曲线 |
| 告警链路 | 主动触发一次 P0 | 15 分钟内有人确认 | 告警时间戳 |
这六项里，前五项的合格标准就是本文第二节那张阈值表，原样搬过来即可。 唯一需要你自己定的是第六项的响应时限，取决于你的人员配置。
「30 天内不会到 80%」这一条要解释一下怎么算。 方法是看 7 天的磁盘增长量，然后线性外推 30 天。注意日志类文件往往是阶跃式增长的——可能平时每天只涨几十 MB，但某天某个任务开始写大日志，一天就涨掉几个 GB。 所以线性外推要留余量，我的建议是按实测增长率的 1.5 倍来估。
还有一件必须做的事：把这张表打印出来，贴在机器旁边或者存成一份文档。 验收标准的价值在于「所有人都用同一把尺子」。如果只有你自己知道阈值，那么每个来接手的人都要重新问你一遍，这套体系就没有沉淀下来。
最后，把验收结果和机器配置一起存档。 记录这台机器是什么配置、什么线路、验收时各项实测值是多少。半年后你要扩容或者换机器时，这份记录就是唯一可靠的依据—— 而不是你现在的印象。
流程到这里就闭环了： 第二节的数字是判断标准，第四节和第六节是成本和规模的决策依据，第八节划出不该配的边界，第九节保证告警有人接，第十节给出可以签字的验收清单。把这六节连起来读，你的韩国VPS监控系统就不会是一个开完就忘的配置。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
