Show HN: Linnix – eBPF observability that predicts failures before they happen
github.comI kept missing incidents until it was too late. By the time my monitoring alerted me, servers/nodes were already unrecoverable.
So I built Linnix. It watches your Linux systems at the kernel level using eBPF and tries to catch problems before they cascade into outages.
The idea is simple: instead of alerting you after your server runs out of memory, it notices when memory allocation patterns look weird and tells you "hey, this looks bad."
It uses a local LLM to spot patterns. Not trying to build AGI here - just pattern matching on process behavior. Turns out LLMs are actually pretty good at this.
Example: it flagged higher memory consumption over a short period and alerted me before it was too late. Turned out to be a memory leak that would've killed the process.
Quick start if you want to try it:
docker pull ghcr.io/linnix-os/cognitod:latest
docker-compose up -d
The main difference from tools like Prometheus: most monitoring parses /proc files. This uses eBPF to get data directly from the kernel. More accurate, way less overhead.
Built it in Rust using the Aya framework. No libbpf, no C - pure Rust all the way down. Makes the kernel interactions less scary.
Current state: - Works on any Linux 5.8+ with BTF - Monitors Docker/Kubernetes containers - Exports to Prometheus - Apache 2.0 license
Still rough around the edges. Actively working on it.
Would love to know: - What kinds of failures do you wish you could catch earlier? - Does this seem useful for your setup?
GitHub: https://github.com/linnix-os/linnix
Happy to answer questions about how it works. > The main difference from tools like Prometheus: most monitoring parses /proc files. This uses eBPF to get data directly from the kernel. More accurate, way less overhead. Cloudflare's Prometheus exporter for eBPF has been around for quite a while now. Neat but obvious AI slop (coming from someone who vibe codes a lot). The diagrams that don't align in the README, and a readme making ai typical bold claims that haven't been edited, make me doubt how much a human has even reviewed this software or tested it. If the author hasn't reviewed or tested it why should anyone else bother? I started this as a personal project to help with monitoring my personal projects. The eBPF monitoring works well - that part is solid. The AI part is experimental, especially the idea of running inference on CPU (can't afford GPUs and didn't want to rely on OpenAI APIs, though that's where it started). It's hit-or-miss depending on the model. Not production-tested at scale - just sharing in case it's useful to others who want to tinker with eBPF + Rust. Full transparency: I did use AI to help write the documentation because honestly, writing docs feels boring and will review thoroughly now based on your feedback Open sourcing something for the first times so trying and learning It does seem super cool! But if you aren't even editing the basic README.md - it's not that you used AI to help, but that you that you didn't even do the most basic editing, I don't know what to trust. If I can't trust the docs why spend my time? Love the direction
AI is marked as experimental and optional.
Would love a couple real-world examples with numbers to see how it behaves under load.
Feels genuinely useful; excited to try it on a messy environment. eBPF is so low level it feels like a mistake to let vibe coded slop exist there. I’ll have to pass until someone reputable reviews it, which I assume will be never.