Lin Huanchao

@Fancyki1 您好， 1. 问题：打印的 EbpfType 日志中只看到 `EbpfTypeTracePoint, EbpfTypeTlsUprobe, EbpfTypeNone` 答：这应该是没有配置 `static_config.ebpf.uprobe-process-name-regexs.golang`，因此不会上报 uprobe 获取的 golang 程序的数据，所以 wasm 插件没有打印到 `EbpfTypeGoHttp2Uprobe, EbpfTypeGoHttp2UprobeDATA` 类型 2. 问题：“在解析http协议的req和resp发现http2的流量” 答：这是因为 deepflow-agent 在解析 http 和 http2 协议时给留的 wasm...

> EbpfTypeGoHttp2Uprobe @Fancyki1 您好，针对您的进展，有以下几个问题和回答： 1. **问题：** 没有 **EbpfTypeGoHttp2UprobeDATA** 数据 **答：** 这个问题，我不知道是不是您的代码中的省略部分有做什么过滤，导致在前面就过滤掉了，当然也不能排除是我们数据源侧没有传数据到 wasm 插件中，因为信息量比较少，我暂时不能判断 2. **问题：** 关于对 **EbpfTypeGoHttp2Uprobe** 和 **EbpfTypeGoHttp2UprobeDATA** 的理解 **答：** 可以看这里的说明：[EbpfType](https://github.com/deepflowio/deepflow/blob/main/agent/src/common/ebpf.rs#L58)，以及可以参考这几个链接，了解 golang uprobe 的 payload 的格式是如何的：[parseHeader](https://github.com/deepflowio/deepflow-wasm-go-sdk/blob/main/example/go_http2_uprobe/go_http2_uprobe.go#L150), [parseHeader](https://github.com/deepflowio/deepflow-wasm-go-sdk/blob/main/example/go_http2_uprobe/go_http2_uprobe.go#L173), [check_http2_go_uprobe](https://github.com/deepflowio/deepflow/blob/main/agent/src/flow_generator/protocol_logs/http.rs#L911)。对于 golang...

> 1 导致 painc 原因如下： 代码中些问题，比如下面这里如果还没赋值，可能会导致 panic。建议将错误处理完善一下，目前 wasm 插件发生 panic 会 trap 且无法捕获，所以需要自己预防一下 panic。 这个我们测试的时候也发现，现在是可能空指针的都做了判断。这里有个问题，在wasm 插件里面做defer 去捕获panic 不知道会不会生效，现在代码是这样写了 panic 不会被捕获，会直接 trap，所以还是要预防一下 panic

> exception 不省心，需要检查一下对应设置。 这个我们代码是没有设置OK，所以为了排查我们把response.Exception的值写到了属性里面的Exception，来做比较。看我上面的截图就发现Exception: error-, 但是 grafana上面显示的还是Ok 你好，我确认了一下，response_exception 确实是从插件赋值的。所以 grafana 里查到的 response_exception 应该是和 attributes 里的一致，是否 grafana 的 query 有改动呢？

@axnhhhh 您好，payload 的长度是跟 l7_log_packet_size 配置有关，看到您已经配置了，所以认为出现了分包的怀疑是合理的，确实是有可能如此。以下是几个排查思路和建议，供您参考: 1. payload 的长度可能还跟 agent-group-config 中的 [capture_packet_size](https://github.com/deepflowio/deepflow/blob/main/server/agent_config/example.yaml#L137) 配置有关，请确认是否有设置及设置是否足够长； 2. 也有可能是网络设置导致的，例如报文长度大于网卡 mtu 长度导致的分包，或者其他网关之类的设置导致的截断，请确认此类设置是否合理； 3. 为了验证 wasm 插件接收到的 payload 是否被截断，可以在 onResp 方法开头便打印 payload 的日志，以便调试，例如：`sdk.Info("on http resp payload_len: %d,...

> 您好，根据您提供的排查思路，进行了初步排查，暂并未定位到具体原因。 1、agent-group-config 中 capture_packet_size 未配置，使用的默认配置 2、mtu 1500 3、payload分包的场景中，payload长度不固定。有1500 的 4、另外发现还有粘包的情况，下图为wasm重打印的payload数据包  您好，如果是遇到了分包或者 http 分块，目前是可能会解析 json 失败，至于您提到的“粘包”问题，应该不是粘包，是因为日志打印过多而已。

> 感觉像key赋值的代码有bug: > > https://github.com/deepflowio/deepflow/blob/60d40f292c7d5255f8d4c907a071bf320591dc33/agent/src/flow_generator/protocol_logs/http.rs#L1421-L1429 > > > 解析出来的attribute_names的key小概率情况下会和value对应不上的情况： > key的取值应该取的是f.field_name的拷贝，而非一个Cow类型的key，或者key.to_owned().replace("-", "_"), > 期望解析出： > > ``` > attribute_names: ['rpc_service','xxx_code','xxx_msg'] > attribute_values: ['xxx.xx', 'xxx', '500', "xxx error"] > ``` >...