Python Pixie 的无 Agent 观测尝试

pixie 不需要传统用户态 agent 即可采集指标，因其核心数据采集通过 ebpf 在内核态直接抓包和追踪系统调用，px-agent daemonset 仅为轻量控制面而非数据采集主体。

为什么 pixie 不需要 Agent 就能采集指标

因为 Pixie 的核心数据采集不依赖传统意义上的用户态 agent 进程，而是直接通过 eBPF 在内核态抓包和追踪系统调用。你看到的 px CLI 或 Web ui，只是查询已驻留内核的 Pixie 数据平面（px-deploy 部署后生成的 px-agent DaemonSet 实际是轻量控制面，不是数据采集主体）。

• eBPF 程序加载后常驻内核，只要 pod 有 NET_ADMIN 和 NET_RAW 权限就能运行，不需要长期存活的用户进程“盯着”流量
• px 命令执行时，是向集群中已部署的 px-control-plane 发起 gRPC 请求，再由它调度内核中的 eBPF 探针——不是在本地起一个代理再转发
• 如果你删掉所有 px-agent pod，px run 会失败；但只要 px-control-plane 和内核模块在，px get pods 这类元数据命令仍可工作

px run 报错 “No data found” 的真实原因

这不是采集没开，而是查询时间窗口或目标范围没对上。Pixie 默认只保留最近 2 小时的 trace 和网络流数据，且 eBPF 探针默认只 attach 到带 app.kubernetes.io/name 标签的 pod（或其他白名单 label），没标签的 pod 就像“隐身”了。

• 检查目标 pod 是否有 label：kubectl get pod -n <em>ns</em> <em>pod-name</em> -o jsonpath='{.metadata.labels}'，若为空，加个 app: demo 再试
• 确认时间范围：用 px run px/http_stats --since=5m 而不是默认的 --since=1h，避免查空窗口
• 注意命名空间隔离：px run 默认查当前 kubectl context 的 ns，跨 ns 必须显式加 -n <em>other-ns</em>

python SDK 调用 px API 时连接被拒

Pixie 的 Python SDK（pixie-python）默认连本地 localhost:50051，但它不启动 gRPC server——这个端口必须由 px serve 手动开启，而 px serve 又依赖你已登录（px login）且集群上下文可用。

• 别跳过 px login --Token=<em>your-token</em>，否则 px serve 启动后会报 failed to get cluster info
• Python 里不能直接 import pxapi 就发请求，得先后台跑 px serve --port=50051 &，再让 SDK 连过去
• SDK 初始化时若指定 px_url="http://localhost:50051"，实际走的是 gRPC over HTTP/2，不是 REST；填错协议或端口会抛 StatusCode.UNAVAILABLE

想绕过 Pixie 控制面自己读 eBPF 数据？别试了

Pixie 的 eBPF 程序做了深度定制：map 结构非标准、事件格式私有、ringbuf 消费逻辑耦合在 px-data-plane 中。你用 bpftool map dump 看到的是一堆十六进制 blob，没有 schema 文档，也没开放解析工具。

立即学习“Python免费学习笔记（深入）”；

• 社区版不提供 eBPF 字节码导出或 map schema 定义，所谓“无 agent”不等于“可自由接入”
• 有人尝试用 libbpf 加载 Pixie 编译出的 .o 文件，结果卡在 verifier 错误：invalid bpf_context access off=120 size=8——因为 Pixie 用了内核特定 patch 的 helper 函数
• 真要自研采集，建议直接用 libpcap 或 aiokafka 接 Pixie 导出的 OTLP endpoint，别碰内核层

真正难的不是怎么让 Pixie 跑起来，是怎么理解它把“采集”和“查询”拆成两个生命周期这件事——前者靠 eBPF 静默驻留，后者靠临时控制面按需拉取。漏掉这个前提，所有调试都会往错方向使劲。