可观测性实战：从拨云见日到抽丝剥茧快速定位业务响应时延高问题 原创

本文分享借助 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 零插码的调用追踪，分钟级确定服务逻辑的根因。