后端服务: 内部服务 A 通过域名的方式调用内部服务 B, A 服务设置了 300ms 的超时时间, 部分请求在到达 B 服务时就已经超时, 也就是在 B 服务入口处打印了日志,发现进入的时间已经超过 300ms 了, A 调用 B 超时.
目前我自己试过:
上述都没发现什么问题,请问大佬们还能从哪些方面入手排查?
1
zz44917 2023-10-18 14:25:05 +08:00 1
A 、B 两端同时抓包,看网络报文时间。
|
2
maninnet 2023-10-18 15:00:43 +08:00 via iPhone
有没有可能 dns 缓存过期?
|
3
Goooooos 2023-10-18 15:03:00 +08:00
也有可能消息已经到 B 了,但由于 B 线程池堵塞,等处理消息后才打的日志
|
4
xuhai951753 2023-10-18 15:07:18 +08:00
这个只能是网关耗时太长了吧。。如果使用了网关的话。。
|
6
zpfhbyx 2023-10-18 16:45:44 +08:00
链路追踪..
|
7
8355 2023-10-18 16:56:31 +08:00
公网域名/ 跨服务区等各种问题 应该很好解决 不会就提工单咯
|
8
sujin190 2023-10-18 17:06:25 +08:00 via Android
k8s 的话也许是 dns 解析问题
|
9
treexie 2023-10-19 08:54:03 +08:00
将连接的每个阶段的耗时均记录起来即可,例如 http 调用的就包括以下步骤。golang 的可以参考: https://github.com/davecheney/httpstat ,其它语言的也类似。
DNS Lookup TCP Connection TLS Handshake Server Processing Content Transfer [ 0ms | 0ms | 241ms | 26ms | 0ms ] | | | | | namelookup:0ms | | | | connect:0ms | | | pretransfer:242ms | | starttransfer:269ms | total:269ms |
10
isno 2023-10-19 09:25:45 +08:00
|
11
garychenlin 2023-10-19 09:54:27 +08:00 1
遇到过相同的问题,当时原因是程序内有 dns 解析的缓存 ip ,程序访问域名的时候,会从这些缓存的 ip 一个一个尝试连接。
这种情况下,能 ping 通并不代表没有问题。 当时处理方案: 1. 两端抓包,统计请求包发出和收到时间 2. 定位到耗时在请求包发出之前,于是细化耗时区间,通过日志或者其他方式,记录请求包发出过程的时间,比如打包、压缩、加密、dns 解析等 3. 然后就定位到了 dns |
12
feitxue 2023-10-19 13:47:20 +08:00
服务 A 和 B 是否在同一个内网?
都是内部服务,那么域名解析的 ip 是公网 ip 还是内网 ip |