香港VPS监控怎么配

一、监控到底在监控什么：四个必备指标和两个易漏项

监控不是装个工具看曲线。一套有效的 VPS 监控只回答四个问题：服务还活着吗、变慢了吗、资源要耗尽了吗、有什么马上会坏掉。

第一是存活，也就是服务是否还在正常响应。这个指标最简单，但也最容易被做成「无效监控」——很多人监控的是「进程还在不在」，而进程在但服务返回 502 的情况监控不出来。存活监控必须从外部发起，用真实的 HTTP 请求验证，而不是在机器内部检查自己。

第二是延迟，具体是首字节时间和完整响应时间。延迟是比可用性更早的信号：一个接口从 50ms 涨到 3 秒，通常发生在彻底挂掉之前几小时甚至几天。

第三是资源水位，包含 CPU 使用率、内存可用量、磁盘占用率和 inode 使用率。这四个必须同时监控，缺一样都会漏掉一类故障。 典型例子：磁盘空间没满但 inode 用完了，MySQL 照样无法写入；CPU 一直很低但内存耗尽，进程会被 OOM Killer 直接杀掉，而且日志里看不到任何异常。

第四是流量，包含月流量累计和带宽峰值。这是 VPS 特有的监控项，普通服务器监控方案里通常没有。理由很直接：流量超额会导致限速或者额外计费，而这个故障在监控上表现为「变慢」，你去查 CPU 和内存都正常——因为问题在链路上。

两个最容易漏掉的项： 一是证书到期时间，二是日志量异常增长。前者会在某天早上让你发现全站打不开，后者往往是磁盘被写满的第一个信号。

还要区分「指标」和「信号」。 CPU 使用率是一个指标，它告诉你现在的状态；而「磁盘占用率在过去 6 小时里每小时上升 3 个百分点」是一个信号，它告诉你正在发生什么。只有信号的监控才是能提前预警的监控，单纯的指标快照只能告诉你「现在坏了」，而你要的是「快要坏了」。

怎么把指标变成信号？ 三个可用的手法。第一是变化率阈值：不看绝对值，看单位时间的变化量，比如「磁盘占用率日增速超过 5%」。第二是持续时间：同一个条件连续满足 N 分钟才告警，滤掉瞬时尖峰。第三是多指标组合：磁盘 80% 是正常的，但如果同时「磁盘 80% 且过去 24 小时有超过 100 次写失败」，那才是真正的风险。单指标告警会产生噪音，多指标组合告警才产生信号。

另外要注意指标的绝对值会骗人。一台 128GB 内存的机器用了 8GB，CPU 用了 3%，看起来非常空闲——但如果这台机器本来只需要跑一个静态站点，那 8GB 内存可能意味着有东西在泄漏。百分比阈值适合跨机器比较，而绝对值阈值适合发现异常。 两种都要设。

数脉科技 官网机型与实时报价

# 存活检查：从外部发起，返回非 0 就告警
curl -fsS -o /dev/null -w "HTTP %{http_code} %{time_total}s\n" https://你的站点/health

# 延迟检查：分三次取样，避免单次抖动误报
for i in 1 2 3; do
  curl -o /dev/null -s -w "TTFB %{time_starttransfer}s TOTAL %{time_total}s\n" https://你的站点/
  sleep 2
done

# 资源水位：四个必须一起看
top -bn1 | grep "Cpu(s)" | head -1
free -m | awk '/Mem:/ {printf "可用内存 %dMB / 共 %dMB\n", $7, $2}'
df -h / | awk 'NR==2 {print "磁盘已用", $5}'
df -i / | awk 'NR==2 {print "inode 已用", $5}'

# 把指标变成信号：记录磁盘占用的小时级变化趋势
for h in $(seq 1 6); do
  echo "$(date +%H:%M) $(df / | awk 'NR==2 {print $5}')"
  sleep 3600
done

二、为什么必须装外部监控，内部监控救不了你

