Pixie is a strong eBPF-powered observability tool for Kubernetes. It captures HTTP, gRPC, TLS, database, and network telemetry without application code changes, sidecars, or language agents. That makes it useful when you need answers from a live cluster now. It does not replace application logs, strace, dmesg, or source analysis when the real failure sits inside the process or kernel.

Last updated: 2026-08-20

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’ve ever chased a latency spike on a path nobody instrumented, this is the tool that closes that gap. It also has limits, and they matter. Below I cover what Pixie actually does, where its eBPF probes attach, which protocols it reads automatically, and the problems that still require logs or deeper debugging.

The goal is that you know what you’re getting before you run the installer.

What is Pixie, and why does it use eBPF?

Pixie is an open source observability platform for Kubernetes, and it is a Cloud Native Computing Foundation (CNCF) project. That matters because the code and project direction are public. You aren’t forced to build your telemetry pipeline around one vendor’s agent.

The reason Pixie uses eBPF is architectural, not marketing. eBPF runs small, verified programs inside the Linux kernel. Those programs can react to system calls, network events, and other kernel hooks while workloads continue running.

Because the probes sit below your application, Pixie can see traffic from pods without asking developers to modify the code. You don’t add a tracing library, redeploy every service, or place a sidecar beside every workload.

Manual instrumentation still has its place. It gives you business context that kernel-level collection cannot infer, such as why a checkout was rejected or which customer workflow failed. However, it depends on every team instrumenting every important path correctly. That is the part that fails at 3 a.m.

Pixie gives you broad coverage first. Then you decide where deeper application instrumentation is worth the work.

For a smaller place to learn the mechanics, see using eBPF in home lab monitoring.

How does Pixie provide automatic Kubernetes observability without instrumentation?

Pixie collects telemetry from running Kubernetes workloads through an in-cluster agent and eBPF probes. The application stays unchanged, while Pixie watches the system and network activity around it.

Here is what that means in practice:

• No application code changes.
• No language-specific agent in each service.
• No sidecar for every pod.
• No redeploy required just to see basic request traffic.
• Queries run against telemetry collected near the workloads.

The usual mistake is treating automatic observability as complete observability. Pixie can see that a request was slow, returned an error, or exchanged unexpected data. It usually cannot tell you the business reason inside a handler unless that reason appears in the captured data.

Application logs still matter for decisions, validation failures, stack traces, and domain-specific state. Distributed tracing still matters when you need one request’s business path across services. Kernel debugging still matters when a process hangs in a system call or a device starts returning errors.

Pixie fills the gap between “the dashboard says latency rose” and “which service, connection, query, or protocol exchange caused it.” It doesn’t remove the rest of the debugging stack.

The Pixie eBPF approach also depends on what the kernel and running binaries expose. A stripped binary, an unusual runtime, or a library layout Pixie doesn’t support can leave a protocol partially visible or empty. Check the output before deciding the application is quiet.

Where are the official Pixie eBPF and Kubernetes observability docs?

Start with the official Pixie documentation. It covers deployment, supported telemetry, query usage, and the current limits of the project.

For cluster-level monitoring concepts, read the official Kubernetes observability documentation. Kubernetes gives you the control plane and workload context. Pixie adds live application and network visibility from inside the nodes.

Pixie’s CNCF project status also puts it in the broader Kubernetes observability ecosystem. Treat that as project context, not as proof that every kernel, runtime, protocol, or managed Kubernetes setup behaves the same way. The installer may work while one important probe does not.

The useful path through the documentation is:

1. Check the supported Kubernetes deployment model.
2. Confirm the required kernel and runtime conditions.
3. Review protocol support for the traffic you need to inspect.
4. Deploy in a test namespace or cluster.
5. Reproduce known traffic and compare Pixie’s output with application logs.

That last check catches more problems than reading feature lists. A tool can support HTTP in general and still miss your statically linked binary or custom TLS library.

How does Pixie trace HTTP and other network protocols with eBPF?

Pixie reads data near the socket boundary and identifies protocols from their wire format. It can then build message-level telemetry without application instrumentation.

Pixie uses several probe types:

• Kernel probes, or kprobes, attach to kernel functions and system calls.
• User-space probes, or uprobes, attach to functions inside running binaries.
• Tracepoints are stable hooks exposed by the kernel for specific events.

Here is what happens on a typical request. Your service calls write() on a socket. The probe observes the call, captures connection metadata and available buffer contents, and associates the traffic with the Kubernetes workload.

