可观测性实战：快速定位 K8s 应用的时延瓶颈
摘要：本文分享了某物流公司使用DeepFlow平台快速定位Nginx网关时延瓶颈的实战案例。该公司发现特定域名在夜间持续出现1秒超时，传统APM追踪和监控数据均无法定位根因。通过DeepFlow的零侵扰调用日志，分析人员迅速排除了业务响应慢和网络延迟的可能性，将问题锁定在Nginx自身。进一步分析确认，瓶颈源于Nginx配置中使用HTTP/1.0协议。将其升级为HTTP/1.1后，超时问题立即消失。本案例突显了DeepFlow基于eBPF的全链路、多协议观测能力在复杂环境中快速、精准定位故障的价值。
关键词：DeepFlow、Nginx、可观测性、故障排查、时延瓶颈、零侵扰、物流行业
本文为云杉网络原力释放 - 云原生可观测性分享会第十七期直播实录中的【可观测性实战系列】“实战案例其一·物流行业篇”。回看链接[1]，PPT下载[2]。
一、背景介绍
本次案例为某物流公司在今年 4 月份左右，SRE 通过监控 Nginx 日志，发现一个域名在每天晚上 12 点后存在大量持续 1s 的超时情况，这个问题困扰了用户近一个月。通过查看 DeepFlow 的调用日志，立即排除了业务响应慢的可能性，最终发现问题是 Nginx 自身配置问题导致的。这个案例展示了如何快速的定位 7 层网关时延瓶颈点。
问题持续排查了近一个月，问题的阻塞点如下：
- 服务之间的访问关系复杂，插码（APM）形式追踪断路严重，无法直接确定瓶颈点所在位置
- 服务跨集群部署
- 部分服务内部通信即需要过 Nginx，又需要走 Ingress
- 服务通信涉及多协议，既有 HTTP 又有 Dubbo
- 现有监控数据除 Nginx 日志超时以外，无任何异常情况，问题推进无头绪
- 业务日志无 Error
- Nginx 其他业务无 Error、无超时
- Ingress 日志无 Error、无超时
- 业务实例基础指标无毛刺
- Ingress 监控指标无毛刺
- Nginx 监控指标无毛刺
SRE 偶尔一次与 DeepFlow 社区沟通过程中说到此问题，社区推荐使用 Request Log 试试，应该能快速回答瓶颈点在哪里，在此之前 DeepFlow 开源版已经在逐步覆盖的过程中，正好存在响应慢的业务被 DeepFlow 覆盖了，接下分享下借助 DeepFlow 排障的整个过程。
二、排障过程
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 3：追踪某次调用的网络流日志，确定网络是否存在时延瓶颈。从图中可以看出来，网络上的建连时延和系统时延都不高，因此可以确定与网络无关，仅看 Nginx 自身问题即可。
step 4：追踪问题根因
接下来转交给了 Nginx 运维同学来继续定位，最后通过修改 Nginx 配置，将此业务的 HTTP 协议从 1.0 改为 1.1 后，1s 时延问题消失。
三、问题总结
问：为什么 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），分钟级确定非网络时延瓶颈