这是整篇最重要的一节。很多 VPS 用户的监控是装在机器内部的 Agent，这个架构有一个致命缺陷：机器挂了，监控也一起挂了。

具体来说有五种故障是内部监控抓不到的：

第一种是整机宕机或者被宿主机强制迁移。 机器断电、宿主机故障、云平台把你的实例迁到另一台物理机上——这些情况下你的监控 Agent 进程根本没机会发告警。

第二种是网络层故障。 机器活着、进程活着，但网络不通：机房线路故障、路由异常、防火墙规则把流量全拦了、或者你的 IP 被上游拉黑了。这类故障从机器内部测是测不出来的，因为内部测试走的还是那条已经坏了的路径。

第三种是证书到期或者 DNS 解析被改。 你的服务在 127.0.0.1 上响应正常，但外面访问不了——因为证书过期了，或者域名解析指向了别的 IP。外部监控从公网发起，用真实的域名访问，才能发现这类问题。

第四种是磁盘满了导致数据库写入失败。 服务进程还在、端口还在监听，但业务已经无法写入数据。外部监控如果只检查 HTTP 状态码可能还是 200，得靠检查一个真正会写入的接口。

第五种是机房层面的问题。 商家的宿主机维护、整个机柜断电、带宽被掐——你的机器状态在控制台里可能还显示「运行中」。

所以原则很清楚：外部监控是必须的，内部监控是补充。 外部监控从第三方节点发起，用公网域名访问，检查真实业务路径；内部监控负责提供更细的资源曲线和日志，两者结合才完整。

外部监控的搭建门槛比想象中低。业界通用的做法是选一个第三方拨测服务，注册后拿到一个监控地址，在上面配置三件事：HTTP 状态码检查、响应时间阈值、证书到期检查。这三项配置完成，你的监控就具备了基本的可靠性。

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

# 证书剩余天数：低于 30 天就该告警
echo | openssl s_client -servername 你的域名 -connect 你的域名:443 2>/dev/null \
  | openssl x509 -noout -enddate
# 更直接的写法：输出剩余天数
DAYS=$(( ( $(date -d "$(echo | openssl s_client -servername 你的域名 -connect 你的域名:443 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)" +%s) - $(date +%s) ) / 86400 ))
echo "证书剩余 $DAYS 天"

三、告警噪音：一个总在响的监控系统等于没有监控

这是监控系统失败最常见的方式，不是没配，是配得太吵。 半夜被三条无关消息吵醒，两周之后你会开始无视所有告警——包括那条真正重要的「数据库连接失败」。噪音不会让你更安全，它只会训练你忽略告警。

告警噪音的来源通常有三个，而且都可以定量控制。

第一个来源是阈值设得太紧。 比如 CPU 超过 70% 就告警。但业务高峰期 CPU 常态就在 80%，那这条规则每天都在响。正确的做法是设「持续时间」而不是设「瞬时阈值」——CPU 连续 5 分钟超过 90% 才告警，而不是瞬间超过一次就报。瞬时尖峰几乎不预示故障，持续异常才是。

第二个来源是缺少基线。 同一台机器，凌晨 3 点和晚上 8 点的资源使用完全不同。用同一套阈值覆盖所有时段，必然有一半时间是噪音。 解决办法是按时段设置阈值，或者用「相对基线偏离度」告警——比过去 7 天同时段的平均值高出 50% 才报。

第三个来源是告警粒度太粗。 一台机器的磁盘超限，应该报「磁盘」这件事，而不是把每个相关进程都报一遍。一条告警应该对应一个可执行的处置动作。 如果一条告警收到之后你不知道该做什么，它就是噪音。

给告警定级的标准很简单，按处置的紧急程度分三级：

级别	含义	通知方式	响应时限	举例
P0 紧急	服务不可用	电话 + 短信	15 分钟	站点完全打不开、数据库连不上
P1 重要	即将不可用	短信 + 邮件	2 小时	磁盘 85%、证书 7 天后到期、月流量 90%
P2 提示	需要关注	邮件	下个工作日	内存使用率持续偏高、日志增长异常

