最近工作中的一个问题，耗时一个月之久终于调查完毕且顺利解决，顿时感慨万千。耗时之久和预期解决时间和环境搭建以及日志不合理等等有关，当然这个并非此文的重点。
之所以在很久以后的今天又开始写文，主要是这个问题调查的过程值得铭记。具体情况如下文述。
一、问题发现过程
数据告警服务提示相关分析结果缺失，经初步调查，发现分析服务在调用对应的NLP算法服务时出现大量Failed，遂查看算法日志，确实存在错误信息。
二、问题调查和解决
1.定位问题
1) 反馈给算法相关开发同学：他们认为可能是该算法遇到了长文本数据（超过3000字），由于分析时间超长，导致后续算法请求时出现阻塞而导致failed。
2) 根据开发的反馈，开始定位是否存在这样的长文本数据：通过分析日志和数据库查询确认后，并没有分析长文本数据，且出现异常时的文本数据均为短文本（小于200）。
3) 深入调查：该算法部署了多个节点，出现异常时，多个节点均出现了异常，因此可能是算法本身遇到了某个瓶颈问题。经确认，该算法使用了同一台GPU服务器上的tf-serveing服务。
4) 确认GPU服务器是否发生了异常情况：经确认，该服务器进行过VIP漂移操作。
5) 问题是否可以复现：测试环境中，对GPU服务器进行vip漂移操作，发现错误现象出现，问题可复现。
因此，问题的起因是GPU服务器进行了VIP漂移操作，导致算法出现异常。
2.调查问题
1) 了解vip原理，初步了解后，觉得可能是我们的算法缺少超时设置，因此算法中新增超时设置后，再次进行测试
备注：keepalived可以将多个无状态的单点通过虚拟IP(以下称为VIP)漂移的方式搭建成一个高可用服务，常用组合比如 keepalived+nginx，lvs，haproxy和memcached等。
它的实现基础是VRRP协议，包括核心的MASTER竞选机制都是在VRRP协议所约定的。
2）一轮测试发现：问题仍然存在，修复失败，且无新增日志。于是，我们要求增加日志信息，并以Debug方式启动算法，进行二轮测试。
3）二轮测试发现：问题仍然存在，出现新的错误日志，错误信息为：Connect error: No route to host(errno:113)。
百度一番，都说是server端的防火墙设置了过滤规则；但是，Server端并没有，怎么办？
Server端抓包：
经抓包发现，GPU服务器完成vip漂移需要耗时4s左右，然而，算法在漂移开始的2s内发送了近20次请求之后无请求。
问题的根源（可能）：Server端vip漂移未完成时，算法却发送了大量请求导致Server端的tcp连接池满，后续server端不再为其他请求分配资源。
3.解决问题
1）根据调查的原因，修复方法是：sever端在进行vip漂移完成前，尽量减少算法的请求次数，因此我们对该算法进行了超时重试次数的设置和请求间隔的设置（可配置）。
2）算法修复后经测试，问题解决。
三、总结
1）合理且重要的日志输出对于问题的定位和调查非常重要
2）涉及HTTP请求的问题调查时，服务端抓包有必要
3）Linux 的errno113问题并不一定是设置了防火墙导致的
备注：
（一）vip环境：用来给K8s做三节点高可用，被K8s的kubeproxy的ipvs方式转发到具体pod，四层转发，tcp协议（NAT模式）
（二）Linux errono命令