Pixie: eBPF Auto-Telemetry for Kubernetes, and What It Costs You
Instant Kubernetes-Native Application Observability
At a glance
- What is it?
- Pixie collects full-body requests, network metrics and CPU profiles inside the cluster using eBPF, then queries them with a Python-like language called PxL. The trade-off is that its telemetry lives and dies with the cluster, and the recent release history is dominated by pre-release builds.
- Who is it for?
- Adopt Pixie if you run Kubernetes, want protocol-level visibility without instrumenting application code, and accept that telemetry is stored in-cluster and short-lived. Do not adopt it if you need long-term retention, non-Kubernetes workloads, or a vendor-neutral export pipeline as the primary path.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 47 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Pixie fills: telemetry you did not have to instrument
Most Kubernetes observability starts with an instrumentation project. You add an SDK, rebuild services, redeploy, and then wait for traces to arrive. Pixie takes the opposite position. According to the README, its agents use eBPF to collect telemetry automatically, including full-body requests, resource and network metrics, and application profiles. Nothing in the application has to change for that collection to happen. The audience is platform and SRE teams who already run Kubernetes and want to see what traffic is actually crossing the cluster before they spend a quarter adding tracing libraries. The README frames the output at two levels: high-level cluster state (service maps, cluster resources, application traffic) and detailed views (pod state, flame graphs, individual full-body requests). That combination is the pitch. It is not a metrics-only agent, and it is not a tracing SDK.
How the data flows: eBPF collection, in-cluster edge compute, PxL queries
The architecture has three visible parts. First, eBPF programs attached on each node collect telemetry: network flows, DNS requests and responses, TCP drops and retransmits, resource usage by pod, node and namespace, and CPU profiles. Second, the README states that Pixie collects, stores and queries all telemetry data locally in the cluster, which it calls in-cluster edge compute. This is the design decision that shapes everything else. There is no mandatory round trip to a vendor backend before you can query. Third, PxL, described as a Pythonic query language, is the interface across the UI, CLI and client APIs. The README also lists Apache Arrow, pandas and Vega among the project topics, which is consistent with a query layer that produces columnar results and renders them as charts rather than shipping raw rows to a browser. Two features sit outside that core loop. Pixie can deploy a bpftrace program to every node in the cluster and capture its output into a table that is queryable in the UI, with TCP drops given as the example. It can also attach to running Go binaries to change logging behaviour without recompiling and redeploying.
Installing Pixie and querying it from the CLI
The README does not include installation commands, so the deployment path has to be read from the surrounding material. The repository ships a Vizier component, and releases are tagged under release/vizier/, which tells you the in-cluster agent is versioned separately from the rest of the tree. The README links an Artifact Hub badge for a pixie-operator package in the community-operators repository, so an operator-based install exists. The CLI is named px. The homepage and docs live at px.dev and docs.px.dev, and the README points to tutorials under docs.px.dev/tutorials/pixie-101/ for network monitoring, infrastructure health, service performance, database query profiling, request tracing and profiling. The topics list includes px-run, which corresponds to a documented px run workflow for executing PxL scripts. What I cannot confirm from the supplied material is the exact Helm command, the namespace Pixie installs into, or the precise px CLI flags. If you are evaluating it, treat the docs site as the source for those, not this article. The README does give one operational number worth holding onto: Pixie uses less than 5% of cluster CPU, and in most cases less than 2%. That is the project's own claim, not an independent measurement.
The retention boundary is the design, not a missing feature
In-cluster storage is what makes Pixie fast and what makes it unsuitable as a system of record. The README does not describe a long-term retention window, and the architecture it does describe puts collection, storage and querying on the same cluster. That means historical analysis over months is not the intended use. It also means the cluster's own resource budget is the ceiling for how much telemetry you keep. The 5% CPU figure is a budget statement as much as a performance claim. There is a second boundary that the README states indirectly: eBPF collection depends on the host kernel, and the recent release tags include one explicitly named for updating kernel versions. Kernel compatibility is an active maintenance surface, not a solved problem. A third limitation is scope. Pixie is described as an observability tool for Kubernetes applications. Workloads outside the cluster, managed databases, and serverless functions are not what the eBPF agents attach to. If your incident spans a managed queue and a Kubernetes service, Pixie sees one half.
What the release history says about stability
The three most recent releases listed are all pre-release builds: v0.14.16-pre-HEAD.40, v0.14.16-pre-ddelnano-update-kernel-versions.38, and v0.14.16-pre-ddelnano-fix-vizier-dns-parser-crash.39. Two of the three names embed a contributor branch, and one names a crash fix in the DNS parser. That is a normal shape for an actively developed project, and it is also a signal about where to get your build. If you install from a pre-release tag because it is the newest thing on the releases page, you are running a branch build. The last push to the default branch is dated 2026-07-30, so the project is being worked on. The repository is not archived. None of this tells you whether the current stable Vizier release is healthy; it tells you that the tag list is not a changelog and should not be read as one. Pin a version and read the release notes for that version rather than taking the top entry.
Where Pixie stops and an OpenTelemetry pipeline begins
The obvious alternative is an OpenTelemetry-based pipeline: instrument services with the SDKs, run a Collector, and export to a backend you choose. The difference is not quality, it is where the work happens. OpenTelemetry requires application changes and gives you control over sampling, attribute schema and retention because the data leaves the cluster on your terms. Pixie requires no application changes and keeps the data in the cluster, which is why it can show you full-body requests for protocols your services never instrumented. The cost is that you inherit Pixie's storage model and its protocol coverage rather than defining your own. A reasonable position is to run both: Pixie for the immediate, un-instrumented view during an incident, and an OpenTelemetry pipeline for the durable record. The README does not claim Pixie replaces a tracing backend, and nothing in the material suggests an export path that would make it one.
Licence, maintenance and the cost of staying current
Pixie is Apache-2.0. That permits commercial use, modification and redistribution, and it includes an explicit patent grant. It does not give legal advice, and if you plan to redistribute a modified Vizier inside a product, read the licence text and your own counsel's reading of it rather than mine. On maintenance, the material supports a few concrete observations. Vizier is versioned independently, so upgrades are a component upgrade, not a whole-repository upgrade. Kernel compatibility is a recurring item, evidenced by a release tag dedicated to updating kernel versions. The project carries CII Best Practices, CLOMonitor and OpenSSF Scorecard badges, which indicate that the maintainers have opted into those programs; they are process signals, not guarantees about any given release. The practical cost is the one the README implies: you are running eBPF agents on every node, so every node kernel you add to the fleet is a compatibility question you have to answer before the agent works there.
Editorial conclusion
Adopt Pixie if you run Kubernetes, want protocol-level visibility without instrumenting application code, and accept that telemetry is stored in-cluster and short-lived. Do not adopt it if you need long-term retention, non-Kubernetes workloads, or a vendor-neutral export pipeline as the primary path. Before committing, verify that your kernel version is supported by the deployed Vizier build, check the current release channel rather than the pre-release tags, and confirm the CPU ceiling Pixie enforces on your nodes.
Community notes