Pixie auto-instruments your Kubernetes workloads with eBPF at the kernel level, so you get real HTTP, gRPC, and TLS visibility the moment it deploys. No code changes, no sidecars, no language agents. It taps the Linux kernel directly, collects metrics, traces, and logs, and keeps the data inside your cluster where you can query it. If you have ever chased a latency spike on a path nobody instrumented, this is the tool that closes that gap.

Last updated: 2026-07-18

Below I cover what Pixie actually does, where its eBPF probes attach, which protocols it reads for free, and the limits that bite you in production. The goal is that you know what you are getting before you run the installer.

Pixie and why eBPF matters for Kubernetes observability

Pixie is an open source observability platform for Kubernetes, and it is a CNCF project. That matters because the code and the roadmap are public, so you are not locking your telemetry pipeline to one vendor's agent.

The reason it leans on eBPF is architectural, not marketing. eBPF runs small, verified programs inside the kernel that fire on system and network events. Because those programs sit below your application, Pixie sees every syscall your pods make without you touching the code. No language agents, no redeploy, no sidecar next to every workload.

Compare that to the usual path. Manual instrumentation means adding a library to each service, shipping it, and hoping nobody forgot the one endpoint that pages you at 3am. The eBPF approach gives you coverage first, then lets you decide what to keep. For a smaller, safer place to learn the mechanics, I wrote about using eBPF for home lab monitoring.

How Pixie's eBPF probes capture data without code changes

Pixie attaches three kinds of probes, and knowing which is which tells you what it can see. Kernel probes, or kprobes, hook kernel functions like the syscalls that read and write sockets. User-space probes, or uprobes, hook functions inside a running binary, which is how Pixie reads library calls before they hit the wire. Tracepoints are stable hooks the kernel exposes on purpose, so they survive kernel upgrades better than raw kprobes.

Here is what happens on a request. Your service calls write() on a socket, the kprobe fires, and Pixie copies the buffer contents and the connection metadata. It never asks your app for anything. That is the whole trick, and it is why collection is automatic.

The catch nobody mentions: probes attach based on kernel symbols and library layouts. So an unusual container image or a statically stripped binary can break a uprobe that works fine everywhere else. When a protocol shows up empty, that mismatch is usually the real problem, not Pixie being broken. For the general pattern, see how to trace system calls with eBPF.

Which protocols can Pixie decode automatically?

Pixie reads the bytes at the syscall boundary and detects the protocol from the wire format, so you get message-level tracing without configuring anything. Out of the box it parses HTTP/1.x, HTTP/2 and gRPC, plus databases and messaging: MySQL, PostgreSQL, Redis, Kafka, DNS, and more.

This is the HTTP tracing answer people actually want. Because Pixie sits on the socket, it reconstructs full requests and responses, including status codes and latencies, for every service that talks HTTP. You did not add a trace header. You did not wrap a handler. The data is there because the kernel saw the syscall.

Protocol coverage grows over time, so treat any list as a snapshot. Check current support in the official docs before you bet a rollout on one wire format.

How does Pixie read TLS and encrypted traffic?

This is where most network-tap tools give up, and where Pixie earns its keep. A packet sniffer on an encrypted connection sees ciphertext and nothing useful. Pixie sidesteps that by attaching uprobes to the TLS library functions, so it reads the plaintext buffer before the library encrypts it, and again after it decrypts on the way in.

In practice that means uprobes on OpenSSL and on Go's built-in TLS stack. Your app hands plaintext to SSL_write, the uprobe fires, Pixie captures it, and only then do the bytes get encrypted for the network. You get decrypted HTTP and gRPC traces on connections a wire capture could never read.

The honest limit: this only works when Pixie can find and hook the exact TLS function in your binary. A statically linked binary with an uncommon crypto library, or a runtime Pixie has not mapped, leaves you with encrypted traffic it cannot open. Confirm your stack before you assume TLS visibility is total.

The in-cluster architecture that keeps your data local

Pixie stores and queries telemetry inside your own cluster instead of shipping every byte to a vendor's backend. Each node runs an agent that holds recent data in memory, and you query it in place. That edge model is why it stays cheap and fast at high request volumes.

The payoff is twofold. Your sensitive request bodies and query text never leave the cluster by default, which shortens the security review. And you are not paying to move terabytes of trace data across the internet to answer a question about the last few minutes.

The trade-off is retention. Because the hot data lives in cluster memory, the window is short by design. This is a live-debugging tool, not a year-long archive. When you need history, alerting, and incident correlation over weeks, you route selected telemetry outward. A New Relic integration is available for Pixie telemetry and handles exactly that long-term storage and alerting role.

Profiling, dynamic logs, and cluster-wide bpftrace

Three features go past network tracing into how your code actually runs.

First, the continuous CPU profiler. Pixie samples stacks across your services and builds flame graphs, so you can spot the hot path in a Go, C++, or Rust binary without adding a profiling library or restarting anything. Sampling is cheap because it reads stacks at an interval instead of instrumenting every call, and it still finds the frame eating your CPU. If flame graphs are new to you, I walk through the technique in profiling kernel performance with eBPF.

