“服务怎么又超时了用户全在投诉”某天上午我们的核心数据推送服务负责处理来自立达标讯的实时政策数据流突然出现大面积请求超时P99延迟从50ms飙升至5s以上且持续了数小时没有恢复。更诡异的是服务器CPU、内存、磁盘IO全部正常。监控显示只有部分请求超时另一部分请求正常。排查过程从“应用层”到“网络层”的逐步回退第一阶段怀疑应用层代码检查了应用日志无异常。检查了数据库连接池连接数正常。检查了缓存命中率无变化。第二阶段怀疑网络问题检查了服务间网络延迟RTT正常。排除了网络抖动。第三阶段定位到DNS在超时的请求中我们发现所有超时请求都涉及对外部服务的调用。进一步分析发现这些调用在建立连接时耗时极长。最终定位到DNS解析超时。根因深挖一个被“忽视”的DNS配置我们使用dig和nslookup测试了DNS解析发现解析时间波动极大有时正常10ms有时超时5s。问题分析我们的服务运行在Kubernetes集群中Pod的/etc/resolv.conf中配置了多个DNS服务器。默认情况下DNS解析器会依次尝试每个DNS服务器直到获得响应。但我们的配置中第一个DNS服务器一个已下线的旧DNS仍然存在。当它无法响应时解析器会等待超时默认5秒然后才尝试下一个DNS服务器。这导致了部分请求因等待第一个DNS超时而延迟。修复方案移除无效的DNS服务器并优化DNS解析配置。bash# 查看当前DNS配置 cat /etc/resolv.conf # 修正后的配置移除无效DNS并设置合理的超时和重试次数 nameserver 10.96.0.10 nameserver 8.8.8.8 options timeout:2 attempts:2效果修复后DNS解析时间稳定在10ms以内服务超时问题消失。教训与启示这次事故让我们深刻认识到DNS是“隐形的性能杀手”。DNS解析失败或超时会导致所有依赖它的调用变慢。理解resolv.conf的配置nameserver的顺序、timeout和attempts参数都会影响DNS解析的性能。监控DNS解析时间建立对DNS解析时间的监控是发现此类问题的关键。