查 isvoro 在售套餐与库存

关键原则：P0 和 P1 才配短信，P2 只发邮件。 通知渠道越多不代表越可靠，每多一个渠道，就多一次你忽略它的机会。

# 用 deadsnakes 风格的自定义脚本做一次简单告警判断（放进 cron）
cat > /usr/local/bin/check_vps.sh <<'EOF'
#!/bin/bash
LEVEL=0; MSG=""
DISK=$(df / | awk 'NR==2 {gsub("%","",$5); print $5}')
MEM=$(free -m | awk '/Mem:/ {printf "%d", $7/$2*100}')
HTTP=$(curl -o /dev/null -s -w "%{http_code}" --max-time 10 https://你的域名/)
[ "$HTTP" != "200" ] && { LEVEL=0; MSG="$MSG 站点返回 $HTTP;"; }
[ "$DISK" -ge 90 ] && { LEVEL=0; MSG="$MSG 磁盘 ${DISK}%; "; }
[ "$DISK" -ge 85 ] && [ $LEVEL -eq 1 ] && MSG="$MSG 磁盘 ${DISK}%; "
[ "$MEM" -le 10 ] && { [ $LEVEL -eq 1 ] && MSG="$MSG 可用内存 ${MEM}%; "; }
[ -n "$MSG" ] && curl -s -X POST "你的告警webhook" -d "level=$LEVEL&msg=$MSG"
EOF
chmod +x /usr/local/bin/check_vps.sh

四、证书到期：最便宜的故障，也是最常发生的故障

证书过期导致的整站不可用，是所有 VPS 故障里最冤的一种——服务器好好的、配置一个字没改、流量正常，然后某天早上全站打不开，浏览器报「您的连接不是私密连接」。

自动续期解决的是「续期机制」，但有几个坑必须知道。

第一个坑是续期脚本本身依赖的东西会挂。 certbot 的定时器依赖 systemd timer 和网络。如果系统重装过、或者 crontab 被误清、或者机器长期离线导致 timer 被跳过，续期就不会执行。所以续期的正确设计是「到期前主动检查」，而不是「到期当天才发现」。

第二个坑是 DNS 验证和 HTTP 验证的差别。 HTTP 验证（--webroot）要求 80 端口能被公网访问并且路径解析正确；DNS 验证需要域名有 API 权限，可以给任意域名签发。如果你的站点在 80 端口上有跳转、或者有 CDN 拦截，HTTP 验证可能一直失败。 验证失败不会立刻报错，它只是在日志里写一行然后等下次重试——很多天后你才发现证书早就过期了。

第三个坑是续期之后 Nginx 没 reload。 certbot 续期成功只是更新了证书文件，Nginx 还拿着内存里的旧证书在跑。必须配置 deploy hook 让续期后自动 reload。

第四个坑是证书链不完整。 某些签发机构提供的中间证书没有被自动配置，导致部分设备（尤其是手机端和某些国产浏览器）报证书错误，而电脑浏览器正常。用 openssl s_client 验证完整链条是必做动作。

# 检查证书链条完整性，-showcerts 会输出所有中间证书
echo | openssl s_client -servername 你的域名 -connect 你的域名:443 -showcerts 2>/dev/null \
  | grep -E "^ [0-9] s:|^ [0-9] i:"

# certbot 续期演练（--dry-run 不会真的改证书）
sudo certbot renew --dry-run

# 确认 deploy hook 已配置：续期后自动 reload
sudo grep -r "nginx" /etc/letsencrypt/renewal-hooks/deploy/ 2>/dev/null

查看 joysol 当前月价与库存

监控上怎么配：证书剩余天数设三个告警点——30 天（P2 邮件）、14 天（P1 短信）、7 天（P1 短信）。 30 天的那个不是提醒你赶紧续，而是提醒你去测一遍续期流程，因为等到 7 天再测就来不及了。

五、月流量和带宽监控：VPS 独有的那部分

普通服务器监控方案不监控流量，但 VPS 必须监控，因为流量超额是 VPS 特有的直接计费型故障。

三个数字要分开监控，含义完全不同。

月流量累计值，用来判断会不会超额。阈值建议设在额度的 80% 和 95% 两档。80% 的时候你还有时间优化，95% 的时候你要么加购要么限速。

带宽峰值，用来判断有没有被打或者有没有跑满。峰值持续在带宽上限的 90% 以上，说明要么是流量型攻击，要么是某个进程在做大量下载。 正常业务不会长期跑满。

流量的日环比，用来发现异常增长。正常业务的流量曲线是相对平稳的，如果某一天是前一周平均的 3 倍，要么是业务增长（好事），要么是某个进程在往外发数据（坏事）。这个环比指标比绝对值更容易发现「数据泄露」这类问题。

带宽峰值怎么测需要注意一点：如果你用 iftop 或者 nload 这种基于抓包的工具，在千兆口上会带来可观的开销，而且它自己不会算进流量统计。生产环境更适合用读取网卡计数器的轻量方式。

# 读取网卡累计收发字节（不抓包，开销极小）
cat /proc/net/dev | awk 'NR>2 {split($1,a,":"); if (a[1]!="lo") printf "%-10s 收 %10.2f GB  发 %10.2f GB\n", a[1], $2/1073741824, $10/1073741824}'

# 实时带宽速率（读 /proc 差值，不抓包）
awk 'BEGIN{printf "实时速率: %.2f Mbps\n", 0}' 
cat /proc/net/dev | awk 'NR>2 {split($1,a,":"); if(a[1]!="lo") printf "%s %.2f Mbps\n", a[1], $2*8/1e6/60}'

# 按连接数排查谁在占带宽（取前 10）
sudo ss -tnp state established | head -20

# 找出流量最大的进程（用 nethogs 或 bmon，不要用 iftop 全量抓包）
sudo nethogs -c 2 -t 2>&1 | head -20

tmhhost 官网机型与实时报价

关于限速这件事必须提前知道：不同服务商的超额处理方式差别很大，有的直接降到很低的带宽，有的按 GB 计费，有的直接停机。这个规则是你在买机器时就要问清楚的，不是出事之后才知道。 香港节点的具体超额规则和报价以官网当日报价为准，下单前一定要找到那一条写明。

六、日志和磁盘增长的监控：磁盘被写满的提前预警

磁盘写满是最常见的 VPS 事故，而且它的原因通常不是「数据变多了」，而是某个日志在没人注意的时候一直增长。典型来源有三个：访问日志没有轮转、数据库的 binlog 没清、或者某个进程在往一个临时文件里疯狂写。

监控磁盘要用两个指标，不是一个。 空间占用率 df 反映的是字节数，inode 使用率 df -i 反映的是文件数量。大量小文件（比如几百万个缓存文件）会先撑爆 inode，而 df -h 还显示着一半空间没满。 这种情况你会看到 MySQL 报「磁盘空间不足」但 df -h 显示还有很多空间，非常难查。

日志轮转要配三样东西：大小限制、保留份数、压缩。 只配 logrotate 是不够的——logrotate 默认按天轮转，一台被疯狂访问的机器一天能写出几十 GB 的日志，按天轮转等于一天产生几十个几十 GB 的文件。

数据库 binlog 一定要配过期清理。 MySQL 的 binlog 默认可能永久保留，它记录的是所有写操作，一个频繁写入的库，binlog 增长速度可以远超你的想象。

# 磁盘和 inode 双监控
df -h / | awk 'NR==2 {print "空间已用:", $5}'
df -i / | awk 'NR==2 {print "inode 已用:", $5}'

# 找出最大的日志文件
sudo du -ah /var/log/ 2>/dev/null | sort -rh | head -10

# 日志目录总量（比单文件更实用的告警对象）
sudo du -sh /var/log/ | cut -f1

# 检查 binlog 体积和过期情况
du -sh /var/lib/mysql/*bin* 2>/dev/null
mysql -u root -p -e "SHOW BINARY LOGS;"

# 配置 binlog 7 天过期（写进 my.cnf 后重启生效）
# expire_logs_days=7

# 慢查询日志的大小（数据库出问题时它会异常增长）
sudo du -sh /var/lib/mysql/*slow* 2>/dev/null

告警阈值建议：空间 80% 和 90% 两档，inode 80% 一档。 空间到 90% 必须有人当天处理，因为备份、日志轮转、数据库临时文件都需要空闲空间。

还要监控日志文件本身的数量和年龄。 一个更实用的做法是设一个「日志目录总大小」的上限告警，而不是逐个文件去盯。理由是日志目录的总量比单个文件的大小更能反映问题，而且你不需要为每个日志文件配一条规则。

数据库这块要单独说，因为它的增长方式和服务日志完全不同。 访问日志的增长是线性的、可预测的；binlog 的增长是跟写入量走的，一个频繁写入的库，binlog 一天涨几十 GB 完全正常。后果是 binlog 慢慢吃满磁盘，而 binlog 又不能随便删——删早了主从复制会断，删晚了磁盘会满。正确做法是在数据库配置里设置过期时间，让 MySQL 自己清理，而不是手动 rm。

查看 zorocloud 当前月价与库存

还有一个容易被忽略的点：数据库的错误日志和慢查询日志也是会增长的，而且它们增长的时机往往是数据库出问题时——大量慢查询被记录，慢查询日志突然涨几十倍。这时候慢查询日志不但占空间，还会让磁盘更快写满，形成恶性循环。监控慢查询日志的大小，某种意义上是在监控数据库的健康度。

七、告警通道怎么选：到哪里、用什么、发什么

告警发不出去等于没配。这节讲通道选择和投递可靠性。

通道按送达率排序，最可靠的组合是「短信 + 邮件」，最不可靠的是「只在群里发」。 原因很实际：邮件可能在发件方被判为垃圾邮件，IM 消息可能在客户端静默不推送，而短信是唯一一个能在手机静音模式下穿透到锁屏的通道——对于 P0 级别的告警，这是关键差别。

但不要所有级别都用短信。 短信有成本，也会训练你无视它。P2 用邮件、P1 用邮件加短信、P0 用电话加短信，这是合理的分层。

投递可靠性要靠「确认」机制，而不是靠信任。 有效的做法是：P0 告警发出后 5 分钟内没有收到确认，自动升级到下一个渠道；再过 10 分钟没人确认，升级到电话。这需要告警平台支持升级策略。

一定要有「静默期」。 维护窗口、批量部署期间，告警应该被抑制而不是疯狂发送。没有静默期的系统在部署时会产生大量噪音，久而久之整个告警通道都会被忽略。

一定要有告警本身健康度的监控。 监控系统的监控叫 meta-monitoring。 做法很简单：定期（比如每 5 分钟）给监控服务发一个测试告警，确认它真的能送达。这一步经常被跳过，但它能发现「告警服务欠费了」「Webhook 域名过期了」「短信服务欠费了」这类沉默的失效。

告警内容里必须带的四个字段：发生了什么、影响是什么、现在该做什么、状态码是什么。 没有这四项的告警，收到的人还要自己去查，等于把排查工作又做了一遍。举个合格的写法：「磁盘占用率 92%（阈值 90%）。影响：数据库无法写入，站点表单提交失败。处置：执行 runbook-disk-90，清理 /var/log 归档。状态：P1。」

告警里要带上定位信息。 比如是哪台机器、哪个服务、哪个挂载点。「磁盘满了」和「hk-web-01 的 /var 分区满了」是两个完全不同的告警，后者的处置时间可能是前者的十分之一。

还要有一条「恢复通知」。 告警在问题解决之后应该自动关闭，并且发一条恢复消息。这条恢复消息比告警本身更被需要——半夜被叫醒之后，最想知道的是「好了没」而不是「还在不在」。恢复消息的设计能让值班的人安心去睡觉，而不用一直盯着监控面板。

查看 backwaves 当前月价与库存

# meta-monitoring：每 5 分钟发一次测试心跳到告警通道
cat > /usr/local/bin/heartbeat.sh <<'EOF'
#!/bin/bash
curl -s -X POST "https://hc-ping.com/你的UUID" > /dev/null
EOF
chmod +x /usr/local/bin/heartbeat.sh
# 用 cron 每 5 分钟跑一次
(crontab -l 2>/dev/null; echo "*/5 * * * * /usr/local/bin/heartbeat.sh") | crontab -

# 带定位信息的告警模板：机器名、服务名、阈值、当前值、runbook 链接
cat > /usr/local/bin/alert.sh <<'EOF'
#!/bin/bash
HOST=$(hostname)
DISK=$(df / | awk 'NR==2 {gsub("%","",$5); print $5}')
if [ "$DISK" -ge 90 ]; then
  MSG="[P1] $HOST 磁盘占用 ${DISK}%（阈值 90%）。影响：数据库写入失败。处置：runbook-disk-90"
  curl -s -X POST "你的告警webhook" -d "text=$MSG" > /dev/null
fi
EOF
chmod +x /usr/local/bin/alert.sh

八、值班流程：半夜被叫醒之后该做什么

监控配得再好，如果收到告警的人不知道下一步该做什么，告警就只是把你从睡眠里叫起来然后让你更沮丧。一个可执行的值班流程需要三样东西：一份 runbook、一条统一的入口、和明确的处置顺序。

第一样是 runbook，也就是针对每种告警类型的处置手册。 它不能是一句「检查服务器」，而应该是具体的命令序列。比如「磁盘 90%」的 runbook 应该是：查磁盘占用排行、查日志文件大小、检查是否有失控进程、按顺序清理、确认服务恢复、记录处理结果。runbook 要写成不懂这个系统的人也能照着做。

第二样是统一的告警入口。 如果 P0 走短信、P1 走邮件、P2 走邮件，而它们又分散在不同通道，那半夜你得在三个地方找信息。最好所有告警都先进一个统一的通道（Webhook 接收后转成一张工单或者一条消息），再按级别分发。

第三样是处置顺序。 半夜被叫醒，正确顺序是：先确认影响面（是全站挂了还是部分功能挂了）、再判断是最近变更导致的还是资源耗尽（看最近的部署记录、内存和磁盘的趋势）、然后执行恢复动作（runbook 里的第一条）、最后做根因记录。顺序不能反——很多人在半夜直接重启，掩盖了证据，故障原因再也查不出来了。

# 第一步：确认影响面——本机能不能访问
curl -o /dev/null -s -w "本机 HTTP %{http_code}\n" http://127.0.0.1/
# 第二步：从外部确认是不是只有你这边的问题
curl -o /dev/null -s -w "外部 HTTP %{http_code}\n" https://你的域名/
# 第三步：判断是不是资源耗尽
free -m; df -h /; uptime
# 第四步：查最近一小时的变更
sudo journalctl --since "1 hour ago" | grep -iE "restart|upgrade|deploy|config" | tail -20

查 digitalvirt 在售套餐与库存

还有一条纪律：恢复优先于定位。 半夜的职责是把服务恢复，不是把根因查清。但恢复过程中要留下证据——重启前先保存 top 输出、df -h、free -m、错误日志尾巴，这些是事后定位的唯一线索。

九、常见误区：这些监控配置看起来在监控，其实在添乱

误区一：在机器内部装监控就以为监控做好了。 见第二节，这是最根本的一个错误。

误区二：阈值设得极其敏感，一有波动就告警。 前面说过，正确做法是「持续时间 + 分级阈值 + 时段基线」。一个每天响十次的监控系统，收到第十一次的时候你不会再看一眼。

误区三：监控了 CPU 和内存，却不监控磁盘和 inode。 磁盘是 VPS 事故的头号原因，而 df -i 这个指标在大多数监控模板里是缺失的。

误区四：只监控存活，不监控延迟。 服务返回 200 但耗时 5 秒，从存活监控的角度看一切正常，但用户已经在抱怨了。延迟是体验的代理指标，必须单独设阈值。

误区五：告警没有分级，所有事情都用同一种方式通知。 结果是重要告警被淹没。

误区六：监控采集本身把机器拖垮。 在低配机器上跑全量抓包、或者开一个高频的全指标采集 Agent，监控进程的 CPU 占用可能达到 5% 到 10%，在 1GB 内存的机器上这足以引发问题。低配机器上要用最轻量的采集方式，只读 /proc 不抓包。

误区七：没有静默期。 每次发版都会产生一批告警，几周之后大家学会了在发版时忽略告警，包括真实的故障告警。

误区八：从来没测试过告警到底能不能收到。 换个手机号、换个邮箱之后没测，或者告警服务欠费了不知道。meta-monitoring 就是解这个的，见第七节。

查看 zgovps 当前月价与库存

误区九：以为装了监控就不需要看日志。 监控告诉你「出问题了」，日志告诉你「为什么」。只有监控没有日志，故障排查会卡在第一步。

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

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

• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 数脉科技 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 野草云 当前机型与价格

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

十、常见问题

免费方案够用吗？ 个人站点和小型业务够用。市面上有基于心跳 URL 的免费拨测服务，也有开源的 Uptime Kuma、Beszel 这类自建方案。自建的好处是数据在你自己手上，坏处是它自己也在被监控的机器上，等于第二节说的那个问题——所以自建监控最好放在另一台机器上。

监控 Agent 装在哪台机器上？ 内部监控 Agent 装在业务机器上，外部拨测服务在第三方节点上。两者都要有，作用不同。 只装内部 Agent 的风险是机器挂了你不会知道；只做外部拨测的风险是看不到资源趋势。

告警发到微信或者钉钉群可以吗？ 可以，但不要只依赖它。群消息会被刷屏淹没，也会在有人换手机或者退群时丢失。 群可以作为辅助通道，但 P0 级别的告警应该走短信或者电话。

多久检查一次比较合适？ 存活和延迟类检查 1 到 3 分钟一次，这是业界常见的频率；证书到期、资源水位、流量这类检查 5 到 15 分钟一次足够；日志分析类可以放到小时级。频率越高，对拨测服务和被监控机器的压力越大，1 分钟一次对大多数站点已经足够。

怎么知道监控自己没坏？ 两个办法：一是第七节说的 meta-monitoring，定期发测试心跳；二是定期做一次「故障演练」——手动关掉你的服务，看告警能不能在预期时间内发到你手上。这个演练每个季度做一次，比任何理论都有用。

监控采集会不会影响网站性能？ 会，但可控。关键是选对采集方式：读 /proc 和系统接口的 Agent 开销在 1% 以下，而基于抓包或高频轮询全量指标的采集方式开销可能到 5% 以上。低配机器上尤其要注意这一点。

监控数据要保留多久？ 至少 90 天。理由是很多故障有周期性——比如每周一次的定时任务把磁盘写满、每月一次的证书续期失败。保留期太短，你只能看到「现在坏了」，看不到「每次都是这个原因」。90 天是一个能覆盖周、月、季三种周期的最小值。

监控要装在业务机器上还是单独买一台？ 业务量小的时候装在业务机器上，用最轻量的采集方式；如果业务机器本身配置很低，或者监控要求 24 小时不间断（不能因为业务机器重启而丢失数据），那就单独准备一台小机器专门做监控。监控系统的可用性不应该依赖于被监控对象。