Second, dynamic logging. You point Pixie at a function in a running binary and pull out arguments and return values, live, with no redeploy. Think of it as a print statement you add to production without shipping a build. Use it sparingly and scope it tight, because a probe on a hot function under load is still work the kernel has to do.

Third, cluster-wide bpftrace. Pixie distributes bpftrace programs to every node, so one script gets kernel-level answers from the whole fleet at once. Normally bpftrace means SSH-ing into a box, running your one-liner, then repeating on the next node while the incident spreads. Pixie removes that loop. A heavy probe is real overhead multiplied by node count, so test it narrow before you fan it out, and reach for it when you already know the hook you need.

Where Pixie fits in the CNCF observability ecosystem

Pixie complements your metrics and logging stack. Treat it as the auto-instrumentation layer that fills the gaps your Prometheus scrapes and app logs never covered, especially the raw HTTP, gRPC, and database traffic nobody instrumented by hand.

Its CNCF status means it plays with the neighbors. It can feed data toward OpenTelemetry-shaped pipelines and hand long-term telemetry to a backend like New Relic, while Prometheus keeps alerting on service metrics and Grafana keeps your dashboards. Pixie is the fast, kernel-level source of truth for what actually crossed the wire.

So the sane pattern is layered. Keep your existing metrics and logs for history and alerting. Add Pixie for the instant, no-agent view when you need to see a live request or find a hot path right now. For the security corner of this same landscape, Falco for eBPF security monitoring is the tool built for detecting suspicious syscalls rather than tracing app traffic.

What are the real limitations and prerequisites?

The first hard gate is your kernel. Pixie's eBPF probes need Linux kernel v4.14 or newer, so check your node images and node pools before anything else. On a managed cluster that usually means confirming your node pool's OS image, not your laptop's kernel. An old node quietly failing to load probes is a classic waste of an afternoon.

The rest of the real constraints, in plain terms:

• Privileges. Loading eBPF programs needs elevated kernel capabilities, so the agents run privileged. That belongs in your security review, not a surprise later.
• Protocol gaps. If your traffic uses a wire format Pixie does not parse yet, you see connections but not decoded messages. Verify your specific protocols.
• TLS coverage. Decryption depends on hooking a TLS library Pixie recognizes. Unusual crypto stacks stay opaque.
• Retention. In-cluster data is short-lived by design. Route to a backend if you need history.
• Resource headroom. The agents use CPU and memory on every node. Leave room so collection does not fight your workloads.

None of these are dealbreakers. They are the things that decide whether your rollout is smooth or a week of confusion, so read them before you install. Understanding the failure up front is how you avoid debugging it live.

Where to start in the official docs

Install is one command from the Pixie CLI against a running cluster: bash -c $( curl -fsSL https://work.withpixie.ai/install.sh ). That bootstraps the CLI, and from there you deploy the control plane and the per-node agents into your cluster. Within minutes each node loads its verified programs and starts enriching events with Kubernetes metadata.

After it deploys, prove it works before you trust it. Check that the agent pods are ready across nodes with kubectl get pods, then open the UI or run a script and confirm you see HTTP latencies, error rates, and database call counts for a few known services. If those numbers appear, your data path is healthy.

For anything beyond this, go to the primary sources, not a random blog. The Pixie project documentation has the current install guides, protocol support tables, and PXL scripting reference, and the eBPF project site explains the kernel technology underneath. Both stay current in ways a version number pasted into an article never will.

FAQ

Does Pixie work on managed Kubernetes like EKS, GKE, or AKS?

Yes, as long as the node images meet the kernel floor and you can grant the agents their privileges. The thing that trips people up on managed clusters is not the control plane, it is an old or hardened node image that will not load eBPF programs. Confirm the node pool OS before you blame Pixie.

Can I query Pixie data with my own scripts?

Yes. Pixie ships a scripting language called PXL, and you write scripts to slice the telemetry however you want, then run them from the CLI or the UI. Your investigation becomes a script you can save, share, and rerun, instead of a set of clicks nobody can reproduce.

Will Pixie slow down my applications?

The overhead is low because eBPF programs are just-in-time compiled and run in the kernel, and the CPU profiler samples rather than instrumenting every call. The exception is pointing dynamic logging or a bpftrace script at a hot function under heavy load. Scope those probes tight and the day-to-day cost stays small.

Is Pixie safe to run in the kernel?

Every eBPF program is checked by the kernel's verifier before it runs, which rejects code that could loop forever or read out of bounds. That sandbox is the reason kernel-level collection is viable at all. It does not remove the need to test heavy custom probes, but it stops a bad program from taking the node down.

Do I still need Prometheus and Grafana if I run Pixie?

Keep them. Pixie gives you instant, no-instrumentation traces and live debugging, but its in-cluster data window is short. Prometheus and Grafana still own your long-term metrics, dashboards, and alerting. Run Pixie alongside them as the fast source for what crossed the wire right now, and route what you need to keep into a backend for history.