Show HN: Linnix – eBPF observability that predicts failures before they happen
Hacker News (score: 18)Description
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.
More from Hacker
Show HN: Tusk Drift – Turn production traffic into API tests
Show HN: Tusk Drift – Turn production traffic into API tests Hi HN! In the past few months my team and I have been working on Tusk Drift, a system that records real API traffic from your service, then replays those requests as deterministic tests. Outbound I/O (databases, HTTP calls, etc.) gets automatically mocked using the recorded data.<p>Problem we're trying to solve: Writing API tests is tedious, and hand-written mocks drift from reality. We wanted tests that stay realistic because they come from real traffic.<p>versus mocking libraries: Tools like VCR/Nock intercept HTTP within your tests. Tusk Drift records full request/response traces externally (HTTP, DB, Redis, etc.) and replays them against your running service, no test code or fixtures to write/maintain.<p>How it works:<p>1. Add a lightweight SDK (we currently support Python and Node.js)<p>2. Record traffic in any environment.<p>3. Run `tusk run`, the CLI sandboxes your service and serves mocks via Unix socket<p>We run this in CI on every PR. Also been using it as a test harness for AI coding agents, they can make changes, run `tusk run`, and get immediate feedback without needing live dependencies.<p>Source: <a href="https://github.com/Use-Tusk/tusk-drift-cli" rel="nofollow">https://github.com/Use-Tusk/tusk-drift-cli</a><p>Demo: <a href="https://github.com/Use-Tusk/drift-node-demo" rel="nofollow">https://github.com/Use-Tusk/drift-node-demo</a><p>Happy to answer questions!
Show HN: Yolobox – Run AI coding agents with full sudo without nuking home dir
Show HN: Yolobox – Run AI coding agents with full sudo without nuking home dir
Sandbox: Run untrusted AI code safely, fast
Sandbox: Run untrusted AI code safely, fast
Show HN: Bithoven – A high-level, imperative language for Bitcoin Smart Contract
Show HN: Bithoven – A high-level, imperative language for Bitcoin Smart Contract Hey HN! I’m a researcher working on Bitcoin smart contracts, and today I’m releasing Bithoven—a high-level imperative language that compiles to native Bitcoin Script (Legacy, SegWit, and Taproot).<p>The Goal:<p>Raw Bitcoin Script is notoriously difficult to reason about. Writing raw Bitcoin Script today feels like writing Assembly in the 1970s. You have to mentally juggle the stack (`OP_SWAP`, `OP_ROT`), manually manage distinct execution branches, and pray you didn't leave a stack item unconsumed (which crashes the script). My goal was to bridge the gap between complex contract logic and raw opcodes, allowing developers to write readable, compile-time-safe code.<p>Key Features:<p>- Imperative Syntax: Write logic using familiar if/else and return statements instead of mental stack juggling.<p>- Type Safety: First-class support for bool, signature, string, and number types to prevent runtime errors.<p>- Targeted Compilation: Support for Legacy, SegWit, and Taproot compilation targets.<p>- Native Primitives: Built-in keywords for timelocks (older, after) and cryptography (sha256, checksig).<p>You can try it in the browser here (runs via WASM): <a href="https://bithoven-lang.github.io/bithoven/ide/" rel="nofollow">https://bithoven-lang.github.io/bithoven/ide/</a><p>Here is an example of a Hashed Time-Locked Contract (HTLC):<p><pre><code> (condition: bool, sig_alice: signature) (condition: bool, preimage: string, sig_bob: signature) { if condition { // Relative locktime (Sequence) older 1000; return checksig (sig_alice, alice_pk); } else { // Hashlock verification verify sha256 sha256 preimage == hash; return checksig (sig_bob, bob_pk); } } </code></pre> The project is free open source and the academic paper is currently under review. I’d love to hear any feedback. Thanks for checking it out!
No other tools from this source yet.