常见门店网络问题排障

一、久久丫案例背景

久久丫实施过程,一线反馈1-2家门店经常会有支付超时报错,经过IDS-KIT工具分析,主要异常如下:

{
"error": "send request failed: Post https://hipos.51991.com/api/v3/pbis/getMember?0.03... dial tcp 47.101.63.39:443: i/o timeout",
"headers": {
"Accept": [
"application/json"
],
"Accept-Language": [
"zh-CN,zh;q=0.9"
],
.......
"method": "POST",
"request": "{\"channel\":\"YunxiOperation\",\"partner_id\":\"441\",\"store_id\":\"4617253233025384449\",\"store_code\":\"206593\",\"scope_id\":0,\"mobile\":\"18969873546\",\"card_no\":\"\",\"member_code\":\"\"}",
"since": 1666194919366,
"url": "https://hipos.51991.com/api/v3/pbis/getMember?0.03...
}

经过分析,目前POS跟云端SLA的CONNECT Timeout 2s,该门店一天有几十个这样的连接超时,初步分析:跟门店网络不好有关。

进一步沟通,该门店使用Wi-Fi,大概率是商场网络,我们两手准备,一方面准备了一个模拟请求云服务的程序(5秒一次),另一方面沟通用ping来验证门店网络丢包情况。

1.1 程序验证

按附件connchecker.exe运行(客户windows环境),执行15分钟,收集日志如附件(connchk.log)

结论:

请求https://hipos.liufuya.net/api/gateway接口,共超时100次。 

TCP Connet超时时间2s的,98次超时(共596次请求),失败率16% 

TCP Connet超时时间4s的,2次超时(共555次请求),失败率0.4%

1.2 Ping验证

结论

结论:

持续跑一段时间整理丢包率8%,网络非常不可靠。


1.3 这个案例的动作

  • 运维层面告知久久丫门店网络存在如上问题,进一步找供应商协助优化。  @陈涛  进行中
  • HiPOS调大TCP连接超时时间,从2S改为5S。  @东周 完成

进一步动作:

  • 运维再遇到常见网络异常可以参考上述的排查思路。
  • HiPOS产品层面可以逐步集成网络细粒度排障和监控工具。
  • HiPOS研发层面逐步能自适应不同的网络现状,自适应的进行学习和调整timeout,提升产品交互体验。

二、常见网络排查工具MTR介绍

除了上述Ping和研发的脚本来判断主机的网络连通性,有一个更好用的工具MTR。

windows下载地址(或者附件中下载): https://github.com/oott123/WinMTR/releases  

2.1 MTR结果分析

当我们分析 MTR 报告时候,最好找出每一跳的任何问题。除了可以查看两个服务器之间的路径之外,MTR 在它的七列数据中提供了很多有价值的数据统计报告。 Loss% 列展示了数据包在每一跳的丢失率。 Snt 列记录的多少个数据包被送出。 使用 –report 参数默认会送出10个数据包。如果使用 –report-cycles=[number-of-packets] 选项,MTR 就会按照 [number-of-packets] 指定的数量发出 ICMP 数据包。

Last, Avg, Best 和 Wrst 列都标识数据包往返的时间,使用的是毫秒( ms )单位表示。 Last 表示最后一个数据包所用的时间, Avg 表示评价时间, Best 和 Wrst 表示最小和最大时间。在大多数情况下,平均时间( Avg)列需要我们特别注意。

最后一列 StDev 提供了数据包在每个主机的标准偏差。如果标准偏差越高,说明数据包在这个节点的延时越不相同。标准偏差会让您了解到平均延时是否是真的延时时间的中心点,或者测量数据受到某些问题的干扰。

例如,如果标准偏差很大,说明数据包的延迟是不确定的。一些数据包延迟很小(例如:25ms),另一些数据包延迟很大(例如:350ms)。当10个数据包全部发出后,得到的平均延迟可能是正常的,但是平均延迟是不能很好的反应实际情况的。如果标准偏差很高,使用最好和最坏的延迟来确定平均延迟是一个较好的方案。

在大多数情况下,您可以把 MTR 的输出分成三大块。根据配置,第二或第三跳一般都是您的本地 ISP,倒数第二或第三跳一般为您目的主机的ISP。中间的节点是数据包经过的路由器。

当分析 MTR 的输出时,您需要注意两点: loss 和 latency。

2.2 网络丢包

如果在任何一跳上看到 loss 的百分比,这就说明这一跳上可能有问题了。当然,很多服务提供商人为限制 ICMP 发送的速率,这也会导致此问题。那么如何才能指定是人为的限制 ICMP 传输 还是确定有丢包的现象?此时需要查看下一跳。如果下一跳没有丢包现象,说明上一条是人为限制的。如下示例:

人为限制MTR丢包

在此例中,第4跳发生了丢包现象,但是接下来几条都没任何丢包现象,说明第二跳的丢包是人为限制的。如果在接下来的几条中都有丢包,那就可能是第二跳有问题了。请记住,ICMP 包的速率限制和丢失可能会同时发生。

MTR丢包截图

从上面的图中,您可以看从第13跳和第17跳都有 10% 的丢包率,从接下来的几跳都有丢包现象,但是最后15,16跳都是100%的丢包率,我们可以猜测到100%的丢包率除了网络糟糕的原因之前还有人为限制 ICMP。所以,当我们看到不同的丢包率时,通常要以最后几跳为准。

还有很多时候问题是在数据包返回途中发生的。数据包可以成功的到达目的主机,但是返回过程中遇到“困难”了。所以,当问题发生后,我们通常需要收集反方向的 MTR 报告。

此外,互联网设施的维护或短暂的网络拥挤可能会带来短暂的丢包率,当出现短暂的10%丢包率时候,不必担心,应用层的程序会弥补这点损失。


2.3 网络延迟

除了可以通过MTR报告查看丢包率,我们也还可以看到本地到目的之间的时延。因为是不通的位置,延迟通常会随着条数的增加而增加。所以,延迟通常取决于节点之间的物理距离和线路质量。

MTR查看网络延迟

从上面的MTR报告截图中,我们可以看到从第11跳到12跳的延迟猛增,直接导致了后面的延迟也很大,一般有可能是11跳到12跳属于不通地域,物理距离导致时延猛增,也有可能是第12条的路由器配置不当,或者是线路拥塞。需要具体问题进行具体的分析。

然而,高延迟并不一定意味着当前路由器有问题。延迟很大的原因也有可能是在返回过程中引发的。从这份报告的截图看不到返回的路径,返回的路径可能是完全不同的线路,所以一般需要进行双向MTR测试。

注:ICMP 速率限制也可能会增加延迟,但是一般可以查看最后一条的时间延迟来判断是否是上述情况。


2.4 根据MTR结果解决网络问题

MTR 报告显示的路由问题大都是暂时性的。很多问题在24小时内都被解决了。大多数情况下,如果您发现了路由问题,ISP 提供商已经监视到并且正在解决中了。当您经历网络问题后,可以选择提醒您的 ISP 提供商。当联系您的提供商时,需要发送一下 MTR 报告和相关的数据。没有有用的数据,提供商是没有办法去解决问题的。


2.5 online mtr

https://traceroute-online.com/mtr/


Is this article helpful?
3 1 1
发表评论
 
附上文件