app的/v1/stats/querier/L7FlowTracing接口返回的数据与grafana中显示的火焰图数据不一致

[xiaoyuan2019]

通过同一个_id从grafana deepflow-tracing看板和deepflow-app服务的/v1/stats/querier/L7FlowTracing接口返回的数据不一致。从grafana中看到只有一个span一个service，而通过app接口返回的数据有18个span3个service，并且有的span中的service_uid和service_uname为null，无法关联上下游关系，截图如下： 部署的deepflow-app是v6.5.9版本，操作系统版本： [root@localhost ~]# uname -a Linux localhost.localdomain 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7"

[taloric]

这里先看下 grafana f12 返回的数据是否和接口一致？确认下是渲染问题还是接口数据返回问题，一般不会有这种问题 service_uid / service_uname 在有些 span( signal_source = 0) 即 网络 span 里的数据是不会赋值的，因为“网络 span ”不认为归属于“某个服务”， 它是服务边界的 span

[xiaoyuan2019]

@taloric 感谢回复。 1、同一时间段同一个_id，在grafana上看到的span更多些，而通过app接口返回的数据少些，这个现象不是必现的； 2、请问如何根据app接口返回的火焰图信息组装成服务访问拓扑图？是根据parent_id、child_id还是req_tcp_seq和resp_tcp_seq，哪种方式更快更准？

[taloric]

@taloric 感谢回复。 1、同一时间段同一个_id，在grafana上看到的span更多些，而通过app接口返回的数据少些，这个现象不是必现的； 2、请问如何根据app接口返回的火焰图信息组装成服务访问拓扑图？是根据parent_id、child_id还是req_tcp_seq和resp_tcp_seq，哪种方式更快更准？

1. 这里描述的和 issue 图片提供的不一致？图片里说是 grafana span 少，接口多？

   • 如果不是必现，看下是否和查询参数里的时间有关？grafana 里应该是直接以界面右上角时间来查后端数据的，看下直接用接口是否这种方式？可能是此问题导致数据返回量差异

2. 没有更快、更准的对比，需要二者都加上才能得到【正确】的火焰图；可参考此文档 描述的构建过程，单独其中一种关联方式是不完整的。

[xiaoyuan2019]

@taloric 大佬，参考deepflow企业版这里的onetrace拓扑图，这里的拓扑图应该是直接通过火焰图数据转换过来的，火焰图数据是通过app的/v1/stats/querier/L7FlowTracing接口返回的，如果app中已有相关转换代码（火焰图span数据转换成拓扑图数据）的话，我是不是可以直接参考？具体转换代码位置还请发下，多谢！

[taloric]

@taloric 大佬，参考deepflow企业版这里的onetrace拓扑图，这里的拓扑图应该是直接通过火焰图数据转换过来的，火焰图数据是通过app的/v1/stats/querier/L7FlowTracing接口返回的，如果app中已有相关转换代码（火焰图span数据转换成拓扑图数据）的话，我是不是可以直接参考？具体转换代码位置还请发下，多谢！

这里比较特殊，这里是前端根据火焰图生成的，不是在后端生成的。

[taloric]

@xiaoyuan2019 如果需要实现类似的服务拓扑图，其实也不复杂，基于火焰图生成即可。火焰图里有服务与具体的父子关系，只需遍历一次返回结果，具有父子关系的 span 转换为服务（根据 service_uid/service_uname)，如果父子 span 是同一个服务，合并为一个即可

[xiaoyuan2019]

@taloric 我目前是这样做的：遍历结果，判断每个span中的parent_id和childs来生成访问关系，但是当有多个childs或tap_side为c和s时没有service_uid就会导致访问链路的缺失，是否可以判断每个span中的req_tcp_seq是否相等来确定访问关系呢？

[taloric]

@xiaoyuan2019 没有必要，本质上返回结果里已经根据 req_tcp_seq 进行过匹配、关联，再关联可能只会导致顺序错误； 对此类情况，我们一般的做法是忽略 c/s 的 span，只对有 service_uid 的 span 构建服务关系即可；（即以 signal_source=3/4 的数据作为基准） 如果一定要用 c/s 位置，可以粗略地这样划分：s 位置归属于它底下的 child（直到找到 signal_source=3/4 为止），反之 c 位置归属于它的 parent，同样向上遍历直到找到 signal_source=3/4

[xiaoyuan2019]

@taloric 大概明白了，这种onetrace拓扑图我们也不需要c/s位置，只要c-p和s-p就行，按照您的意思，遍历时直接去掉tap_side为c和s的span，那剩下的c-p和s-p怎么确定源和目的呢？虽然c-p是client，s-p是server，但是肯定有很多的c-p和s-p的。

[xiaoyuan2019]

@taloric 验证了下，从火焰图接口返回的数据遍历只保留信号源为3或4的span，然后再遍历3/4的span根据req_tcp_seq相等判断是否是同一个请求，如果是则c-p----->s-p，这样是不是可以？

[taloric]

@taloric 验证了下，从火焰图接口返回的数据遍历只保留信号源为3或4的span，然后再遍历3/4的span根据req_tcp_seq相等判断是否是同一个请求，如果是则c-p----->s-p，这样是不是可以？

对的，跨进程的 c-p ---> s-p 的关系是: tcp_seq 相等，或 s-p 的 parent_span_id = c-p span_id，或 x_request_id 相等

但反之，如果是一个进程的 s-p --> c-p ，则是 syscall_trace_id 相等；要注意下方向（从谁到谁）

可以参考这一节内容： https://github.com/deepflowio/deepflow-app/blob/main/HOW-TO-GET-SPAN-LIKE-DATA.md#%E7%94%9F%E6%88%90-processspanset

[xiaoyuan2019]

@taloric 意思是跨进程（c-p--->s-p）访问是tcp_seq相等，进程内（s-p--->c-p）的访问是syscall_trace_id 相等？那这两个在生成拓扑图时都要判断是吗？

[taloric]

@xiaoyuan2019 对的

[sunnyForshuine]

请问这个接口的参数是什么？是否可以不用传traceId？

[taloric]

@sunnyForshuine 可以参考 grafana 调用接口的代码 https://github.com/deepflowio/deepflow-gui-grafana/blob/main/deepflow-querier-datasource/pkg/plugin/datasource.go#L993-L999

[taloric]

@xiaoyuan2019 @sunnyForshuine 看起来此 issue 内无其他疑问，我先关闭此讨论，有问题的话可以随时重新打开 :)