先判断是链路异常，还是测量现象

访问美国CN2 GIA服务器时，页面变慢、连接超时或下载速度下降，并不一定代表线路故障。单次 ping 偏高可能是探测报文被限速；某个中间路由节点显示丢包，也可能只是该节点限制 ICMP 响应。判断告警是否成立，应优先看多个探测点、多个时间窗口的端到端结果，并结合业务实际使用的协议和方向。

建议按这个顺序排查：先确认故障时间、影响范围和探测方法，再比较不同来源到服务器的延迟与丢包；接着检查服务器网卡流量和带宽利用率；最后定位到主机网络、应用或上游路径。告警阈值应以稳定时段建立的基线为参照，而不是把某个固定延迟值直接套用到所有用户和时段。

建立可比较的监控基线

在配置告警前，先固定测试条件。至少记录探测节点所在网络和大致位置、目标 IP、协议、采样间隔、测试时间段及样本数量。业务用户主要通过 TCP 访问时，除 ICMP 外，还应监控到业务端口的 TCP 建连时间或应用请求耗时；ICMP 只能作为辅助信号。

基线宜覆盖工作日和业务高峰时段。记录每个探测点的延迟中位数、p95、丢包率，以及服务器入站和出站流量。样本应来自与业务用户网络相近的探测环境；不同运营商、办公网络与云探测节点的结果不能简单合并，否则正常的路径差异可能被误报为故障。

下面的阈值是用于启动监控的可调整初值，不是美国CN2 GIA服务器的固定性能指标。实际阈值应根据业务容忍度、探测节点基线和服务器可用带宽校准。

表中的时间和数值适合作为初始规则，不应脱离业务直接照搬。例如，短时下载任务可能允许较高带宽利用率，而交互式业务可能需要更严格的延迟告警。没有经过确认的带宽上限时，不要用猜测的端口速率计算利用率；应先核对服务配置或管理面可见的带宽信息。

按优先级由外到内排查

1. 确认告警是否可复现

先核对告警时间、探测节点、目标地址、协议和样本数，并与业务日志中的失败时间对齐。若只有一个探测点短暂异常，其他探测点及业务请求正常，先将其视为局部或瞬时现象，继续观察，不要立即更改服务器配置。

从 Linux 探测机执行以下命令，可检查到目标 IP 的 ICMP 响应。-c 100 表示发送 100 个请求；运行前确认探测符合所在网络的使用规范。

ping -c 100 <目标IP>

重点看丢包率和往返时间，而不是只看单次最大值。若结果显示丢包或延迟升高，不能仅凭这一项认定服务端故障；若 ping 全部超时，也可能是目标或沿途设备不响应 ICMP。应继续用业务端口进行 TCP 探测，或从业务日志确认连接是否失败。

2. 比较多个探测点与路径

在不同网络来源重复测试。如果只有一个来源异常，优先排查该来源网络、出口或到目标的特定路径；多个来源在相近时间同时出现端到端丢包或延迟升高，才更像是目标侧或共同路径问题。

Linux 探测机安装了 mtr 时，可运行：

mtr -rwzc 100 <目标IP>

该命令发送多轮探测并输出路径统计。若某个中间节点显示丢包，但后续节点和最终目标正常，通常不能据此判定端到端丢包；中间设备可能降低对探测报文的响应优先级。若从某一跳开始，后续多跳直至目标都持续出现相近的丢包或延迟变化，才值得进一步关注。路径变化本身也不等同于故障，需与业务失败、端到端指标和时间窗口对应。

3. 核对服务器网卡流量与接口错误

登录服务器后，先查看接口统计，不做配置变更。以下命令适用于常见 Linux 环境：

ip -s link

检查实际承载业务流量的网卡，关注接收与发送字节数、丢弃和错误计数。计数是累计值，应比较两次采样之间是否增长，不能仅凭历史累计值判断当前故障。若没有错误增长、流量也远低于已核实的带宽上限，而外部探测仍异常，应把重点放回端到端路径或业务端口。

