Overview
Pixie
Pixie is an open-source observability platform for Kubernetes that uses eBPF to automatically capture telemetry data — without any code changes or manual instrumentation.
Key Features
- Zero-instrumentation: Uses eBPF to automatically trace HTTP, gRPC, MySQL, PostgreSQL, Redis, Cassandra, DNS, and more
- Full-body request tracing: Captures complete request and response bodies (headers, payloads)
- In-cluster processing: Data stays in the cluster — no external data transfer required
- PxL scripting: Custom query language for flexible data exploration
- CPU flamegraphs: Built-in continuous profiling for Go, C++, Rust applications
- Network monitoring: TCP drops, retransmits, DNS resolution tracking
Architecture
Source: https://docs.px.dev/about-pixie/what-is-pixie/
Components
| Component | Description |
|---|---|
| PEM (Pixie Edge Module) | Agent installed on each node. Uses eBPF to collect data, which is stored locally on the node in-memory. |
| Vizier | Collector installed per cluster. Responsible for query execution and managing PEMs. |
| Kelvin | Central query execution engine within Vizier. Aggregates results from PEMs across the cluster. |
| Pixie Cloud | Manages user authentication, API keys, and data proxying. Can be hosted (Community Cloud) or self-hosted. |
Pixie CLI (px) |
Command-line tool to deploy Pixie, run PxL queries, and manage resources like API keys. |
| Pixie Client API | Programmatic access to Pixie data for integrations, Slackbots, and custom applications. |
Supported Protocols
| Protocol | Auto-traced | Notes |
|---|---|---|
| HTTP | ✅ | — |
| HTTP/2 (gRPC) | ✅ | Golang gRPC with/without TLS; requires debug info |
| MySQL | ✅ | — |
| PostgreSQL | ✅ | — |
| Redis | ✅ | — |
| Cassandra (CQL) | ✅ | — |
| DNS | ✅ | — |
| Kafka | ✅ | — |
| NATS | ✅ | Requires NATS build with debug information |
| AMQP | ✅ | — |
| MongoDB | ✅ | — |
When to Use Pixie
- ✅ Quick debugging — no instrumentation setup needed
- ✅ Network-level visibility — TCP drops, DNS issues, inter-service traffic
- ✅ Database query profiling — full SQL queries with latency and error rates
- ✅ Legacy services — works with any language, no SDK required
- ✅ Security-sensitive environments — data stays in-cluster
- ❌ Long-term storage — Pixie stores data in-memory (short retention, typically minutes to hours)
- ❌ Custom business metrics — use Prometheus/OTel for application-specific metrics
- ❌ Cross-cluster tracing — use OpenTelemetry for distributed traces across clusters
Pixie vs OpenTelemetry
| Aspect | Pixie | OpenTelemetry |
|---|---|---|
| Instrumentation | None (eBPF) | SDK or auto-instrumentation |
| Setup effort | Deploy agent | Add SDK to each service |
| Data location | In-cluster only | Exported to backends |
| Retention | Minutes to hours | Days to years |
| Protocol support | Automatic for supported protocols | Depends on instrumentation |
| Custom spans/metrics | Limited (PxL scripts) | Full control |
| Cross-cluster | No | Yes |
💡 Best practice: Use Pixie for rapid debugging and network-level insights, and OpenTelemetry for long-term observability with custom instrumentation. They complement each other.