Nusku: A Continuous Profiler for Linux Built in Zig on eBPF

A developer has started work on Nusku, a continuous profiling system for Linux written in Zig, with eBPF handling the low-level observation. In a dev log published on dev.to on 4 October 2026, the author frames the project around a single goal: not answering whether an application is slow, but exposing the specific reason, observed live as the behaviour occurs.

What it is designed to show

According to the post, you aim Nusku at a running process — or launch one through it — and observe what that process actually costs during normal use. The intended feature set covers:

• Per-function CPU time, updating live
• Memory shown at the moment of allocation, including what requested it and from where, rather than a single figure ticking upward
• Threads that appear idle but are actually blocked on a lock, a disk read or another process, and for how long
• Syscalls that quietly consume milliseconds a typical CPU graph never surfaces
• Network calls that are slow because packets are being retransmitted, not because the code is at fault

The tool is meant to run locally with nothing to configure, or on a remote machine, streaming the same live picture back over a secure connection so that a server can be examined the same way as a process on a laptop.

Why eBPF, and why Zig

The author's case for eBPF is that it underpins every serious Linux profiling tool — the post names Parca, Pyroscope, Cilium and Datadog's continuous profiler — instead of polling files in /proc and hoping for the best. eBPF delivers kernel-level visibility into a process without modifying the target and without the overhead of a polling loop in userspace. In Nusku it is the foundation, not an add-on attached later.

Zig comes down to two things. Practically, there is no garbage collector distorting performance measurement, and the author has full control over memory and allocation — which matters when the tool's entire purpose is measuring memory and allocation in other programs. Personally, the author says it is simply the language they want to master, and Nusku is partly a vehicle for learning systems programming properly.

Agent first, everything else later

Nusku is split into components, each with one job, to be built and released one at a time. The Agent sits next to a process and performs the actual watching through eBPF. It is being built first, on the reasoning that accurate data is the prerequisite for everything else. The Controller — the piece a user would actually talk to once multiple processes or remote machines are involved — will list what is running, let you pick a target and manage sessions. Any further components have not yet been decided. Each piece has to fully work before the next one begins, which, the post says, currently means the Agent and nothing else.

A no-deadline project, documented in the open

The post is candid about scope and motive. There is no deadline and no plan to monetise. The author describes the approach as depth-first, working from textbooks and Linux kernel documentation rather than taking shortcuts, and is writing up the rough, work-in-progress state in a public dev log as the build happens. The motivation traces back to a university performance course where every assignment repeated the same loop — profile, locate the slow spot, fix it, then measure again to confirm — and later to time spent around infrastructure, where the same observability gap appeared from a different angle.

Why it matters

Continuous profiling has consolidated around eBPF, but the tools the author cites are largely oriented toward production observability: fleets of machines, stored profiles, dashboards. Nusku's pitch targets an earlier point in the cycle — giving a developer the complete performance picture locally, before code ships, rather than after users complain. Combined with the zero-configuration local mode, that positions it closer to an inner-loop development instrument than a backend monitoring service.

The language choice also deserves attention. A profiler that measures allocation behaviour benefits from not having a garbage collector or opaque runtime of its own muddying the numbers, so Zig aligns with the tool's purpose rather than being a novelty.

Finally, this is an early-stage personal project, not a finished product: only the Agent is underway, and the author is explicit that usefulness to others is a bonus rather than the optimisation target. Anyone selecting a profiler today will still reach for the established options — but a from-scratch, publicly documented build of an eBPF profiler in Zig is a rare resource for anyone learning either subject, and worth following as the Agent matures.