需要观察网卡流量速率时，可在系统安装并启用了 sysstat 的情况下执行：

sar -n DEV 1 5

输出按网卡展示收发速率，但接口名、单位和字段显示可能随系统版本而异。若命令不存在，先确认工具是否安装；不要据此误判为网卡故障。也可以间隔固定时间读取 ip -s link 的字节计数，按“字节增量 × 8 ÷ 秒数”换算为比特每秒，并确认统计的是正确接口。

4. 判断是否存在带宽拥塞

带宽告警应基于实际可用上限计算，而不是依据服务器规格名称或一次测速结果。分别检查入站和出站流量：出站接近上限时，下载或对外服务可能变慢；入站接近上限时，上传、同步或用户请求可能受影响。若利用率持续高位，同时丢包、TCP 重传或业务响应时间上升，拥塞可能性更高。

不要在生产高峰期直接用大流量测速来验证带宽，这会额外占用链路并影响业务。需要进行主动吞吐测试时，应在获准的测试窗口内，使用可控的测试端点和时长，并提前确认目标端可接收测试流量。测试结果只代表该时间、该方向、该探测节点与该并发条件下的样本，不是持续可用带宽的承诺。

结果分支：告警之后看什么

• 只有 ICMP 丢包，业务端口正常，多个探测点的请求也成功：先检查探测策略和目标对 ICMP 的响应情况。降低对单一 ICMP 指标的告警权重，不要据此改动网络配置。
• 一个探测点异常，其他来源正常：保留该点的时间序列，增加同类来源复测，并核对其网络出口。告警应标记为单点影响，避免升级成全站故障。
• 多个探测点同时出现端到端丢包或延迟升高：结合路径变化、网卡计数和业务日志判断范围。若服务器接口计数正常且流量未接近上限，优先收集探测时间、来源、目标、路径和业务端口结果，供网络侧继续定位。
• 带宽持续接近上限，并伴随重传或业务变慢：确认入站还是出站达到高位，再识别对应时段的业务流量来源。调整告警或业务流量策略前，先确认变更影响范围和回退办法；只调高阈值不能消除实际拥塞。
• 服务器接口错误或丢弃计数持续增加：记录接口和计数增量，并检查系统日志及相关变更。不要在原因不明时重启网络服务或修改接口配置，以免扩大影响。

告警降噪与故障前兆

告警采用“持续时间 + 多样本 + 恢复条件”比单点越线更可靠。可以将延迟按 1 分钟采样、按 5 分钟窗口判定；丢包使用滚动窗口计算；带宽同时保留短周期峰值和较长周期平均值。具体窗口要与业务检测频率匹配，样本太少时不宜直接升级严重告警。

设置恢复阈值时，应加入回差，避免指标在门槛附近反复触发。例如，利用率达到 80% 持续一段时间才预警，恢复条件可以设为低于 70% 并持续一段时间。恢复门槛和持续时间应结合业务流量波动调整。若同一故障会同时触发延迟、丢包和业务探测告警，可将它们关联到一个事件中展示，但保留各指标原始数据，方便区分原因。

更值得关注的故障前兆通常是多个信号的连续变化：p95 延迟逐步抬升、丢包从零星变为持续、出入站流量长时间贴近上限，或 TCP 重传与业务超时同时增加。单个信号短暂波动未必代表故障；多个独立信号在相同时间窗口变差，且不同探测点可复现时，升级排查优先级更合理。

修复后的验证与持续观察

处理后不要只看告警是否自动恢复。使用与故障前相同的探测节点、目标、协议、采样间隔和测试时段，重新比较延迟中位数与 p95、丢包率、带宽利用率和业务请求结果。若条件允许，覆盖一个完整业务高峰窗口，并确认网卡错误计数不再持续增长。

若复测正常但告警再次出现，应检查是否只在特定来源、方向或高峰时段复发，再调整对应规则或继续定位；不要通过放宽所有阈值来“消除”告警。保留修复前后同口径的数据，以及变更时间和回退方式，才能确认问题是否真正解决。