Architecture
How Rezolus is structured and how the pieces fit together.
rezolus binary — you just pick the subcommand for the job. Dashed boxes are what you point it at: the systems and services being measured, which are not part of Rezolus.Operating Modes
Rezolus is a single binary with six subcommands. Each mode handles a different stage of the observability workflow.
Agent
sudo rezolus <config.toml>
The core collection engine. Attaches eBPF programs to kernel tracepoints and kprobes to collect metrics across CPU, scheduler, block I/O, network, memory, TCP, and syscalls. Exposes data via HTTP on port 4241 in JSON and msgpack formats.
Exporter
rezolus exporter <config.toml>
Pulls metrics from the agent's msgpack endpoint and serves them in Prometheus format on port 4242. Converts histograms to configurable summary percentiles. Designed for Prometheus scraping.
Recorder
rezolus record [-o out.dendro]
On-demand metric capture to a .dendro archive, the only format it writes. Connects to a running agent and writes high-fidelity snapshots at configurable intervals and durations. Ideal for benchmarking and performance engineering.
Hindsight
rezolus hindsight <config.toml>
Maintains a rolling buffer of high-resolution metrics on disk as a .dendro archive. Trigger snapshots via SIGHUP or the HTTP API. Supports time-range queries for extracting the window around an incident.
Viewer
rezolus view <input> [listen]
Web-based interactive dashboard for exploring .dendro, .rez and Parquet recordings or streaming live from a running agent. Includes a built-in TSDB with PromQL query support and pre-built dashboards for each metric category.
MCP Server
rezolus mcp [subcommand]
AI-guided analysis server. Provides tools for querying recordings with PromQL, detecting anomalies, analyzing correlations between metrics, and describing recording metadata, plus tools that write findings back as timeline events. More.
eBPF Integration
Rezolus uses libbpf-rs for eBPF program management. BPF programs are written in C (.bpf.c files) alongside their Rust module counterparts and compiled at build time via build.rs.
At runtime, the agent attaches these programs to kernel tracepoints and kprobes. This provides kernel-level visibility with near-zero overhead — no polling of /proc or /sys required for instrumented metrics.
Requires: Linux kernel 5.8+ and root access. macOS builds omit eBPF samplers.
Key Technical Details
- • Async runtime: Tokio with minimal threads
- • HTTP framework: Axum
- • Metrics library: metriken crate
- • Sampler registration:
linkmedistributed slices for static registration - • Data format:
.dendroarchives via the dendro crate - • Hardware topology: systeminfo crate
- • Architectures: x86_64 and ARM64