本文介绍使用网络探测分析应用解决实际问题的实践教程案例。
案例一：某游戏美服间歇性高延迟故障定位
案例背景
某游戏美服出现间歇性高延迟问题。触发 CLS 告警，显示从中国香港、上海两个探测点到洛杉矶游戏服务器的 ICMP 延迟（Ping）从平均150ms飙升至400ms以上，且丢包率从<1%跃升至15% - 25%，影响中国内地、中国香港连接至美国洛杉矶数据中心的玩家。
核心挑战
快速、精准的根因定位与恢复。
解决方案
接入 CLS 的网络探测应用，配置实时网络质量告警，及时发现问题。当出现告警时，通过网络质量分析仪表盘快速定位问题。流程如下：
1. 接入监控： 接入 CLS 网络探测应用，实现网络质量的探测与数据采集。详细请参见 使用网络探测分析。
2. 配置告警：统计各网络链路的指标，当连接失败率大于5%、网络延迟大于400ms、丢包率大于5%满足其中任一指标阈值时触发告警。告警通知中展示触发告警的对应链路服务端和客户端信息。详细操作请参见 配置告警策略。告警语句配置如下：
统计连接失败率，阈值设置为大于0.05（5%）。
attribute.net.type:"ping" | SELECT concat(ip_to_country(cast(json_extract_scalar(attribute.net.origin, '$.netInfo.client_ip') AS varchar)), '-', ip_to_provider(cast(json_extract_scalar(attribute.net.origin, '$.netInfo.client_ip') AS varchar))) AS "客户端", concat(ip_to_country(cast(json_extract_scalar(attribute.net.origin, '$.host_ip') AS varchar)), '-', ip_to_provider(cast(json_extract_scalar(attribute.net.origin, '$.host_ip') AS varchar))) AS "服务端", count( case when cast(json_extract(attribute.net.origin, '$.responseNum') as bigint) = 0 then 1 else null end)*1.0/count(*) as "失败率" GROUP BY "客户端", "服务端" ORDER BY "失败率" DESC LIMIT 20
统计网络延迟，阈值设置为大于400（400ms）。
attribute.net.type:"ping" | SELECT concat(ip_to_country(cast(json_extract_scalar(attribute.net.origin, '$.netInfo.client_ip') AS varchar)), '-', ip_to_provider(cast(json_extract_scalar(attribute.net.origin, '$.netInfo.client_ip') AS varchar))) AS "客户端", concat(ip_to_country(cast(json_extract_scalar(attribute.net.origin, '$.host_ip') AS varchar)), '-', ip_to_provider(cast(json_extract_scalar(attribute.net.origin, '$.host_ip') AS varchar))) AS "服务端", avg(cast(json_extract(attribute.net.origin, '$.latency') as double)) as "延迟" GROUP BY "客户端", "服务端" ORDER BY "延迟" DESC LIMIT 20
统计丢包率，阈值设置为大于0.05（5%）。
attribute.net.type:"ping" | SELECT concat(ip_to_country(cast(json_extract_scalar(attribute.net.origin, '$.netInfo.client_ip') AS varchar)), '-', ip_to_provider(cast(json_extract_scalar(attribute.net.origin, '$.netInfo.client_ip') AS varchar))) AS "客户端", concat(ip_to_country(cast(json_extract_scalar(attribute.net.origin, '$.host_ip') AS varchar)), '-', ip_to_provider(cast(json_extract_scalar(attribute.net.origin, '$.host_ip') AS varchar))) AS "服务端", avg(cast(json_extract(attribute.net.origin, '$.loss') as double)) as "丢包率" GROUP BY "客户端", "服务端" ORDER BY "丢包率" DESC LIMIT 20
3. 分析诊断：
触发告警后先查看告警通知,发现异常主要集中在中国大陆、中国香港到美国的链路上。
打开 网络质量分析_PING 分析仪表盘 和 网络质量分析_TCP 分析仪表盘。在顶部过滤服务端国家为美国，客户端国家为中国。发现 PING 延迟高、丢包严重；再看 TCP，连接成功，但耗时极不稳定（200ms-800ms），确认问题影响到了 TCP 协议层，非仅 ICMP 限速。
打开网络质量分析_MTR 分析仪表盘，下钻到链路的每一跳分析。查看 MTR 探测结果明细，任选一个异常记录，单击查看详情。可发现如下信息：
第1 - 5跳（本地运营商网络）：延迟和丢包均正常。
第6跳：进入中国电信国际出口（IP 归属 202.97.*.*）。
第7 - 9跳：经过 202.97.*.*系列节点时，丢包率骤升至20% - 30%，平均延迟从50ms跃升至300ms。
第10跳之后（进入美国境内网络）：丢包率降回1%以下，但延迟基数已因前段拥塞而抬高。
4. 定位根因：故障点高度集中于中国电信通往北美方向的国际骨干网出口节点。该时段正值国内晚间上网高峰，叠加美西周末游戏高峰，导致跨境链路拥塞。
案例二：通过 PING 分析提升 FPS 游戏体验
案例背景
某款第一人称射击游戏在全球多个数据中心部署了战斗服务器。玩家根据匹配规则被分配到不同服务器进行对战。由于网络延迟直接影响操作响应与游戏体验，必须根据实时网络质量，优先将玩家分配至低延迟的战斗服务器。
核心挑战
传统静态分配或单纯依据地理就近的策略，难以适应网络状况的动态波动，如区域性网络拥塞、跨境链路不稳定等，导致玩家可能持续遭遇高延迟，影响公平性与体验。
解决方案
接入 CLS 网络探测应用，实现对各地区玩家到不同战斗服务器链路的延迟进行持续监控与数据分析，并据此动态调整匹配策略，优化整体网络体验。案例实践流程如下：
1. 接入监控： 接入 CLS 网络探测应用，实现对“玩家-服务器”链路的网络质量探测与数据采集。详细请参见 使用网络探测分析。
2. 分析诊断： 在 网络质量分析_PING 分析仪表盘 中，实时查看各链路延迟及服务器负载。本案例中发现，中国玩家当前被分配至四个地域的服务器，其中至俄罗斯服务器的链路延迟普遍高于200ms，而法国服务器同时段延迟低，负载也较低。
3. 策略调优： 基于数据洞察，调整匹配规则，国际对战时将中国玩家优先分配目标指向法国服务器，并大幅降低俄罗斯服务器的分配优先级，从而快速将玩家导向更优链路。
实施效果
通过上述数据驱动的动态调度，有效规避了高延迟链路，显著降低了受影响玩家的平均网络延迟，提升了对战体验的流畅性与公平性。
