利用 DeepFlow 为传统 APM 开启全栈追踪能力 精华
传统 APM 聚焦在代码层面，不具备全栈多维度无盲点看问题的能力，同时由于插码的阻碍往往难以覆盖所有微服务，DeepFlow 依靠 eBPF 零代码修改采集全栈追踪数据并聚合生成了调用关系，可以增强传统 APM 的数据，大大缩短问题定界时间。对于已经使用传统 APM 工具的用户，可以考虑使用 DeepFlow 提供的 API 来增强应用依赖拓扑及调用追踪，以获得全栈数据追踪能力。
本文以 SkyWalking 为例从落地实现角度来描述，如何将在传统 APM 中集成 DeepFlow 的数据，增强传统 APM 数据能力， 主要从以下两个角度来：
- 依赖拓扑：增强查看某历史时间范围内服务（POD）到服务（POD）全栈路径拓扑以及全景上下游拓扑。
- 调用链追踪：增强查看某个应用 Span 对应系统 Span、网络 Span 时延消耗以及追踪未插码服务的能力。
开启下文的阅读之前，需要对 DeepFlow 目前已有的数据及术语有了解，下文默认读者都有一定的认知。
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/
实现过程够详细
展示的效果确实不错
下载了解下