监控一个独享 IP,到底在监控什么
很多团队没有为独享 IP 单独搭监控,直到某天业务方反馈「连不上」才去排查。其实独享出口的健康状态可以拆成四个很具体的问题:出口地址还是不是当初登记的那个;到目标服务的延迟和丢包是否在基线范围内;HTTP 请求的各阶段耗时有没有异常;一旦出现异常,路径上哪一段变了。curl、ping、mtr 三个命令行工具就能回答这四个问题。这篇文章面向运维与 IT 负责人,给出一份可直接拿去跑的脚本模板、告警阈值设置思路,以及解读 mtr 结果时最容易踩的坑。超出这些需求时,再考虑监控平台,参考非工作时间网络异常怎么发现:出口监控与告警实践。
一份最小可用的检查脚本
下面的脚本适合放在会走独享出口的一台 Linux 机器上,用 cron 每几分钟执行一次。其中的地址 203.0.113.10 是文档保留段的示例地址,请替换成你们实际登记的出口地址和实际业务域名。
#!/usr/bin/env bash
EXPECT_IP='203.0.113.10'
TARGET='example.com'
LOG=/var/log/egress-health.log
TS=$(date '+%F %T')
# 1. 出口一致性
NOW_IP=$(curl -4 -s --max-time 8 https://ipv4.icanhazip.com | tr -d '[:space:]')
[ "$NOW_IP" = "$EXPECT_IP" ] && IP_OK=1 || IP_OK=0
# 2. 延迟与丢包(10 个包)
PING=$(ping -c 10 -q $TARGET | tail -2 | tr '\n' ' ')
# 3. HTTP 分段耗时
HTTP=$(curl -4 -s -o /dev/null --max-time 15 \
-w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}' \
https://$TARGET)
echo "$TS ip=$NOW_IP ip_ok=$IP_OK | $PING | $HTTP" >> $LOG
# 4. 只在异常时跑 mtr,避免日常产生大量探测流量
if [ "$IP_OK" = 0 ]; then
mtr -r -c 20 -n $TARGET >> $LOG.mtr
fi
这份脚本的设计思路
第一步用 curl -4 取公网出口地址并与期望值比对,这一步就能发现出口被切换、隧道掉线后回落到本地网络等最常见的问题。第二步用小批量 ping 获取平均延迟和丢包率,注意不要用太大的包数,避免监控本身成为流量来源。第三步用 curl 的 -w 参数把一次请求拆成 DNS、TCP 连接、TLS 握手、首字节和总耗时五段,哪一段变长就能直接定位问题大致在哪一层。第四步只在出口地址异常时才跑 mtr,因为 mtr 会发送大量探测包,不适合高频执行。如果你们需要更系统的延迟测试思路,可以参考独享节点真实延迟怎么测:企业 IT 不该只看 ping 值。
告警阈值怎么设,才不会天天误报
监控最容易失败的地方是告警太敏感,运维收到过多没用的通知后会逐渐忽略。建议用「基线 + 持续性」两个原则设阈值:
- 基线:先运行一到两周,统计平均延迟和第 95 百分位延迟,以基线的若干倍作为告警条件,而不是凭感觉定一个数字;
- 持续性:单次失败不告警,连续三次或连续一段时间内失败才告警;
- 分级:出口地址不一致属于严重告警(可能已经走到未登记的地址),延迟偏高属于提醒级。
告警可以先用最简单的方式推送到即时通讯工具,等稳定后再接入值班流程。一旦告警真正触发,应急切换和排查步骤可以直接套用企业级 VPN 故障应急响应 SOP。
解读 mtr 结果:中间跳丢包不等于真丢包
看最后一跳,不要看中间跳
mtr 的 Loss% 反映的是某一跳对探测包的响应比例,不是你的业务流量的丢包率。许多路由器会把生成探测响应的优先级调得很低,即使正常转发流量没有任何问题,中间某一跳也可能显示较高的丢包。判断规则很简单:如果丢包只出现在中间某一跳,而后面的跳和最后一跳都是 0%,这通常只是限速的假象;只有丢包一直持续到最后一跳,才说明链路上确实有问题。
把 mtr 结果和基线对照
建议在正常时段保留一份 mtr 结果作为基线,故障时把两份并排对比:哪一跳的地址变了(路径切换)、哪一跳开始延迟明显抬高、最后一跳是否仍然可达。把对比结果连同时间一起发给服务商客服,比一句「感觉变慢了」更容易得到有效回复。
部署与维护建议
- 脚本部署在会走独享出口的机器上,否则检测的就不是真正的出口;
- 用 cron 每 3 到 5 分钟执行一次,预留日志轮转,避免磁盘被写满;
- 每当出口地址变更、目标服务迁移或线路调整后,同步更新 EXPECT_IP 和 TARGET;
- 监控数据留存至少一个计费周期,方便和服务商对账;
- 监控机自身也要有人关注,避免「监控挂了没人知道」。
这套脚本覆盖的是基础健康检查,足以让大部分「连不上」的反馈变成有日志可查的事实。如果你们使用 NasaVPN 的独享 IP 与独享节点,可以把它们直接用到自己的出口上,一旦监控显示异常,就把脚本输出作为排查材料提交给客服。