传统 APM 聚焦在代码层面,不具备全栈多维度无盲点看问题的能力,同时由于插码的阻碍往往难以覆盖所有微服务,DeepFlow 依靠 eBPF 零代码修改采集全栈追踪数据并聚合生成了调用关系,可以增强传统 APM 的数据,大大缩短问题定界时间。对于已经使用传统 APM 工具的用户,可以考虑使用 DeepFlow 提供的 API 来增强应用依赖拓扑及调用追踪,以获得全栈数据追踪能力。
本文以 SkyWalking 为例从落地实现角度来描述,如何将在传统 APM 中集成 DeepFlow 的数据,增强传统 APM 数据能力, 主要从以下两个角度来:
-
依赖拓扑:增强查看某历史时间范围内服务(POD)到服务(POD)全栈路径拓扑以及全景上下游拓扑。
-
调用链追踪:增强查看某个应用 Span 对应系统 Span、网络 Span 时延消耗以及追踪未插码服务的能力。
开启下文的阅读之前,需要对 DeepFlow 目前已有的数据及术语有了解,下文默认读者都有一定的认知。
如果对 DeepFlow、eBPF、OpenCloudOS开源社区感兴趣,欢迎预约4月26日的线上直播《eBPF 技术落地实战:从可移植性到性能开销》,扫描下方二维码报名!
01|全栈路径拓扑-界面
增强查看某历史时间范围内服务(POD)到服务(POD)应用和网络指标量能力,可以快速回答在某一段时间内端到端路径是否存在瓶颈点,下面将结合 Skywalking 介绍产品 UI 界面如何融合
第一步:聚焦需要查看的路径(以下举例通过拓扑图路径点击,大家可以根据环境的实际情况来定义使用流程)
聚焦需要查看的路径
点击全栈路径拓扑
第二步:查看全栈路径拓扑(增强能力)
查看全栈路径拓扑
上图拓扑中每一个节点都对应一个统计位置(tap_side),统计位置的说明参考 DeepFlow 官网的线上文档[1],以客户端容器节点
举例说明具体的含义,表达是 cartservice 服务访问 redis-cart 服务,在 cartservice 对应 POD 所在的容器节点上采集到的访问数据,然后聚合的指标量。上图查看的指标量为响应时延
,不难看出瓶颈在服务端容器网络,判断过程如下:
- 客户端时延:④=204.31ms,为请求服务端的总时延,由以下几部分组成
-
客户端容器网络:路径①(也就是⑤-④),图中所示为38.14us
-
云网络:路径②(也就是⑥-⑤),图中所示为273.13us
-
服务端容器网络:路径③(也就是⑦-⑥),图中所示为204.25ms
-
服务端:即图中⑦,为372.83us
-
02|全栈路径拓扑-API
结合 API 看看如何实现,DeepFlow 的所有数据均可通过 SQL API 获取。
调用方输入客户端名称
、服务端名称
、指标量
以及时间范围
作为 API 的搜索条件即可获得全栈路径拓扑
数据。
第一步:获取 Skywalking 路径的客户端服务及服务端名称
,根据需求明确需要查看的指标量
及查看的时间范围
Skywalking 输入
第二步:查询 DeepFlow 获取应用/网络统计位置的数据,SQL 调用参考 DeepFlow 官网的线上文档[2]
SELECT Avg(`request`), /* 需要查看的指标量 */
pod_service_0, /* 客户端服务名称,客户端为 POD,则替换为 pod_0 */
tap_side,
pod_service_1 /* 服务端服务名称,服务端为 POD,则替换为 pod_1 */
FROM vtap_app_edge_port /* 查看应用指标使用 vtap_app_edge_port;查看网络指标切换到 vtap_flow_edge_port */
WHERE time>=1678760220 AND time<=1678762020 AND
pod_service_0='deepflow-server' AND /* 过滤客户端 */
pod_service_1='deepflow-server' /* 过滤服务端 */
GROUP BY pod_service_0,
tap_side,
pod_service_1,
第三步:根据返回数据绘制拓扑图
每个 tap_side 对应一个节点,节点根据 c-app/app/c-p/c/c-nd/c-hv/c-gw-hv/c-gw/local/rest/s-gw/s-gw-hv/s-hv/s-nd/s/s-p/s-app
从左到右排序,每个节点独立显示指标数据
。
03|全景上下游拓扑-界面
增强某节点查看全景上下游拓扑的能力,可快速发现未插码范围内被谁访问了(比如追踪上游的 Nginx 网关、安全策略未防住的访问等等),以及自身访问了谁,下面也将结合 Skywalking 介绍产品 UI 界面如何融合
第一步:聚焦需要查看的节点(以下举例通过拓扑图节点点击,大家可以根据环境的实际情况来定义使用流程)
点击全景上下游拓扑
第二步:查看全景上下游拓扑(增强能力)
查看全景上下游拓扑
上图为 tikcet-web 服务的全景上下游拓扑,其中 ① 是未插码的 ingress-nginx-controller 服务,表明 ticket-web 服务对外都是通过 ingress 来访问的,其中 ② 为未插码的 kube-dns 服务,经常访问服务慢,可能是因为 DNS 解析慢,而在应用拓扑是无法看出来此信息的。
04|全景上下游拓扑-API
调用方输入服务名称
、指标量
以及时间范围
作为 API 的搜索条件即可获得全景上下游拓扑
数据,需要两次调用的 DeepFlow API,分别获取到上游和下游的数据如下:
获取上游数据
SELECT Avg(`request`), /* 需要查看的指标量 */
pod_service_0, /* 客户端服务名称,客户端为 POD,则替换为 pod_0 */
tap_side,
pod_service_1 /* 服务端服务名称,服务端为 POD,则替换为 pod_1 */
FROM vtap_app_edge_port /* 查看应用指标使用 vtap_app_edge_port;查看网络指标切换到 vtap_flow_edge_port */
WHERE time>=1678760220 AND time<=1678762020 AND
pod_service_1='deepflow-server' /* 需要查看上游数据的服务 */
GROUP BY pod_service_0,
tap_side,
pod_service_1,
获取下游数据
SELECT Avg(`request`), /* 需要查看的指标量 */
pod_service_0, /* 客户端服务名称,客户端为 POD,则替换为 pod_0 */
tap_side,
pod_service_1 /* 服务端服务名称,服务端为 POD,则替换为 pod_1 */
FROM vtap_app_edge_port /* 查看应用指标使用 vtap_app_edge_port;查看网络指标切换到 vtap_flow_edge_port */
WHERE time>=1678760220 AND time<=1678762020 AND
pod_service_0='deepflow-server' /* 需要查看下游数据的服务 */
GROUP BY pod_service_0,
tap_side,
pod_service_1,
05|调用链追踪-产品
在开始介绍如何增强调用追踪的数据之前,先结合一张图说明一些后续要使用到的术语
数据介绍图
-
图中 A 表示应用 Span(来源传统 APM);S 表示网络 Span(来源 DeepFlow);N 表示网络 Span(来源 DeepFlow)
-
图中黑色部分为发起全栈调用追踪的的应用 Span,后续统称为
应用 Span Y
-
图中蓝色部分为通过
应用 Span Y
追踪的路径中的系统和网络 Span -
图中绿色部分为通过
应用 Span Y
追踪的下游未插码的 Span -
图中红色部分为通过
应用 Span Y
追踪的上游未插码的 Span
接下来将分别来讨论上图中蓝色/绿色/红色部分如何基于 SkyWalking 产品做 UI 融合(注:以下产品 UI 部分仅为示意图):
第一步:聚焦需要查看的应用 Span(以下举例通过点击 Span,大家可以根据环境的实际情况来定义使用流程)
聚焦需要查看的路径
点击全栈调用追踪
第二步:查看全栈调用拓扑(增强能力)
查看全栈调用拓扑
06|调用链追踪-API
接下来看下结合 DeepFlow 的 SQL API 如何实现,基于前面的术语介绍图,可知传统 APM 结合 DeepFlow 的数据来完成全栈调用追踪的能力,需要分蓝色、绿色和红色三部分来实现,接下来将分开介绍这三部分的数据实现。
蓝色部分:根据 应用 Span 的 TraceID + SpanID 追踪 DeepFlow 的系统 Span 和网络 Span,可以方便的查看某次调用在系统和网络分布消耗的时延,快速定界问题。可以通过 TraceID、SpanID 作为搜索条件获取 DeepFlow 的系统和网络 Span
蓝色部分-追踪图
SELECT response_duration,
start_time,
end_time,
resource_gl0_0, /* 客户端 */
resource_gl0_1, /* 服务端 */
tap_port_type, /* eBPF、NIC ... */
tap_port, /* NIC Name */
trace_id,
span_id
FROM l7_flow_log
WHERE trace_id = 'c5ad367da7ed41fc97921d91a0584bd8.63.16620935428909473' AND
span_id = 'e05ee7a06d674085a16dfea36ed11b98.169.16620935428971714-2' AND /* 非必须,精确搜索 */
time >= 1662093572 AND time <= 1662095372 /* 加速搜索 */
此部分的细节部分可以参考DeepFlow 让 SkyWalking 分布式追踪无盲点[3]。
红色部分:增强某个应用 Span 上游的 Span,对于插码范围以外(之前)的部分,例如追踪出来从未插码的客户端 Span
红色部分-追踪原理解释图
对于这部分数据的追踪,需要分几个步骤来逐一进行关联
-
① 根据
应用 Span Y
的 TraceID + SpanID 追踪 DeepFlow 的系统 Span,此时可能会得到多个系统 Span,只需要获取与应用 Span Y
紧邻的系统 Span X
继续往下追踪即可(可通过总时延最长来判断) -
② 获取
系统 Span X
的 syscall_trace_id_request 作为其他系统 Span 的搜索条件,得到系统 Span Z
SELECT response_duration, /* SELECT 字段可以根据需求自定义即可*/
l7_protocol,
Enum(request_type),
request_resource,
process_kname_0,
process_kname_1,
tap_side,
req_tcp_seq,
resp_tcp_seq,
Enum(auto_instance_type_0) AS `client_Enum(auto_instance_type_0)`,
auto_instance_0,
Enum(auto_instance_type_1) AS `server_Enum(auto_instance_type_1)`,
auto_instance_1,
FROM l7_flow_log
WHERE time>=1678764261 AND /*追踪开始时间,建议设置比系统 Span X 的开始时间早 3min*/
time<=1678767861 AND /*追踪结束时间,建议设置比系统 Span X 的结束时间晚 3min*//
(syscall_trace_id_request=16787489195430278) /* 16787489195430278 为 系统 Span Y 的 syscall_trace_id_request */
ORDER BY `end_time`
-
③ 获取
系统 Span Z
的 req_tcp_seq/resp_tcp_seq 作为其他系统 Span 和网络 Span 的搜索条件,得到网络 Span Z.1/Z.2 以及系统 Span Q
,此处逻辑特别注意:req_tcp_seq !=0 & resp_tcp_seq !=0 则需要同时满足 req_tcp_seq 和 resp_tcp_seq;如果其中一个为 0,则任意满足一个即可
SELECT response_duration, /* SELECT 字段可以根据需求自定义即可*/
l7_protocol,
Enum(request_type),
request_resource,
process_kname_0,
process_kname_1,
tap_side,
req_tcp_seq,
resp_tcp_seq,
Enum(auto_instance_type_0) AS `client_Enum(auto_instance_type_0)`,
auto_instance_0,
Enum(auto_instance_type_1) AS `server_Enum(auto_instance_type_1)`,
auto_instance_1,
FROM l7_flow_log
WHERE time>=1678764261 AND
time<=1678767861 AND
(type=2 AND
req_tcp_seq=3575241005 AND /* 3575241005 为系统 Span Z 的 req_tcp_seq*/
resp_tcp_seq=995863176) /* 995863176 为系统 Span Z 的 resp_tcp_seq*/
ORDER BY `end_time`
-
④ 接下来可继续追踪
系统 Span Q
的上游系统 Span,这里将分两种情况,如果上游的系统 Span 与系统 Span Q
在同一个线程,则重复步骤 [2]/[3] 即可,如果在不同线程/进程中,目前仅支持网关设置了 X-Request-ID 的情况下继续追踪,获取系统 Span Q
的 x-request-id 作为查询其他系统 Span 和网络 Span 的搜索条件,得到其上游的系统 Span M
SELECT response_duration, /* SELECT 字段可以根据需求自定义即可*/
l7_protocol,
Enum(request_type),
request_resource,
process_kname_0,
process_kname_1,
tap_side,
req_tcp_seq,
resp_tcp_seq,
Enum(auto_instance_type_0) AS `client_Enum(auto_instance_type_0)`,
auto_instance_0,
Enum(auto_instance_type_1) AS `server_Enum(auto_instance_type_1)`,
auto_instance_1,
FROM l7_flow_log
WHERE time>=1678764261 AND
time<=1678767861 AND
x_request_id=6e903947-5ef0-4c63-91a8-a2a599171633 /* 6e903947-5ef0-4c63-91a8-a2a599171633 为系统 Span Q 的 x_request_id*/
ORDER BY `end_time`
-
⑤ 到此,已经根据上述步骤追踪得到所有的上游 Span,接下来将确定父子关系,可直接根据总的响应时延,按从大到小降序排列即可
绿色部分:增强某个应用 Span 下游的 Span,对于插码范围以外(之后)的部分追踪,例如追踪出来未插码的服务端 Span(DNS),此追踪过程与红色部分
非常相似,仅步骤 ② 中的syscall_trace_id_request
换成syscall_trace_id_response
即可,此处不在赘述。
绿色部分-追踪图
07|什么是 DeepFlow
DeepFlow[4] 是一款开源的高度自动化的可观测性平台,是为云原生应用开发者建设可观测性能力而量身打造的全栈、全链路、高性能数据引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技术,创新的实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心机制,帮助开发者提升埋点插码的自动化水平,降低可观测性平台的运维复杂度。利用 DeepFlow 的可编程能力和开放接口,开发者可以快速将其融入到自己的可观测性技术栈中。
GitHub 地址:https://github.com/deepflowys/deepflow
访问 DeepFlow Demo[5],体验高度自动化的可观测性新时代。
参考资料
[1] 统计位置的说明参考 DeepFlow 官网的线上文档: https://deepflow.io/docs/zh/auto-metrics/metrics-without-instrumentation/
[2] SQL 调用参考 DeepFlow 官网的线上文档: https://deepflow.io/docs/zh/server-integration/query/sql/
[3] DeepFlow 让 SkyWalking 分布式追踪无盲点: https://deepflow.io/blog/007-skywalking-distributed-tracing-without-blind-spots/#0x1-DeepFlow-SQL-API
[4] DeepFlow: https://github.com/deepflowys/deepflow
[5] DeepFlow Demo: https://deepflow.yunshan.net/docs/zh/install/overview/