一两个月以前就发现,位于国外的测试主机经常出现连接失败导致的错误报警,我们的业务涉及国内国外,国外有测试主机A,运行Jenkins任务,由主机B上的脚本轮询主机A上的Jenkins接口来获得测试状态;最近两周仔细观察发现,连接失败多出现在北京时间3-5点和晚上11点-凌晨2点.我通过监控系统也发现非常规律的TIME_OUT(和连接失败相符合),测试主机上的任务是调用美国的业务API,如果出现超时,测试直接会报错。(不行了,越说觉得越明显了,这么明显的原因今天才发现…还是因为别人的失误发现的…)
首先我们看到规律的TCP timeout,但是有TCP timeout 不一定有报警,但是报警一定位于TCP timeout,同时监控看到有大量的TIME_WAIT,1K左右
再来描述下今天发生的事,同事在国内"业务"搞域名切换,要把一个域名解析到另一个IP,突然国内的测试和国外的测试都有大量报警,看国外的是有过时的构建任务失败(红色),Jenkins URL访问失败。
我非常确认的是过时的任务不会触发警报,所以它构建失败只是幌子,但是看国外业务测试又没有出错,断定是主机B获取结果失败,从而报警。
同时由于另一个同时怀疑TIME_WAIT的问题,但是说由于Jenkins 作为server,由于自己主动断开连接造成的1K多TIME_WAIT,不至于导致自己的服务器程序没端口可用,而导致其他客户端访问而超时,所以TIME_WAIT 排除 ,但是TIME_WAIT对应的主机IP令人生疑,同事查得是北京亚马逊中心的IP,但是从AWS控制台并没有找到这个IP对应的主机信息,于是我百度这个端口,20389
这才点醒了我。测试主机使用的身份认证LDAP服务器是国内的,它出现故障,导致位于主机B上的程序 登录Jenkins超时,但是报出的错是连接Jenkins超时,掩盖了真相。于是登到主机上tcpping,2s等待时一步三跪,国内主机就没这个问题。
我们事后分析
openfalcon的TIME_OUT指的是计时器第一次超时时间,显然由于TCP重试机制,并不是每次第一次超时就会导致失败;这个TIME_OUT当然是向外的请求,既然向外的业务请求没有频繁超时,那么肯定是非业务超时了,但是没有想到主机上除了业务测试谁还会向外发请求。
主机C访问主机S的服务P偶尔出现超时?
范式: 查看主机C程序日志,系统日志和统计,C外发请求是否出现丢包(ride rocket),S主机在端口s收包是否成问题丢包?端口不够用?,服务P在处理请求(数据流动一定要具体)依赖的网络服务是否正常?
在解决问题时,要列举事实你所看到的现象,可以转述给别人(甚至模糊的转述给别人),看他的提问,给你不一样的切入点。
附加 国内国外:一般,公司可能非主要业务使用同一个系统;
北京时间:网络请求有明显的峰谷特性(一次傍晚时间明显的请求失败);
直接出现报错:那么TIME_OUT就是非测试请求时发生的;
搞域名切换:新IP对应的服务器上应用程序部署可能有问题,有缺陷;
都有:这两个程序的共同点出了问题 (依赖LDAP);
并没有找到这个IP对应的主机:那么这个IP是ELB的,但是怎么根据IP找打ELB名称我觉得是个技术活…
20200102
TIME_OUT问题再次出现,不过这次不是测试,而是关键业务主机。openfalcon显示0.3左右的TIME_OUT,已经很明显的影响到测试,估计用户使用也是。描述:测试发送TCP请求,socketTimeout是5s,仔细看Java文档,说的是readTimeout,5s内测试没有收到相应于是返回null,报错,但是从业务日志来看,(看了一个,即使一个也应该是可信的,因为业务没有大量报错),该请求79内ms就处理完并返回了,并且该请求不是和服务器交互的第一个请求,这次是在国外出现的问题,12.25出现问题;还有一次是国内618,初次请求就出错,监控表现为傍晚5点半开始业务主机有TcpDropOnOverflow,就是在建立TCP连接时的半连接队列满了,客户端请求被丢弃,晚上百度半连接队列满是因为业务模块处理不过来,不过我们不论是CPU还是Mem都很低,后面排查出为进程文件打开数限制ulimit -a
。
学习在应用层编程中TIMEOUT和传输层重传,计时器等的关系。