1.
概述与准备工作
- 准备:需要 VPS 的 root 或 sudo 权限、提供商控制台账号、外部测试主机(最好在大陆与国外各一台)。
- 工具:ping/traceroute/mtr, iperf3, tcpdump/tshark, ethtool, netstat/ss, vnstat/iftop, Prometheus + node_exporter 或 Zabbix。
- 时间同步:保证 ntp 或 chrony 正常,避免因时间差导致日志无法比对(命令:chronyc sources 或 ntpq -p)。
2.
关键性能监控指标与阈值
- 延迟(Latency):ICMP 平均延迟 <100ms(链路稳定目标 30-80ms),抖动(jitter)<20ms;
- 丢包率(Packet Loss):端到端丢包 <0.5%(业务敏感场景 <0.1%);
- 带宽/吞吐(Throughput):链路带宽饱和率 <80%;使用 iperf3 测试;
- 链路异常(连接数、重传、网卡错误):重传率、ifconfig/ethtool RX/TX error;
- BGP/路由变化:AS 路径变化、黑洞公告、路径绕行。以上指标通过 Prometheus 或 Zabbix 采集并设定报警阈值。
3.
部署实时监控(Prometheus + node_exporter 示例)
- 安装 node_exporter:在 VPS 上运行 wget https://.../node_exporter && ./node_exporter &。
- 配置 Prometheus 抓取:在 prometheus.yml 添加 - job_name: 'taiwan-vps' static_configs: - targets: ['your.vps.ip:9100']。
- 添加网络相关 exporter(如 bpf 或自定义脚本)上报 mtr/iperf 的历史结果;Grafana 建面板显示延迟、丢包、带宽与网卡错误。
4.
主动链路检测与定时任务
- 定时 MTR:在 VPS 上 crontab 调度每 5 分钟运行 mtr -r -c 100 -w 8.8.8.8 保存结果到 /var/log/mtr/。
- 周期带宽测试:每天低峰用 iperf3 -c test-server -t 60 -P 4,或向提供商申请 iperf3 服务器检测双向吞吐。
- 保存与上报:保持历史数据至少 7 天以便比对,异常时自动上传到中心分析节点。
5.
故障快速定位标准流程(详尽步骤)
- 第一步:确认报警时间并拉取监控图(延迟/丢包/带宽)。
- 第二步:本地基础检测:ping -c 20 -s 1400 目标IP,mtr -r -c 100 目标IP,traceroute -n -T -p 80 目标IP;查看是否在某一跳出现丢包或跳数异常。
- 第三步:服务器侧检查:top/htop 查看 CPU/IO;ss -s 或 netstat -s 查看 TCP 重传;ethtool -S eth0 查看网卡错误;dmesg | tail 查内核异常。
- 第四步:抓包证据:tcpdump -i eth0 -w /tmp/cap.pcap host <目标IP> and port <端口>(注意抓包时长与文件大小),必要时使用 tcpdump -s 0 -nn -w。
- 第五步:路由与 BGP:查看路由表 ip route show、bgp 信息(若有路由器权限)或使用互联网 Looking Glass 检查 AS 路径变化。
6.
定位结论判定与隔离问题源
- 如果 mtr/traceroute 在某一中间跳点开始出现稳定丢包或延迟跳升,问题通常出在上游运营商或中间链路;
- 如果丢包/延迟在本机之前(如本机 NIC 错误、CPU 饱和、防火墙丢包),按服务器侧流程修复(修网卡驱动、调优内核参数或扩容 CPU/带宽);
- 双向验证:在对端也跑 mtr/iperf,验证是单向还是双向问题,便于判定对端或中间链路问题。
7.
收集上报给提供商的最小信息模板
- 时间戳(UTC)与持续时长;MTR(完整输出)、traceroute(-n -T)、ping(-s 与报文大小)、iperf3 日志与速度曲线、tcpdump pcap(首尾各 30 秒)与服务器负载快照(top、dmesg、ethtool 输出)。
- 示例:请在工单中附上 mtr -r -c 100 目标IP 输出、traceroute -n -T 输出、/tmp/cap.pcap,说明影响范围(IP/端口/时间段)并请求提供商检查 CN2 光缆或边缘路由器 AS 路径。
8.
恢复与验证操作清单
- 若是服务器问题:重启网卡(ip link set dev eth0 down/up)、清 conntrack(conntrack -F)、重启服务;若内核队列或拥塞,调整 sysctl(例如 net.core.netdev_max_backlog、tcp_congestion_control)。
- 若是上游问题:请求提供商修复并验证(拿到修复时间后运行 mtr/iperf3 验证),同时将修复前后数据对比并归档以便 SLA 统计。
9.
问答1:如何判断是 CN2 线路本身问题还是服务器配置问题?
问:如何判断故障来源是 CN2 线路还是我方服务器配置? 答:先做端到端测试:在 VPS 上运行 mtr/traceroute 指向公网目标,若在上游某跳(通常是 ISP 节点)出现丢包/延迟突增,且对端也能复现同样路径问题,倾向上游(CN2)问题;若丢包仅在本机前端出现(ethtool 显示 RX/TX error 或 CPU 占满导致重传),则是服务器配置或资源问题。
10.
问答2:我没有对端 iperf 服务器,如何验证带宽问题?
问:没有对端 iperf3 服务怎么办? 答:可使用公共测速(speedtest-cli)或向提供商申请临时测试端点;也可以在国外或大陆的另一台 VPS 上运行 iperf3 -s 来做临时测试。结合 MTR 判断链路段落,若带宽在跨境点骤降,说明中间链路限速。
11.
问答3:上报给提供商时哪些信息最关键?
问:哪些数据是提供商最需要的以便快速定位? 答:关键是时间窗口(精确到秒)、mtr/traceroute 原始输出、tcpdump pcap(能看到丢包或重传)、iperf3 测试结果以及本机网卡统计(ethtool 输出)和负载快照;这些能帮助运营方定位是链路、路由还是设备故障。
来源:台湾 vps 线路 cn2 性能监控指标与故障快速定位流程