Pixie Documentation

Pixie is an open-source observability tool designed for Kubernetes applications. It provides high-level cluster visibility (service maps, cluster resources, application traffic) and deep-dive capabilities (pod state, flame graphs, and full-body application requests).

Key features include:

• Auto-telemetry: Uses eBPF to automatically collect data like full-body requests, network metrics, and application profiles without manual instrumentation.
• In-Cluster Edge Compute: Collects, stores, and queries telemetry data locally within the cluster, typically consuming less than 5% of cluster CPU (often < 2%).
• Scriptability: Uses PxL, a Pythonic query language, accessible via the Web UI, CLI, and client APIs.

Stirling is Pixie's data collector that runs on nodes. It uses Linux APIs, including eBPF technology, to gather application metrics and events from the Linux kernel, system libraries, or the application itself.

Key data collected includes:

• Application CPU, memory, and network utilization.
• Application network messaging events for various protocols (e.g., HTTP, MySQL, Postgres, etc.).

The architecture uses a core infrastructure with "source connectors" that extract information from different data sources and export data tables via the Stirling API.

The Pixie PostgreSQL wire protocol parser is based on Postgres wire protocol version 3. While the implementation references the version 9.5 specification, the protocol has remained stable since version 7.4 and is compatible with modern PostgreSQL deployments.

Note that this parser can also be used for CockroachDB, as it implements the same PostgreSQL wire protocol.

Pixie's HTTP2/gRPC tracing feature has the following scope:

Supported:

• Unary gRPC RPCs: Pixie traces unary calls by using HTTP2 stream IDs to associate requests and responses.
• Golang Applications: Specifically those using standard net/http and http2 packages.
• TLS Mode: Tracing works even when TLS is enabled.

Not Supported:

• Streaming RPCs: This includes client-streaming, server-streaming, and bidirectional-streaming.
• Non-Golang Applications: Only Golang applications meeting the symbol requirements are supported.

If you need tools for interacting with gRPC services, the following external utilities are recommended:

• grpc_cli: A C++ based command-line tool. Note that it requires reflection to be enabled on the service to operate.
• grpcurl: A Go-based command-line tool. Like grpc_cli, it requires service reflection. It is particularly useful for Go-based projects (such as the Pixie gRPC service poker).

Privy is a command line tool for generating synthetic protocol traces (JSON, XML, SQL, HTML, Protobuf) using OpenAPI descriptors and fake PII data.

To generate JSON data in the default Bazel sandboxed runtime directory:

bazel run //privy/generate:privy_generate

To specify a custom output folder, multiple data types, and a logging level, use the following syntax:

bazel run //privy/generate:privy_generate -- --out_folder=/path/to/output/directory --generate json sql --logging=debug

You can build the Stirling code base using the Bazel build system with the following command:

bazel build //src/stirling/...

You can make the linter available globally for multiple projects using one of two methods:

Method 1: Directory Proximity

Clone the clang-format-linter repository into the same directory where arcanist and libphutil are located. Arcanist automatically searches for modules in the directory one level up from itself.

Directory Structure:

> ls
arcanist
clang-format-linter
libphutil

.arcconfig configuration:

{
  "load": [
    "clang-format-linter"
  ]
  // ...
}

Method 2: Absolute Path

Clone the repository to a fixed location (e.g., ~/.dev-tools) and reference that absolute path in your .arcconfig.

cd ~/.dev-tools
git clone https://github.com/vhbit/clang-format-linter

{
  "load": [
    "~/.dev-tools/clang-format-linter"
  ]
  // ...
}