分享个一年前的故障处理.
故障现象:
应用程序的某个功能偶尔报"connect reset by peer" (我最初看见的现象就是这个......)
这个故障其实还满常见的.
大概环境(仅做参考):
图标我就不改了, 将就下 故障现象:应用程序的某个功能偶尔报"connect reset by peer"排查思路:
既然客户端报错"connect reset by peer", 那大概率是应用服务器的连接满了,被杀了.
登录应用服务器, 查看连接数不高. 查看日志, 也有报错 "connect reset by peer". 服务器觉得连接被客户端断了, 客户端以为被服务器断开了. 这就很有意思了. 关键是只是这一个功能报这个错, 其它应用的功能都是正常的. 总不可能是数据库的问题吧, 查看数据库 AWR, 稳得不行... 完全没得问题.(这种问题不可能是数据库的问题, 但瞎猫想碰见死耗子...)
当时用的命令忘了, 参考如下:
代码语言：javascript复制#本地连接中 time_wait
netstat -tnp | grep TIME_WAIT | awk '{print $4}' |sort | uniq -c | sort -n
#连接中外地的IP
netstat -tnp | awk '{print $5}' | sort | uniq -c |sort -n
#查看本地TCP状态排序
netstat -ntp |awk '{print $6}' | sort | uniq -c
#查看服务器某地址端口的连接数
netstat -nat | grep 0.0.0.0:8080 |awk '{print $5}' | sort | uniq -c | sort -rn1. 推测为程序BUG
不是我甩锅哈, 这感觉就是程序问题啊, 你看其它功能都正常. 就这个功能不正常. 开发的也甩锅, 这个程序包从来就没动过, 而且其它地方的都没得问题. 确实, 我查看程序包都是几年前的时间戳了. 而且该功能是一个常用功能,用的人很多,不可能只有这一处有问题. web应用服务器报的错是"connect reset by peer", 应用服务器不可能瞎报错啊, 故把问题锁定在了 应用服务器和客户端之间.
2. 防火墙网络问题
测试丢包率: 0 , ping大包也不丢. 页面响应时间也很快. 排除网络.
那大概率就是防火墙把这个功能的包都丢了. 防火墙一般不会做这样的事情, 但还是检查下, 负责防火墙的人说, 防火墙配置没动过. 故登录防火墙检查ACL之类的未发现异常. 那就不是防火墙的锅了
3. SSO问题
那就绕过SSO(单点登录)测试下, 可惜开发同事原本就没写登录界面, 绕过SSO的话, 还得写个登录界面.....
SSO应该是没得问题的, 先搁着吧.
4. 负载问题
这个有问题吗? 不像吧, 而且使用改负载的还有其它应用, 那些都没得问题的嘛. 而且这个应用只是这个功能的问题. 感觉还是软件的问题. 还是先绕过负载测试一下吧. 测试(curl就行)功能正常, 正常的话,那就说明是负载的问题了. 这么有力的证据,负责负载的人不能再甩锅了吧. 此时, 其它应用也出现了类似的问题. 那基本上就锁定了是负载的问题. 找负责负载的同事看下就知道了
5. 结论
确定为负载问题, 负载的连接满了, 就丢掉了新的连接. 为什么要丢新的连接,而不是丢最旧的连接? 估计是想让用户觉得是网络问题吧. 听说后面是把负载的连接生命周期调短了. 应用也都恢复正常了.
6. 后续
虽然问题是解决了, 但是对于这个现象, 还是没能解释为什么只有这个功能不行? 这个功能也没有新开连接啊.搞不懂....
