可观测性实战：快速定位 K8s 应用的时延瓶颈

在 K8s 应用中快速定位时延瓶颈，可通过分析调用日志、上下游服务依赖、网络流日志并结合协议特性调整实现，DeepFlow 等工具可显著提升排查效率。具体实战过程如下：

背景介绍

某物流公司 SRE 发现某域名在每天晚上 12 点后存在大量持续 1s 的超时情况，持续近一个月。通过查看 DeepFlow 的调用日志，排除了业务响应慢的可能性，最终确定是 Nginx 自身配置问题导致。问题排查的阻塞点如下：

服务访问关系复杂
服务跨集群部署。
部分服务内部通信既需要过 Nginx，又需要走 Ingress。
服务通信涉及多协议，既有 HTTP 又有 Dubbo，插码（APM）形式追踪断路严重，无法直接确定瓶颈点所在位置。
现有监控数据无异常
业务日志无 Error。
Nginx 其他业务无 Error、无超时。
Ingress 日志无 Error、无超时。
业务实例基础指标无毛刺。
Ingress 监控指标无毛刺。
Nginx 监控指标无毛刺，问题推进无头绪。

排障过程

Step 1：利用调用日志（Request Log）确定超时情况输入 url（request_resource 字段），从趋势图可知与 Nginx 日志反馈的情况一致，确认超时情况存在。

Step 2：聚焦时间段，分析上下游服务
追踪上游服务：利用调用日志的客户端作为服务端，追踪上游服务是否存在影响。发现上游服务时延增加是由当前服务造成的，需继续聚焦分析当前服务及下游服务是否存在瓶颈。例如分析服务 svc_a 访问 Nginx 的调用情况，将 svc_a 作为服务端，查看访问 svc_a 的客户端 svc_b 这条路径的延迟情况，结果显示延迟达到 1.5 秒，初步判断延迟问题可能由 Nginx 或者 Nginx 下游的服务引起。

- 追踪下游服务：利用调用日志的服务端作为客户端，不停迭代追踪下游服务。发现 Nginx 往下的服务响应都非常快，基本为 25ms 左右的时延，锁定时延瓶颈是 Nginx 造成的。

Step 4：追踪问题根因转交给 Nginx 运维同学继续定位，最后通过修改 Nginx 配置，将此业务的 HTTP 协议从 1.0 改为 1.1 后，1s 时延问题消失。

问题总结

HTTP 协议版本影响时延的原因HTTP 1.1 相较于 HTTP 1.0，引入了多个性能优化方面的改进，包括：
持久连接：HTTP 1.1 支持在同一个 TCP 连接上发送多个 HTTP 请求和响应，减少了连接的建立和关闭次数，提高了性能和效率。
流水线传输：HTTP 1.1 可以同时发送多个请求，而无需等待每个请求的响应返回，降低了网络通信的延迟，加快了数据传输速度。
分块传输编码（Chunked Transfer Encoding）：HTTP 1.1 可以将响应消息分成多个块进行传输和接收，提供了更快的响应时间，特别适用于大型或动态生成的内容传输。
请求管线化（Request pipelining）：在不等待响应返回的情况下，连续发送多个请求，减少了等待时间和网络延迟，提高了效率。
缓存控制：HTTP 1.1 引入了更丰富的缓存控制机制，例如 ETag、Cache-Control 头部字段等，可以实现更精确的缓存控制，减少了对服务器的请求，提高了性能。
DeepFlow 在整个案例的价值点
利用零插桩的调用日志（Request Log），分钟级锁定时延瓶颈点。
利用零插桩的流日志（Flow Log），分钟级确定非网络时延瓶颈。

关于 DeepFlow

项目定位：DeepFlow 开源项目旨在为复杂的云原生应用提供深度可观测性。
技术实现：基于 eBPF 实现了零插桩（Zero Code）、全覆盖（Full Stack）的指标、追踪、日志采集，并通过智能标签技术实现了所有观测数据的全关联（Universal Tagging）和高效存取。
应用价值：使用 DeepFlow，可以让云原生应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。
相关资源
GitHub 地址：
https://github.com/deepflowio/deepflow
DeepFlow Demo：
https://deepflow.io/docs/zh/install/overview/
，可体验零插桩、全覆盖、全关联的可观测性。

热门标签