传统 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.83us02｜全栈门路拓扑-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_idFROM l7_flow_logWHERE 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 ZSELECT 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｜什么是 DeepFlowDeepFlow[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-inst...
[2] SQL 调用参考 DeepFlow 官网的线上文档: https://deepflow.io/docs/zh/server-integration/query/sql/
[3] DeepFlow 让 SkyWalking 分布式追踪无盲点: https://deepflow.io/blog/007-skywalking-distributed-tracing-w...
[4] DeepFlow: https://github.com/deepflowys/deepflow
[5] DeepFlow Demo: https://deepflow.yunshan.net/docs/zh/install/overview/