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