The application doesn’t need to call Pixie. That is why collection is automatic.

Pixie can decode HTTP/1.x, HTTP/2, gRPC, MySQL, PostgreSQL, Redis, Kafka, DNS, and other supported protocols. Coverage changes as the project changes, so check the current official documentation before making one protocol a deployment requirement.

This is the HTTP tracing answer most teams want. You don’t add a trace header or wrap a handler. Pixie sees the traffic because the kernel sees the socket activity.

Still, a socket view is not the same as packet capture or application logging. If you need packet flags, retransmissions, or exact wire behavior, use packet-level tools. If you need the reason a handler returned an error, read the application log and source.

For DNS-specific work, monitoring DNS traffic with eBPF covers the lower-level approach.

How does Pixie trace encrypted traffic with user-space probes?

Pixie can trace some encrypted traffic by attaching uprobes to TLS library functions. The probe reads plaintext before the library encrypts it and after the library decrypts incoming data.

A packet capture sees ciphertext. A TLS uprobe can see the buffer passed to functions such as SSL_write before encryption. That is how Pixie can produce HTTP and gRPC visibility on connections that a wire capture cannot read.

Pixie’s TLS tracing has a hard boundary. It only works when the probe can find the expected function in the running binary and match the library and runtime layout.

Results can be limited by:

• Statically linked binaries.
• Uncommon TLS libraries.
• Stripped symbols.
• Runtime changes.
• Unsupported language or library versions.
• Custom encryption that happens above or outside the expected TLS functions.

A service can therefore show ordinary network traffic while its decrypted request data remains unavailable. That is not a contradiction. The kernel can see bytes moving without knowing what those bytes mean.

Confirm the application’s build and TLS stack before assuming encrypted traffic will be readable. For a broader look at encrypted paths, see using eBPF to trace VPN traffic across encryption.

What happens inside the Pixie Edge Module?

Pixie processes and aggregates much of the collected data near the workloads, inside the cluster. The Edge Module handles data close to the node rather than sending every raw event to a remote service.

That design has two practical effects. First, queries against recent activity stay responsive because the data is already near the workloads. Second, sensitive request data and query text don’t leave the cluster by default.

The trade-off is retention. Hot telemetry kept near the workloads is intended for live investigation, not as a long-term incident archive. If you need history, alerting, or correlation over a longer period, send selected telemetry to the system that already handles that job.

This local model also changes how you think about cost and risk. You avoid shipping every captured byte across the network, but node memory and processing still matter. High-volume traffic, large bodies, and wide queries can put pressure on the same cluster you’re trying to diagnose.

Start with a narrow time range and a specific workload. Querying the entire fleet because the interface lets you do it is still a good way to create a second problem.

Which profiling and debugging features does Pixie add?

Pixie goes beyond network tracing with continuous CPU profiling, dynamic logs, and distributed bpftrace script deployment. These features are useful, but each one can add work to the system being observed.

Continuous CPU profiling

Pixie samples stacks across services and builds flame graphs. That helps you find hot code paths in Go, C++, and Rust programs without adding a profiling library or restarting the workload.

A flame graph tells you where CPU time accumulates. It does not prove why that code is hot. The cause may be unexpected input, lock contention, a retry loop, a bad query plan, or a kernel delay outside the sampled stack.

Use the profile to choose the next investigation. Then confirm the cause with logs, strace, runtime diagnostics, or source. Profile kernel performance with eBPF covers the lower-level profiling trade-offs.

Dynamic Go function logging

Pixie can attach to selected Go functions in a running binary and expose arguments or return values without a rebuild. This is useful when a missing log line is blocking an incident and a redeploy would take too long.

The probe still depends on the binary. Symbol availability, compiler settings, inlining, stripping, and the Go runtime can all affect what Pixie can attach to.

Scope dynamic logging tightly. A function called constantly under production load can turn a debugging probe into extra work on every request. Test the target function and confirm the returned data before expanding the probe.

Distributed bpftrace scripts

Pixie can distribute bpftrace programs across Kubernetes nodes. One script can answer a fleet-wide kernel question without you opening an SSH session on every machine.

That is the operational win. The risk is multiplication. A probe that is acceptable on one node can become expensive when deployed across every node, especially if it fires on a hot system call.

Use this sequence:

1. Identify the exact hook and event you need.
2. Test the script on one node.
3. Check CPU use, event volume, and returned data.
4. Narrow the filter before expanding the scope.
5. Remove the probe after the investigation.

