可观测性实战：快速定位云服务时延瓶颈

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

0x0: 背景介绍

本次案例为某智能汽车公司，业务监控告警发现某充电核心服务 SQL 查询时间偶现超过 200ms，对前方用户影响明显。此问题涉及多团队，仅问题定位就持续了将近 1 个星期未有结论，通过 DeepFlow 的调用日志及分布式调用链追踪的能力，快速定位瓶颈点为云网络抖动导致的，进而直接向云厂商提交工单并附带令人信服的证据。

01-alarm

问题的阻塞点：由于业务访问的数据库是云上的 RDS，因此在问题排查过程中涉及多个团队（业务开发/业务运维/DBA/容器运维），各个团队各执其词。主力推动由业务运维主导，但是因为没有更多证据，也难以推动工单：

• 业务团队：提供的 APM 追踪图，认为业务侧无时延瓶颈
• DBA 团队：提供监控指标 + 慢日志，未发现任何异常
• 容器团队：提供 Node 监控数据，未发现任何异常
• 云服务厂商：认为无足够证据确认问题是他们的，不接工单

02-APM

下面的拓扑图，展示了业务的调用关系，业务 Pod 发出 SQL 请求，通过 Node 转发，然后访问云服务 RDS。

03-topo

0x1: 排障过程

Step 1：利用调用日志，确定访问的 RDS 云服务对应的 IP 地址

业务访问 RDS 是通过域名访问，在 DeepFlow 平台需要对应到具体的 IP 来查询，首先，利用调用日志中的 DNS 调用日志页面，找到对应域名解析的 IP 地址。

04-dns

Step 2：利用调用日志，确定存在的 SQL 查询响应慢的情况

在 DeepFlow 的调用日志查询对应的 SQL 查询语句，发现确实存在响应慢的情况。分析这部分数据过程中，额外观测到业务 SQL 慢的告警阈值可以再下调，先结合P99响应时延，发现正常响应时延都在 2ms 之内，将此现象与业务部分反馈后，业务部门综合考虑下来，将告警的时延阈值调整到了到 100ms，更好的优化用户的体验。

05-sql

Step 3：利用调用日志中的tap_side（统计位置），确定时延瓶颈点

再利用 DeepFlow 的tap_side字段，来对比分析时延数据，进一步锁定瓶颈范围。

可以在下图中清楚一次 SQL 调用的时延数据，在①/②两个位置统计到了，①为业务 Pod 网卡统计的时延；②为 Node 网卡统计（因为存在 SNAT 情况，所以也没显示的也是客户端网卡）的时延，可以看出①和②时延相差不大，因此可确定 Pod 到 Node 这一段是时延消耗非常低，可以确定时延瓶颈和容器平台是无关的。

06-tap_side

07-topo

Step 4：结合网络的传输-失败指标量，进一步定位问题应该在 RDS 前面的云网部分

进一步分析偶现 SQL 时延高时间点的网络指标，发现存在传输-失败的情况，可以进一步确定应该是云网络存在问题，导致 SQL 时延增加。到此，证据已经足够可给云厂商提工单了。

07-metrics

Step 5：追踪问题根因

云厂商最后反馈的问题根因，为 RDS 集群前面的 LB 集群在并发数特别大的情况时候，会对 LB 集群的会话做迁移，故而导致会话抖动，增加了业务侧查询 RDS 的时延。

0x2: 问题总结

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

• 利用 DeepFlow 零插桩的 DNS 调用日志，分钟级确定域名对应的 IP
• 利用 DeepFlow 零插桩的 MySQL 调用日志，分钟级查找响应慢的调用
• 利用 DeepFlow 零插桩调用日志的tap_side，分钟级的定位响应瓶颈点
• 利用 DeepFlow 零插桩的网络指标，分钟级确定传输失败异常

0x3: 什么是 DeepFlow

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

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

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