I've always wanted to see the complete performance picture before pushing any code or building something. Not after it's slow in production, not after a user complains about it, before. Click a button, run a command, trigger a request, and actually see what that cost instead of guessing.
That itch has been sitting with me for years. Back in university, I took a course on application performance, and every single homework was the same loop: profile a feature, find what's slow, fix it, measure again, confirm it's actually better. We did it in C# with Visual Studio's live profiler, watching CPU and memory update in real time while clicking through an app. That loop never left me. A few years later I was using NetBird before it had anything close to a performance or observability story, and I kept thinking about the same gap from a completely different angle: infrastructure.
So I'm building Nusku. A continuous profiling system for Linux, written in Zig, with eBPF doing the actual watching.
What it does
Point Nusku at a running process, or launch one through it, and watch what it's actually doing while you use it. CPU time per function, live. Memory as it's allocated, not just a number that goes up, but what called for it and where. Threads that look idle but are actually stuck waiting on a lock, a disk read, or another process, and for how long. Syscalls that quietly eat milliseconds a normal CPU graph never shows you. Network calls that are slow because packets are getting retransmitted, not because the code is doing anything wrong.
It runs locally with nothing to configure, you point it at a process and watch. It can also run on a remote machine and stream that same live picture back over a secure connection, so a server can be watched the same way as something running on your own laptop.
Why eBPF, and why Zig
Every serious Linux profiling tool, Parca, Pyroscope, Cilium, Datadog's continuous profiler, is built on eBPF, not on polling files in /proc and hoping for the best. eBPF is the only way to get real kernel-level visibility into what a process is doing, without injecting anything into it and without the overhead of a userspace polling loop. So that's the foundation, not an add-on bolted on later.
Zig is the other half of the decision, and it's as much about the learning as the result. No garbage collector getting in the way of measuring performance accurately. Full control over memory and allocation, which matters a lot when the entire point of the tool is measuring memory and allocation in something else. And honestly, it's just the language I want to get good at.
The big picture
Nusku splits into a few pieces, each with one job, built and released one at a time:
- Agent: sits next to a process and does the actual watching through eBPF. Being built first, because nothing else matters if the data it collects isn't accurate.
- Controller: the thing you'd actually talk to once there's more than one process to watch, or watching needs to happen from somewhere else. Lists what's running, lets you pick a target, manages sessions. ...and others will decide later.
Each piece has to fully work before the next one starts. Right now, that means the Agent and nothing else.
What I want to end up with
Honestly, depth first. This is me practicing Zig and systems programming for real, no AI-generated slop, no shortcuts, just me, textbooks, and the Linux kernel docs. There's no deadline attached to any of this and no plan to monetize it right now. If it ends up being something other people actually find useful along the way, that's a genuine bonus, not the goal I'm optimizing for.
What I do want is to end up with a tool that actually answers the question that's been sitting with me since that performance course: not "is my app slow," but "show me exactly why, right now, while it's happening."
I'm documenting the real, unpolished progress in a dev log as I build it. If watching a profiler get built from scratch in Zig and eBPF, warts and all, sounds interesting, I'd genuinely like the company.
Top comments (0)