bpftrace is not a mysterious window into the kernel. It is a program that runs in the kernel’s path and needs the same care as any other production change.

Is Pixie the right fit for Kubernetes observability?

Choose Pixie when you need live, Kubernetes-aware visibility into application and network behavior without changing every service. It earns its place during latency investigations, protocol debugging, dependency checks, and incidents involving workloads nobody instrumented properly.

Keep it out of the role of permanent history and sole alerting system. Prometheus remains useful for metrics and alert rules. Grafana remains useful for dashboards. Application logs remain necessary for business failures and stack traces. Distributed tracing remains useful when you need request context that the network alone cannot provide.

The sane pattern is layered:

• Use Prometheus and Grafana for stored metrics, alerting, and dashboards.
• Use application logs for decisions, errors, and stack traces.
• Use distributed tracing for request context across services.
• Use Pixie for fast live telemetry from Kubernetes workloads.
• Use strace, journalctl, dmesg, and source analysis for process and kernel failures.

Pixie is strongest when the question is, “What crossed this connection, and which workload did it?” It is weaker when the question is, “Why did this line of application code make the wrong decision?”

The pixie ebpf observability model gives you coverage without waiting for every team to add instrumentation. It also gives you another agent, another compatibility surface, and another stream of sensitive telemetry to govern. Review its permissions, retention, query access, and captured data before production deployment.

What are the real limitations and prerequisites?

The main limitation is probe compatibility. Pixie depends on kernel hooks, binary symbols, library layouts, and runtime behavior. Those details change across container images and build pipelines.

Check these areas before rollout:

• Kernel support for the required eBPF features.
• Permissions to load and attach probes.
• Container runtime and Kubernetes compatibility.
• Node operating system and kernel configuration.
• Language runtimes and TLS libraries.
• Binary symbols needed by user-space probes.
• Network policies that could block Pixie components.
• Resource limits for collection, storage, and queries.
• Access controls for request bodies, credentials, and query text.

Security needs a separate review. Network telemetry can contain tokens, identifiers, SQL text, request bodies, and internal hostnames. Keeping data inside the cluster reduces exposure, but it doesn’t make sensitive data harmless.

When a protocol appears empty, check the probe conditions before changing application code. Look at the binary, the library, the kernel, and the exact traffic path. The failure usually lives in one of those seams.

Where should you start with Pixie?

Start with the official deployment and compatibility documentation, then test a workload that produces traffic you already understand. A known request gives you something to compare against instead of guessing whether an empty result is a product bug.

Use a narrow test:

1. Deploy Pixie to a non-critical cluster or namespace.
2. Send a known HTTP or gRPC request.
3. Confirm the workload and connection metadata.
4. Compare the reported status and latency with application logs.
5. Test one encrypted connection if TLS visibility matters.
6. Check a CPU profile against the process’s known workload.
7. Remove or restrict probes you don’t need.

The best first test is reproducible. If you cannot describe the request, the expected response, and the expected workload, you won’t know whether Pixie missed data or your test did nothing.

FAQ

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

It can work on managed Kubernetes, but the result depends on node access, kernel features, permissions, and the managed service’s restrictions. Check the current Pixie deployment requirements for your provider before planning a rollout. A managed control plane does not guarantee that node-level eBPF attachment is available.

Can I query Pixie data with my own scripts?

Yes, Pixie is designed around queryable telemetry and supports programmatic use through its query mechanisms. Start with a query in the Pixie interface, confirm that it returns the fields you need, and then automate that known-good query. Automating an unverified query only makes confusion repeatable.

Will Pixie slow down my applications?

Pixie’s eBPF collection is designed to reduce application changes and keep collection overhead controlled, but no probe is free. Network volume, protocol parsing, CPU profiling, dynamic logging, and broad bpftrace programs all add work. Measure the target workload and keep probes narrow when performance is part of the incident.

Is Pixie safe to run in the kernel?

eBPF programs are verified before they run, which prevents many classes of unsafe kernel behavior. That does not answer the operational security question by itself. Review Pixie’s privileges, probe scope, captured fields, and access controls as you would any component that can observe workload traffic.

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

Yes. Pixie gives you fast, detailed visibility into live Kubernetes traffic and workload behavior. Prometheus and Grafana still handle durable metrics, alerting, dashboards, and the historical view that a short-lived in-cluster telemetry window cannot replace.