hi, 现在 client infra 团队的耀文他们在定位 AWS 外网链路的网络性能问题,麻烦你跟进一下吧;这个对我们的产品体验很重要, 需要我们投入更大的精力还进一步优化; 回头 yaowen 会议写 task 跟进;thx
- 和 aws 就此问题进行沟通:确保信息对问题解决的全面性和有效性,避免扯皮问题的发生;
当前,偶尔会出现用户无法访问 aws 服务器,网络无法访问的情况(无法访问是否和 dns 解析有关不可知)
当用户上报上述问题时,(能够同时)提供机制(附加信息)验证是否确实存在网络问题
根据 ops 同学(tony)的专业判断,提供如下信息可以更好地帮助定位问题:
- DNS 是否正常
- 如果 DNS 正常,server 的 IP 是什么
- client ip
- 具体时间点
在 帮助
页面中,提供网络诊断功能(效果如下图所示),上述需求中要求的信息应该都满足了
- 客户端都包括哪些设备?
- 客户端发生问题的规律是什么?
- 零星出现(时间点)?
- 一小段时间出现(时间段)?
- 发生问题的时段是否存在规律?
- 地区相关性?
- 运营商相关性?
- 帮助页面中的网络诊断是在发生问题的时间段触发的么?还是发生问题后触发?如何保证发生问题的同时进行测试?
bilibili 相关:
- www.bilibi.com
- interface.bilibi.com
- comment.bilibi.com
- api.bilibi.com
- app.bilibi.com
- passport.bilibi.com
- account.bilibi.com
- bangumi.bilibi.com
liulishuo 相关:
- 公司暴露的测速页面:
阿里昆仑用户诊断工具:https://cdn.dns-detect.alicdn.com/https/doc.html
已被用作用户 Ping 页面
- [Android] 调研可行性
- [iOS] 调研可行性
- 新增 traceroute 功能
背景:
根据 ops 同学的反馈,如果 DNS 解析成功,但是 IP 连接失败的话,当前的信息无法定位问题,需要
traceroute
的信息功能:
- 用户检测连通性时,如果存在 DNS 解析成功,ping IP 失败的情况下,自动触发
traceroute
;- 如果一个域名有多个 A 记录的情况下,只有第一条 A 记录失败的情况才会触发
traceroute
;- 存在多个 ping IP 失败的情况下,只去前面三条;
traceroute
信息会被 append 在复制粘贴的日志中建议增加:
- 用户可以取消
traceroute
的功能;- 用户应该可以看到
traceroute
的进度(至少是以百分比的形式);- 建议加入最多多少跳,否则终止(例如 30)(连续 N 跳没反应终止的话,可能不是一个好的条件,4 跳无返回之后可能会给出 echo reply 的返回);
- 使用 ICMP echo request/reply 的方式实现效果比 UDP 垃圾数据 + unreachable 的 port 效果要好,即我们实现方案可能会比 mac 上的
traceroute
要好;Optional:
- 给用户显示实时的
traceroute
进度;- 点击条目可以触发的
traceroute
;- 完成
traceroute
在条目上给出标记,但不影响重新触发;
- 检测信息写入 LogX
- 客户端通过 LogX 上报问题:每次检测把有问题的检测结果(DNS 解析错误或者 Ping 不通)上报到 LogX ;
- 用户支付未打开案例分析
- 用户 Ping 页面
- 用户网络监测页面信息
- kibana 上用户相关的请求信息