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-agentpod，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 静默驻留，后者靠临时控制面按需拉取。漏掉这个前提，所有调试都会往错方向使劲。
