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

本文为云杉网络原力释放 - 云原生可观测性分享会第十七期直播实录中的案例一。回看链接，PPT下载。

0x0: 背景介绍

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

01-nginx_access_log

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

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

02-topology

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

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

0x1: 排障过程

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 时延问题消失。

0x2: 问题总结

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

1
2
3
4
5
6
7
8
9

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），分钟级确定非网络时延瓶颈

0x3: 什么是 DeepFlow

DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。

GitHub 地址：https://github.com/deepflowio/deepflow

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