Linnix

Finde heraus, welcher Prozess deinen SLOs schadet — nicht nur, wer CPU nutzt, sondern wer Stalls verursacht.

Das Problem

top zeigt 80 % CPU. Prometheus zeigt hohe Latenz. Aber welcher Pod blockiert eigentlich deinen Zahlungsdienst?

Linnix verwendet eBPF + PSI (Pressure Stall Information), um diese Frage zu beantworten. PSI misst die tatsächliche Stall-Zeit — nicht die Nutzung, sondern die Konkurrenz (Contention). Ein Pod mit 40 % CPU-Auslastung und 60 % PSI ist schlimmer als einer mit 100 % CPU-Auslastung und 5 % PSI.

Was Linnix erkennt:

• Lärmende Nachbarn (Noisy Neighbors): Welcher Container andere aushungert
• Fork-Stürme: Unkontrollierte Prozesserstellung, bevor sie den Node zum Absturz bringt
• Stall-Zuordnung: „Pod X hat Pod Y einen Stall von 300 ms verursacht"
• PSI-Sättigung: CPU-/IO-/Speicherdruck, der in top nicht sichtbar ist

[!IMPORTANT] Standardmäßig nur Überwachung (Monitor-only). Linnix erkennt und meldet — es ergreift niemals Maßnahmen ohne explizite Konfiguration.

🔒 Sicherheit & Datenschutz

• Sicherheitsrichtlinie: Sieh dir unser Sicherheitsmodell, die erforderlichen Berechtigungen und den Prozess zur Meldung von Schwachstellen an
• Sicherheitsgarantien: Verstehe unsere „Monitor-First"-Architektur und Sicherheitskontrollen
• Architekturüberblick: Systemdiagramm und Datenfluss für Sicherheitsüberprüfungen

Wichtigstes Versprechen: Die gesamte Analyse findet lokal statt. Es verlassen keine Daten deine Infrastruktur, es sei denn, du konfigurierst explizit Slack-Benachrichtigungen. Mehr zum Datenschutz →

Schnellstart (Kubernetes)

Stelle Linnix als DaemonSet bereit, um deinen Cluster zu überwachen.

# Apply the manifests
kubectl apply -f k8s/

API-Zugriff:

kubectl port-forward daemonset/linnix-agent 3000:3000
# API available at http://localhost:3000
# Stream events: curl http://localhost:3000/stream

Schnellstart (Docker)

Teste es in 30 Sekunden auf deinem lokalen Rechner.

git clone https://github.com/linnix-os/linnix.git && cd linnix
./quickstart.sh

So funktioniert es

1. Collector (eBPF): Sitzt im Kernel und beobachtet fork-, exec-, exit- und Scheduler-Ereignisse mit weniger als 1 % Overhead.
2. Reasoning Engine: Aggregiert Signale (PSI + CPU + Prozessbaum), um Fehlermuster zu erkennen.
3. Triage-Assistent: Wenn ein Schwellenwert überschritten wird, erfasst Linnix den Systemzustand und erklärt die Ursache (Root Cause).

Unterstützte Erkennungen

Sicherheit & Architektur

Linnix ist auf Sicherheit im Produktionsbetrieb ausgelegt.

• Monitor-First: Durchsetzungsfunktionen (Enforcement) sind Opt-in und erfordern eine explizite Konfiguration.
• Geringer Overhead: Verwendet eBPF-Perf-Puffer, kein /proc-Polling.
• Berechtigungsisolierung: Kann auf Bare Metal mit CAP_BPF und CAP_PERFMON ausgeführt werden. Das Kubernetes-DaemonSet verwendet derzeit aus Einfachheitsgründen den privilegierten Modus.

Siehe SAFETY.md für unser detailliertes Sicherheitsmodell.

Kubernetes-Funktionen

Linnix bietet Kubernetes-Support erster Klasse:

• Pod-Zuordnung: Jedes Prozessereignis wird mit pod_name, namespace, container_id versehen
• Namespace-Bewusstsein: Nach Namespace filtern und abfragen
• PSI-Beitragsverfolgung: Sieh, welcher Pod zum systemweiten PSI-Druck beigetragen hat
• cgroup-Integration: Ordnet Prozesse ihren cgroups zu, für eine Aggregation auf Containerebene

# Example: Get processes causing stalls in the payments namespace
curl "http://localhost:3000/processes?namespace=payments&sort=psi_contribution"

Commerce / On-Chain-Abrechnung

Linnix enthält eine vertrauenslose Zahlungsschicht (Linnix-Claw), die Agenten-zu-Agenten-Arbeit über ERC-20-Stablecoins on-chain abrechnet. Wenn ein Agent eine Aufgabe an einen anderen delegiert, wird das Ergebnis — eine signierte Quittung mit Telemetrie-Nachweis — an einen TaskSettlement-Smart-Contract übermittelt, der die Zahlung direkt vom Zahlenden an den Zahlungsempfänger freigibt.

Architektur

Agent A (payer)                    Agent B (payee)
   │  createTask(taskId, payeeDID, maxAmount)
   │──────────────────────────────────▶│
   │                                   │ ← does work, captures eBPF telemetry
   │    submitReceipt(taskId, amount, receipt, sig)
   │◀──────────────────────────────────│
   │                                   │
   └──── TaskSettlement.sol ─── ERC-20 transfer ──▶ payee

Wichtige Verträge (Base-Sepolia-Testnetz):

Konfiguration

Füge deiner linnix.toml einen [chain]-Abschnitt hinzu:

[chain]
enabled = true
rpc_url = "https://sepolia.base.org"
chain_id = 84532
settlement_contract = "0x60eE6872920addF41359625B47A07401496bBD5b"
registry_contract = "0x9a6FeBA6d7B97ef91099051eB61F372d1EcD83a3"
token_address = "0x036CbD53842c5426634e7929541eC2318f3dCF7e"  # USDC on Base Sepolia
token_decimals = 6

Der Signaturschlüssel wird in folgender Prioritätsreihenfolge aufgelöst:

1. chain.private_key in der Konfiguration
2. Umgebungsvariable LINNIX_CHAIN_PRIVATE_KEY
3. Aus der Ed25519-Identität des Agenten abgeleiteter HKDF-secp256k1-Schlüssel (Standard — null Konfiguration)

End-to-End-Demo

# Deploy contracts to a local Hardhat node
cd linnix-claw-contracts && npx hardhat node &
npx hardhat run scripts/deploy.js --network localhost

# Run the commerce demo
./scripts/demo_commerce_e2e.sh --local

Siehe die Vertragsquelle und cognitod/src/onchain.rs für Implementierungsdetails.

Early Adopters

Dieses Projekt befindet sich in aktiver Entwicklung. Wenn du es verwendest oder evaluierst, erstelle ein Issue oder sende eine E-Mail an [email protected].

Lizenz

• Agent (cognitod): AGPL-3.0
• eBPF-Collector: GPL-2.0 oder MIT (eBPF-Programme müssen für das Laden in den Kernel GPL-kompatibel sein)

Kommerzielle Lizenzierung ist für Teams verfügbar, die AGPL nicht verwenden können. Siehe LICENSE_FAQ.md für Details.