Pixie
SandboxObservabilityPixie is an open source Kubernetes observability tool that uses eBPF to auto-instrument applications running in a cluster, capturing telemetry (HTTP/gRPC traffic, MySQL/Postgres queries, DNS, network flows, resource usage) without requiring
What it is
Pixie is an open source Kubernetes observability tool that uses eBPF to auto-instrument applications running in a cluster, capturing telemetry (HTTP/gRPC traffic, MySQL/Postgres queries, DNS, network flows, resource usage) without requiring code changes, sidecars, or manual instrumentation. Data is collected and stored in-cluster (via Vizier, Pixie's collector/query engine), which keeps raw telemetry local rather than shipping everything to a remote backend by default. Query interface is PxL, a Python-like DSL for slicing collected data.
Who builds it and why
Pixie originated at New Relic, which acquired the founding team (Pixie Labs) in 2020 and donated the project to CNCF in 2021, where it currently sits in the sandbox stage. New Relic remains the primary corporate sponsor. The GitHub activity (6,474 stars, 90 contributors, last commit June 2026) shows the project is alive, but sandbox status plus a slow-moving release cadence (latest tagged release is v0.1.9) signals this is not a fast-iterating, heavily-resourced project compared to graduated CNCF tools like Prometheus or OpenTelemetry.
Production readiness signal
Sandbox-level CNCF maturity is the honest headline here — this is the earliest stage of CNCF's maturity ladder, meaning the project hasn't yet demonstrated the adoption breadth, governance rigor, or security audit trail required for incubation or graduation. A version number stuck at 0.1.x after years of existence is also a signal worth weighing: either the release process is unusual (cloud vs. OSS versioning split) or the project isn't moving toward a stable 1.0 API/data-contract commitment. 90 contributors and continued commits indicate it's not abandoned, but you should treat this as "actively maintained sandbox project," not "battle-tested production standard." eBPF-based tooling also carries kernel-version and node-compatibility caveats that need validation per-cluster before you rely on it operationally.
Who should use this
- Teams that want deep request/query-level visibility (HTTP, gRPC, SQL) into services without instrumenting every application — especially useful for polyglot environments where adding SDKs to every service is a slog.
- Platform/SRE teams doing incident triage who want ad-hoc, script-like querying (PxL) over live cluster data instead of pre-built dashboards.
- Orgs already using New Relic that want a complementary in-cluster, low-overhead debugging layer.
- Developers who want a "zero instrumentation" way to explore what a Kubernetes service is actually doing at the network/syscall level, particularly for debugging, not for long-term metrics storage.
Who should NOT use this
- Anyone needing long-term metrics retention or a system-of-record observability backend — Pixie is designed around short-lived, in-cluster buffers, not durable historical storage.
- Teams that require CNCF-graduated or incubating-level maturity guarantees for compliance/vendor-risk reasons — sandbox status won't satisfy many enterprise procurement checklists.
- Shops running heterogeneous or older kernel versions across nodes — eBPF compatibility issues will create operational friction.
- Teams wanting a mature, stable API to build long-term automation against — the 0.1.x versioning suggests breaking changes are still plausible.
- Organizations wanting a single unified observability platform (logs+metrics+traces+alerting) — Pixie solves a narrower slice (live in-cluster debugging) and will need to sit alongside Prometheus/Grafana/OTel, not replace them.
Alternatives
- OpenTelemetry — the CNCF-graduated standard for traces/metrics/logs instrumentation; more mature, broader ecosystem, but requires actual instrumentation work.
- Cilium Hubble — also eBPF-based, focused on network observability and policy visibility rather than app-level request tracing.
- Grafana Beyla — another eBPF auto-instrumentation project (OpenTelemetry-native), newer but backed by Grafana Labs' broader observability stack.
Pricing
Fully open source under Apache-2.0. No paid tier for the core project itself; New Relic offers optional hosted/cloud integration for teams that want a managed control plane, but the OSS collector and query engine are free to self-host and operate independently of any vendor.