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

2024-08-20 00:02:56 4

本文为云杉网络原力释放 - 云原生可观测性分享会第十七期直播实录中的【可观测性实战系列】“实战案例其一·物流行业篇”。回看链接[1]，PPT下载[2]。

“可观测性实战”系列前瞻：

01｜案例一：快速的定位7层网关时延瓶颈点。

02｜案例二：快速的定界云服务与应用时延瓶颈点。

03｜案例三：云原生环境下，快速定位访问瓶颈。

01｜背景介绍

本次案例为某物流公司在今年 4 月份左右，SRE 通过监控 Nginx 日志，发现一个域名在每天晚上 12 点后存在大量持续 1s 的超时情况，这个问题困扰了用户近一个月。通过查看 DeepFlow 的调用日志，立即排除了业务响应慢的可能性，最终发现问题是 Nginx 自身配置问题导致的。这个案例展示了如何快速的定位 7 层网关时延瓶颈点。

01-nginx_access_log

问题持续排查了近一个月，问题的阻塞点如下：

服务之间的访问关系复杂，插码（APM）形式追踪断路严重，无法直接确定瓶颈点所在位置服务跨集群部署部分服务内部通信即需要过 Nginx，又需要走 Ingress服务通信涉及多协议，既有 HTTP 又有 Dubbo

02-topology

现有监控数据除 Nginx 日志超时以外，无任何异常情况，问题推进无头绪业务日志无 ErrorNginx 其他业务无 Error、无超时Ingress 日志无 Error、无超时业务实例基础指标无毛刺Ingress 监控指标无毛刺Nginx 监控指标无毛刺

SRE 偶尔一次与 DeepFlow 社区沟通过程中说到此问题，社区推荐使用 Request Log 试试，应该能快速回答瓶颈点在哪里，在此之前 DeepFlow 开源版已经在逐步覆盖的过程中，正好存在响应慢的业务被 DeepFlow 覆盖了，接下分享下借助 DeepFlow 排障的整个过程。

02｜排障过程

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

03-request_log

step 2: 聚焦一个时间段，利用调用日志的客户端/服务端，分析上下游

首先，利用调用日志的客户端作为服务端，追踪上游服务是否存在影响，可发现上游服务的时延在增加，因此可分析出来，上游服务时延的增加是由当前服务造成的，需要继续聚焦分析当前服务及下游服务是否存在瓶颈。

04-request_log_client

假设目前分析服务svc_a访问 Nginx 这一段的调用情况，将刚刚分析的数据绘制为拓扑图来看，将svc_a作为服务端，查看访问svc_a的客户端svc_b这条路径的延迟情况，结果显示延迟达到了1.5秒。因此，我们可以得出结论，目前的延迟问题很可能是由 Nginx 或者 Nginx 下游的服务引起的。

05-topology_client

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

06-request_log_server

07-topology_server

step 3：追踪某次调用的网络流日志，确定网络是否存在时延瓶颈。从图中可以看出来，网络上的建连时延和系统时延都不高，因此可以确定与网络无关，仅看 Nginx 自身问题即可。

08-flow_log

step 4：追踪问题根因

接下来转交给了 Nginx 运维同学来继续定位，最后通过修改 Nginx 配置，将此业务的 HTTP 协议从 1.0 改为 1.1 后，1s 时延问题消失。

03｜问题总结

问：为什么 Nginx 中配置的 HTTP 协议从 1.0 改为 1.1 时延就消失了？因为笔者和运维同学都未对 HTTP 协议有特别深入的了解，以下为 ChatGPT 的回复，供大家参考。

HTTP 1.1 相较于 HTTP 1.0，引入了多个性能优化方面的改进，包括： 1. 持久连接：HTTP 1.1 支持在同一个TCP连接上发送多个HTTP请求和响应，减少了连接的建立和关闭次数，提高了性能和效率。 2. 流水线传输：HTTP 1.1 可以同时发送多个请求，而无需等待每个请求的响应返回，降低了网络通信的延迟，加快了数据传输速度。 3. 分块传输编码（Chunked Transfer Encoding）：HTTP 1.1 可以将响应消息分成多个块进行传输和接收，提供了更快的响应时间，特别适用于大型或动态生成的内容传输。 4. 请求管线化（Request pipelining）：在不等待响应返回的情况下，连续发送多个请求，减少了等待时间和网络延迟，提高了效率。 5. 缓存控制：HTTP 1.1 引入了更丰富的缓存控制机制，例如ETag、Cache-Control头部字段等，可以实现更精确的缓存控制，减少了对服务器的请求，提高了性能。这些性能优化的改进使得HTTP 1.1相较于HTTP 1.0具有更好的性能和效率，提供了更快速、可靠的数据传输和网络通信。

问：DeepFlow 在整个案例的价值点是什么？

利用零插桩的调用日志（Request Log），分钟级锁定时延瓶颈点利用零插桩的流日志（Flow Log），分钟级确定非网络时延瓶颈

04｜什么是 DeepFlow

DeepFlow[3] 开源项目旨在为复杂的云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了零插桩（Zero Code）、全覆盖（Full Stack）的指标、追踪、日志采集，并通过智能标签技术实现了所有观测数据的全关联（Universal Tagging）和高效存取。使用 DeepFlow，可以让云原生应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。

GitHub 地址：

https://github.com/deepflowio/deepflow

访问 DeepFlow Demo[4]，体验零插桩、全覆盖、全关联的可观测性。