本文分享借助 DeepFlow 在某头部劵商业务压测场景中通过调用链追踪快速定位问题的过程。解决在容器云内等复杂调用场景中解决传统监控手段覆盖不全面、排障定位无手段等痛点。分享利用 DeepFlow 如何快速在复杂的业务调用过程中抽丝剥茧,快速排除网络问题,定位Pod服务自身业务逻辑问题,展现 DeepFlow 产品价值。
背景介绍
某头部券商OCR识别业务压测多个后端服务Pod时,偶发性业务响应时延高问题,当出现故障时集中某一Pod出现时延3s以上,其他Pod业务响应正常。
客户在内部已经建立了多套容器环境,随着业务规模的增长和技术架构的演进,也面临了若干运维痛点:
• 基础设施监控手段限制导致的排障困难:由于无法采用实时插庄监控全栈链路,基础设施团队不得不依赖日志分析来逐步排查问题,这种方法显著延长了故障诊断的时间。
• 监控数据粒度不足导致追踪能力受限:现有的传统埋点技术提供的监控数据过于粗略,难以实现对基础服务、云组件和网络调用的深入追踪,影响了问题定位的准确性。
• 云原生环境下的网络诊断难题:在复杂的云原生环境中,Kubernetes的内置诊断工具效率不高,缺乏专门针对网络问题的高效诊断工具,导致问题解决缓慢。
本次案例的业务请求路径为:客户端——>Nginx Host——>Nginx-Ingress Pod——>负载多个OCR Pod副本
DeepFlow 分析定位之前,此问题一直为一个悬案,持续了数天无结论:
• ingress设置rr模式,但压测试时其中一个pod请求数量更多
• 从pod 日志响应时长来看,4个pod 会集中这一个pod出现3s以上请求耗时
• ingress改为最小连接,就不会出现集中一个pod请求数量更多的情况
排障过程
拨云见日:快速定位问题
step 1: 利用 DeepFlow 网络-拓扑分析的主要指标,快速排除容器网络问题
根据拓扑网络指标,查看链路上TCP建连,重传比例,失败比例,建连时延等都是正常范围,排除容器网络问题。
step 2: 利用 DeepFlow 追踪-拓扑的响应时延指标量,确定是应用层响应时延高,并找到时延高的POD
无论ingress设置rr或者最小连接,根据追踪拓扑页面中服务的时延指标数据,都发现ingress和某个pod时延高的情况。但实际每个pod请求数量是一样的,都是675个左右请求数,说明无ingress配置无关。
抽丝剥茧:快速定位原因
step 3: 利用 DeepFlow 调用链追踪功能,确定时延出在服务端POD调用本地服务无响应导致
根据调用日志按照时延排序,选出最高时延的调用日志。如下图,从ingress到ocr pod 总耗时5.29s ,其中pod向本地5001 请求资源/ocr/id_card耗时3.12s和 /ocr/kie耗时2.15s。
查看同一个pod正常时延的的调用日志。如下图,从ingress到ocr pod 总耗时1.08s ,其中pod向本地 localhost:5001端口 请求资源/ocr/id_card耗时699.44ms和 /ocr/kie耗时350.41ms。查看多个类似调用日志总结出,出现本地服务返回给pod信息时,时延正常。
通过以上三步快速得出结论,ingress设置负载均衡模式问题并未得到复现,每次更改最小连接或RR模式,并不影响调度均衡。在本案例中并不是导致时延的根因。而是某个节点POD调用本地 localhost:5001端口请求资源时,未返回信息导致时延。
价值总结
DeepFlow 在整个案例的价值点是什么?
• 利用 DeepFlow 零插码的网络路径,分钟级排除容器网络的问题。
• 利用 DeepFlow 零插码的调用追踪,分钟级确定服务逻辑的根因。