这是一个创建于 321 天前的主题，其中的信息可能已经有所发展或是发生改变。
我司的业务涉及上下游请求转发（下游请求到我们平台，我们平台再请求上游，然后将上游响应返回给下游），该业务对延迟要求较高（ 300ms 以内需要完成全流程）我想请问的是：
当出现超过延迟要求的情况时，在排除了平台故障导致的异常情况后，我如何确认延迟主要发生在下游向我们发起调用的时间，还是我们向上游发起调用的这个时间段内呢？
通俗来讲就是怎么能够判断到底是不是网络波动或者网络抖动带来的延迟？以及具体定位到是哪一段网络波动带来的影响
 | 1 onetown 321 天前 把每段的延时数据监控起来， 出问题， 看当时的时间点的丢包、延时数据（如果方便就计算一下 jitter ， 延时抖动的值）， 就知道是哪一段有问题了啊。 |
 | 2 xjzshttps 321 天前 这个不就是全链路跟踪的活？ |
 | 3 qq1147 OP @onetown 有两个点不太明白： 1. 下游用户调用我们的延时数据我们如何获取到呢，也就是如何排除丢包延时等情况是在下游用户到我们平台这个段发生的 2. 丢包和延时指标怎么记录是最准确的，我们的方案是在服务器上 traceroute 出每一跳的地址，然后 Ping 这些地址的方式记录的，往往记录出来都没有大幅波动，但实际业务还是出现了延迟 |
| 4 onetown 320 天前 @qq1147 #3 1. 如果无法做客户对你们的请求的延时监控， 那么就做一下减法， 比如 A-Z, 你可以记录 B-Z 的全部延时， 如果平均延时在 300, B-Z 是 200 ， 那么 A-B 就在 100 左右了 2. 不用 traceroute 每一跳的节点， 这个涉及到控制面和转发面 SLA 的指标是有可能不一样的，所以这个数据只能作为参考， 实际上， 你可以直接对最终的目标地址做监控，而且要结合 ICMP/UDP 和具体业务协议， 比如 tcping, curl 等等, 如果中间 B-Z 有你们自己的路由节点， 你可以每一个节点都监控， 比如你面向客户接入的 POP 在北京， 目标在洛杉矶， 如果从上海出海， 就可以记录， 北京-上海， 上海-洛杉矶， 洛杉矶-最终目标， 因为洛杉矶出 POP 了就去 internet 了， 也不是你们可控的 |
Select Language