两条命令找出第三方接口问题点

缘起

这几天疲于救火,火气有点儿大,今早领导在群里@我了下,说第三方反馈我们的网络有些问题。搞得我一头雾水,我首先问清了事情的原委,原来我们这边某个应用调用了第三方接口,但是应用这边时不时的会甩出那么几条错误,而且近期比较多。这不问题一多,大家就紧张了。为了自证清白,我不得不拿起武器自卫。

措施

思索了一会儿,既然对方说是网络的问题,那么我就从网络着手。解决网络问题莫过于经典的OSI七层模型了,根据我以往的经验排错用七层模型还是很靠谱的,只要定位了问题在那一层基本上问题就解决了一大半儿。就像一个牛人故事里面讲的那样:知道在哪儿画线和画一条线的价值相差天壤。所以找出问题的根源然后再去解决问题才能有正解。
下面直接上两条命令,没有铺垫,后续遇到类似问题还可以参考:

1.首先确定TCP/IP层有无问题
首先想的是ping这个命令,本来还想用traceroute,mtr的,但是对方做了些安全的屏蔽,所以没效果,幸亏ping没有屏蔽否则真说不清了。
ping效果如下:

64 bytes from 58.213.99.80: icmp_seq=626 ttl=51 time=33.5 ms
64 bytes from 58.213.99.80: icmp_seq=627 ttl=51 time=33.6 ms
64 bytes from 58.213.99.80: icmp_seq=628 ttl=51 time=33.5 ms
^C
--- api.domain.com ping statistics ---
628 packets transmitted, 628 received, 0% packet loss, time 639851ms
rtt min/avg/max/mdev = 33.484/33.608/36.531/0.235 ms

看着还不错, 没有超时,ttl也算稳定,不过略大。北京到外地很少超过3000千米的,大多在2000千米内,20ms内才算优质。这里由ping命令可以判断TCP/IP层没有问题。

2.再看应用层主要是http/https协议
curl命令应该是首选,系统大多默认自带,使用方法多样,而且能从功能及性能两个层面来观察问题所在
先查看返回状态码,默认401还算正常因为没有加认证,但是多试几次就差点儿意思了,偶尔会出现503,代表后端处理不过来。这时基本上就发现了问题点儿,后端多半是集群可能是某个节点有问题,问题多半是处理到了瓶颈。
再看响应时间还是挺快的,进一步确认TCP/IP层没有问题。就连出现503时相应时间依然挺快的,感觉可能是第三方这边可能做了优化,默认超过了一个比较小的响应时间这边就会返回一个503,不用等那么久,这一点儿还是很认可的。

[root@188.18 ~]# curl -I https://api.domain.com/api
HTTP/1.1 401 Unauthorized
Server: nginx/1.16.1
Date: Tue, 09 Jun 2020 04:11:40 GMT
Content-Type: application/json;charset=utf-8
Content-Length: 0
Connection: keep-alive

time_connect: 0.033
time_starttransfer: 0.188
time_total: 0.188


[root@188.18 ~]# curl -I https://api.domain.com/api
HTTP/1.1 503 Service Unavailable
Server: nginx/1.16.1
Date: Tue, 09 Jun 2020 04:11:41 GMT
Content-Type: text/html;charset=iso-8859-1
Content-Length: 355
Connection: keep-alive
Cache-Control: must-revalidate,no-cache,no-store

time_connect: 0.047
time_starttransfer: 0.217
time_total: 0.217

后续

建议肯定是没有的,和他方合作,特别是一堆老师们,应该少说话,尽量别越界,把实事讲清楚就行。不用提建议,对方私下里肯定会改善的,毕竟这对人对己都是有好处的。
后续没有后续,做为运维,只要打好底子,就能从本质上去发现解决问题之道。他强任他强,清风拂山岗他横由他横明月照大江。好好的打磨打磨自己的内功,尽量使用最少的招数,解决最大的问题,达到四两拨千斤的效果。

点击数:21