[BUG] agent standalone模式下ebpf采集不生效

[qyzhaoxun]

Search before asking

• [X] I had searched in the issues and found no similar feature requirement.

DeepFlow Component

Agent

What you expected to happen

standalone模式下agent ebpf采集器也能正常工作，将flow_log写入l7_flow_log

How to reproduce

在k8s环境下直接部署deepflow-agent daemonset，deepflow-agent容器启动后，在/var/log/deepflow-agent/目录正常生成l4_flow_log和l7_flow_log，不过l7_flow_log signal_source只有Packet，没有ebpf

部署yaml信息: deepflow-agent.yaml.txt

DeepFlow version

9935-cfb3560378f755d37bb9b9c1e41305483b0eff4e Name: deepflow-agent community edition Branch: v6.5.3 CommitId: cfb3560378f755d37bb9b9c1e41305483b0eff4e RevCount: 9935 Compiler: rustc 1.75.0 (82e1608df 2023-12-21) CompileTime: 2024-03-27 02:15:14

DeepFlow agent list

No response

Kubernetes CNI

deepflow-agent是以hostnetwork方式运行在tke集群上

Operation-System/Kernel version

"Ubuntu 22.04 LTS" 5.15.0-94-generic

Anything else

deepflow-agent 日志

deepflow-agent.log

Are you willing to submit a PR?

• [ ] Yes I am willing to submit a PR!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[lzf575]

@qyzhaoxun 本地看了下，有ebpf的数据。 你确认下，ebpf需要 kernel 版本大于 4.14+ 才支持。也看下有没有'ebpf collector init' 日志 把deepflow-agent.log 日志文件也发下

[qyzhaoxun]

kernel版本上面提供了，agent的日志以及部署方式都提供了的，可以看下

[sharang]

@yinjiping 看看 issue 正文中的 deepflow log 文件。里面有一些奇怪的 ebpf detach

[yinjiping]

@qyzhaoxun 您好，我看日志没发现什么异常。 可执行下面命令（来看看数据统计）进行确认：

• 进入POD

kubectl exec deepflow-agent-sgm5p -n deepflow -it -- bash

• 查询统计

root@deepflow-agent-sgm5p:/# deepflow-ebpfctl tracer show
Tracer             socket-trace
Bpf buffer         socket-trace-bpf-linux-common
Workers            1
Perf-Pages-Count   128
Events Lost        0
Probes Count       6
State              TRACER_RUNNING
Adapt              1
data_limit_max     1024

-------------------- Queue ---------------------------
worker 0 for queue, de 68 en 68 lost 0 alloc failed 0 burst 7325125 queue size 0 cap 65535

SUM dequeue 68 enqueue 68 lost 0 alloc failed 0 burst count 7325125

-------------------- Protocol ------------------------
- Unknown   (0) 1822436
- HTTP1     (20) 2122072
- HTTP2     (21) 1213292
- Dubbo     (40) 2
- MySQL     (60) 125647271
- PgSQL     (61) 3690
- Redis     (80) 42822
- MongoDB   (81) 1840
- MQTT      (101) 981
- AMQP      (102) 6004204
- DNS       (120) 2503711
- TLS       (121) 422145

多次执行上面的命令，如果上面各个协议的数据统计大于0并且多次执行观察是递增的，说明eBPF获取数据正常。

可主动产生些事件让eBPF捕获， 例如在节点上执行：curl www.baidu.com （观察HTTP1统计变化）

[qyzhaoxun]

感谢，这块使用v6.4可以看到ebpf正常工作，并且能将http/dns协议采集到并且成功落盘，但是https和http2协议采集不到，怀疑是不是类似问题

deepflow-agent配置文件 配置文件下能看到针对kube-proxy-bin确实hook了相关uprobe函数 但是l7_flow_log下一直没有看到对应https的日志 另外使用deepflow-ebpfctl tracer show没有看到TLS/HTTP2有增加

[sharang]

@yuanchaoa 来继续看看，并确认 standalone 和普通模式差异点在哪些环节，确认是否还有其他问题。

[yinjiping]

@qyzhaoxun 您好，确认下下面这些类型符号是否存在：

go:itab.*net.TCPConn,net.Conn
go:itab.*crypto/tls.Conn,net.Conn
go:itab.*golang.org/x/net/http2/h2c.rwConn,net.Conn
go:itab.*golang.org/x/net/http2/h2c.bufConn,net.Conn
go:itab.*github.com/armon/go-proxyproto.Conn,net.Conn
go:itab.*google.golang.org/grpc/internal/credentials.syscallConn,net.Conn

eBPF会利用上面这些类型符号地址，进行conn的判断来获取必要的数据。(怀疑上面符号的名字在kube-proxy-bin中存在差异)

nm /proc/518263/root/usr/local/bin/kube-proxy-bin | grep "Conn,net.Conn"

[qyzhaoxun]

nm: /proc/615963/root/usr/local/bin/kube-proxy-bin: no symbols 这样是表明支持不了吗？

[yinjiping]

@qyzhaoxun 是的，没有符号表，就没有办法了这是个前提条件， 如果 Golang version >= 1.13 and < 1.18，可尝试配置： golang-symbol: 试试，但是遗憾的是kube-proxy-bin的版本显示是1.20

[qyzhaoxun]

不过上面日志不是显示的INFO Uprobe了一些函数吗？这个是实际上没有uprobe成功啊

[sharang]

不过上面日志不是显示的INFO Uprobe了一些函数吗？这个是实际上没有uprobe成功啊

这个日志打印的不合理，图中的 nil 实际上是一个失败的行为，我们会改为 Warning 并给出明确的失败说明

[yinjiping]

不过上面日志不是显示的INFO Uprobe了一些函数吗？这个是实际上没有uprobe成功啊

这个是不是有配置配置项golang-symbol: ?，它尝试一把解析，但是最终还是没有把go:itab.*net.TCPConn,net.Conn解析出来。