Jiawei

> > 我们jaeger里有这个属性，不知道能不能满足  > > 需要明确`这个属性` 是【本机 ip】，还是【请求访问的服务端】或【来源的客户端】（对端） 如果确认这个信息是期望的对端，可以在 otel 里配置一个类似 https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/attributesprocessor 的转换器，把 attibute 从 ` 来源 attribute name` 复制到 span 下的 `net.peer.ip` 即可

@goobycle 不是乱码，存储里默认使用了 zstd 压缩，通过 `/v1/Profile/Profiletracing` 接口查询结果可见明文 如需要存储明文且不经压缩，通过此配置修改为空即可 https://github.com/deepflowio/deepflow/blob/main/server/server.yaml#L543 ``` ingester: ## profile compression algorithm, default is zstd, empty string for not compress profile-compression-algorithm: "" ```

在部署的 helm chart values-custom.yaml 文件中加上： ```yaml configmap: server.yaml: ingester: profile-compression-algorithm: '' ```

不用，但需要检查下修改是否生效，看下 ```bash kubectl get cm -n deepflow deepflow -o yaml | grep profile-compression-algorithm ``` 如果它是如下（即冒号后面无内容） ```yaml profile-compression-algorithm: ``` 估计是 helm chart 没渲染空字符串，可手动修改为： ```yaml profile-compression-algorithm: "" ```

@kill51216 > 1. 主要是想确认一下为什么会有sql语句在调用链路时缺失，是否可以通过配置改善（比如是否哪里的超时时间？） > 这个问题会和java 程序使用的是多线程并发&jdbc连接池操作mysql有关么？ 是的，程序内多线程可见[这个文档](https://deepflow.io/docs/zh/features/distributed-tracing/auto-tracing/) 的 #当前限制 中第一项说明，看下是否类似此场景（接收请求、向下游发送请求位于不同的线程） 可以看下[mysql](https://deepflow.io/docs/zh/features/l7-protocols/sql/#mysql) 文档，通过注释实现关联 > 2. 另外通过链路追踪api调用使用数据库中的(syscall_trace_id_response,syscall_tracd_id_request,req_tcp_seq)进行关联是否还有其他方式？ 分具体情况，如果是过 nginx 类网关可开启 x-request-id 能力串联网关出入 如果使用了 otel 一类的 apm 插桩可使用 trace_id 进行关联 > 3....

@yujianweilai 先看下 deepflow-app 的镜像版本（镜像 tag 即可）

> > @yujianweilai 先看下 deepflow-app 的镜像版本（镜像 tag 即可） > > @taloric > > registry.cn-beijing.aliyuncs.com/deepflow-ce/deepflow-app:v6.6.6 @yujianweilai ok，可以更新到 latest 看看，在下面这个 commit 里修了可能有环的问题，可以看看是否已修复 https://github.com/deepflowio/deepflow-app/commit/234374d5501c4af077b8e1767c6d09251b64c469

@yujianweilai 这里可以确认下是否左右两边的数据都是 OTel？且有同一个 trace_id？ 如果是这样， 应该就是两边（可能是两边服务过了多个不同的主机或集群）的时间差太大了，导致虽然有关联、但按真实时间显示相差较大

@yujianweilai 可以看看左下角的缩略图，粗看之下应该是从最初到最后的时间跨度有169s，此类情况可看下是否也是异步，一般而言：**如果整个链路都有同一个 trace_id，他们一定会渲染在一张火焰图上** ，如果发生了异步使得【正常业务已经结束】、【异步任务隔一段时间后才被调度，但同样会产生 trace_id】，那他们可能就会出现这种相隔很远但在一张图上的现象。 我看您截图的数据都是 OTel，看上去应该就是这个现象（都是一个 trace_id）

@yujianweilai 从您的这个截图来分析，初步看，**黄色的 span 是 ingress**，**蓝色的是 gateway**，**绿色的是后端应用** 且，空行之前没有做 OTel 插桩之类的行为（都是 S+N span），在到达 gateway 之后才开始发生插桩 此类情况一般而言原因是这样的： 空行的产生原因为空行的 【上下两行】没有明确的关联关系（如 parent_span_id => span_id），但又由于在上游注入了全局的 trace_id，使得虽然出现在一张图，但是上下无法关联（可以简单地理解为程序分析出了两个火焰图，但强行渲染在一起） 所以，解决这个问题只需要让空行上下有可用的关联关系即可。可以试试这样： 由于您在 **gateway** 之前的链路里也传入了 trace_id，可以用同样的方法传入 span_id，让 gateway 能集成 span_id 并生成...