Das Go-Tool Kula liest /proc und /sys im Sekundentakt, speichert in drei Speicher-Tiers und liefert Web-Dashboard, TUI und optionalen Ollama-Assistenten. Wir prüfen Mechanik, Installation und Grenzen.

Darf ich c0m4r/kula kommerziell nutzen?

Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.

Wird c0m4r/kula noch gepflegt?

Ja. Die letzten Commits kamen vor 1 Tag.

In welcher Programmiersprache ist c0m4r/kula geschrieben?

Hauptsächlich Go, laut der Sprachstatistik von GitHub.

Kula im Testbericht: Linux-Monitoring ohne Abhängigkeiten mit Ringpuffer-Speicher

Auf einen Blick

Was ist das?: Das Go-Tool Kula liest /proc und /sys im Sekundentakt, speichert in drei Speicher-Tiers und liefert Web-Dashboard, TUI und optionalen Ollama-Assistenten. Wir prüfen Mechanik, Installation und Grenzen.
Für wen ist es gedacht?: Kula eignet sich für Admins, die auf einzelnen Linux-Servern schnell Echtzeit-Monitoring aufbauen wollen, ohne Datenbanken oder Agentenlandschaften zu installieren, und die AGPL-3.0 akzeptieren. Ungeeignet ist es, wenn lange Aufbewahrungszeiträume jenseits der Ringpuffer-Kapazität oder zentrale Multi-Host-Sichten im Vordergrund stehen.
Darf ich es kommerziell nutzen?: Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
Wird es noch gepflegt?: Ja. Die letzten Commits kamen vor 1 Tag.
In welcher Sprache ist es geschrieben?: Hauptsächlich Go, laut der Sprachstatistik von GitHub.

Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.

TIEFGEHENDE OPEN-SOURCE-ANALYSE

Hysen Labs Redaktion · 8. August 2026 · c0m4r/kula

Kula im Sekundentakt: Kolonnen lesen /proc und /sys

Kula ist ein in Go geschriebenes Linux-Server-Überwachungswerkzeug mit einem klaren Versprechen: ein einzelnes Binary, keine externen Datenbanken, keine Laufzeitabhängigkeiten. Es sammelt Systemmetriken jede Sekunde, indem es direkt aus /proc und /sys liest, und stellt sie über ein Echtzeit-Web-Dashboard sowie ein Terminal-TUI bereit. Das Architekturdiagramm im README zeigt den Weg vom Linux-Kernel über /proc/stat, /proc/meminfo und /sys zu den Kolonnen für CPU, Speicher, Netz, Platten und System, die Live-Daten an die Speicher-Engine und die Oberflächen weiterreichen.

Die Metrikliste ist lang: CPU mit user, system, iowait, irq, softirq und steal, GPU-Last und VRAM, Load-Averages, Speicher und Swap, Durchsatz pro Netzwerkschnittstelle inklusive TCP-Fehlern und Retransmits, I/O pro Gerät, Uptime, Entropie, Prozesszustände, Temperaturen, Akkustatus über /sys/class/power_supply, Container für Docker, Podman und rohe Cgroups sowie Anwendungen wie PostgreSQL, MySQL/MariaDB, nginx und apache2. Für NVIDIA-GPUs verweist das README auf eine eigene Wiki-Seite, dort kann Zusatzkonfiguration nötig werden. Kula selbst meldet seine eigene CPU-Last, RSS-Speicher und offene Datei-Handles mit, ein ehrliches Detail für die Bewertung des Überwachungsaufwands.

Drei Speicher-Tiers: 250 MB Rohdaten, 150 MB Minutenwerte, 50 MB Fünfminutenwerte

Das Herzstück ist eine eigens gebaute Ringpuffer-Speicher-Engine, die Metriken direkt in Binärdateien fester Größe schreibt. Ist die Kapazität erreicht, überschreiben neue Daten die ältesten Einträge. Beim Start stellt Kula den Cache der letzten Samples wieder her und rekonstruiert ausstehende Aggregationspuffer, damit es nach einem Neustart aktuelle Daten und Rollups weiterliefern kann.

Die Struktur umfasst drei Stufen. Tier 1 hält rohe 1-Sekunden-Samples, standardmäßig 250 MB. Tier 2 aggregiert auf 1-Minuten-Werte mit Durchschnitt, Minimum und Maximum, standardmäßig 150 MB. Tier 3 fasst auf 5-Minuten-Werte zusammen, standardmäßig 50 MB. Das ergibt pro Host rund 450 MB Fixkosten und begrenzt die Historie naturgemäß: Ältere Daten als die Kapazität hergibt, existieren schlicht nicht. Das README erklärt nicht, ob sich die Tier-Größen über config.yaml anpassen lassen, obwohl es die Datei als Ort der Einstellungen nennt. Wer längere Aufbewahrung braucht, sollte deshalb den Prometheus-Exporter anschauen, der Scrapping in bestehende Stacks erlaubt, bevor er Kula als alleinige Historienquelle plant.

Dashboard mit Chart.js, WebSocket-Zoom und Alert-Schwellen

Das Frontend ist eine in das Binary eingebettete Single-Page-Anwendung, gebaut auf Chart.js mit eigenen SVG-Messgeräten. Live-Daten laufen über WebSocket, für längere Zeiträume fällt das Dashboard auf die History-API zurück. Praktische Funktionen laut README: Zoom per Drag-Auswahl, der den Live-Stream automatisch pausiert, ein Fokusmodus für einzelne Charts, konfigurierbare Y-Achsen-Grenzen, Geräteselektoren für Netzwerk, Platten-I/O und Thermik sowie ein Umschalter zwischen Raster- und Stapel-Layout.

Ein integriertes Alert-System meldet Uhr-Synchronisationsprobleme, niedrige Entropie und Systemüberlastung. Hell- und Dunkelthema sind schaltbar, ein Prometheus-Exporter-Endpunkt erlaubt das Abholen in bestehende Observability-Stacks. Für schnelle SSH-Sitzungen gibt es das TUI, das CPU, Speicher, Verkehr, Speicherdruck und kurzfristige Trends im Terminal zeigt. Der Webserver im Backend stellt zusätzlich eine REST-API bereit, sodass Skripte dieselben Daten abfragen können wie das Frontend.

Ollama-Assistent mit get_metrics und fünf Tool-Runden pro Zug

Ein kurioses Extra ist der optionale AI-Assistent über Ollama. Ist Ollama in config.yaml aktiviert, erscheint ein Robot-Button im Dashboard-Header. Das Panel unterstützt mehrere unabhängige Gesprächssitzungen, und per Klick auf das Icon eines Chart-Kards öffnet sich eine Session, die die letzten Daten dieses Charts als CSV vorgeladen bekommt. Das Modell kann agentisch das Tool get_metrics aufrufen, um bei Bedarf Metriken zu ziehen, bis zu fünf Runden pro Zug, und mid-session lässt sich zwischen lokal vorhandenen Ollama-Modellen umschalten.

Wichtig zur Einordnung: Alle Inferenzen laufen lokal über die Ollama-API, es gehen also keine Metrikdaten an externe Dienste. Das Panel lässt sich verschieben und skalieren, Antworten streamen mit Markdown-Rendering. Für den Alltag ist der Assistent ein Komfort-Feature, kein Kernargument: Die eigentliche Arbeit erledigen Charts, Alerts und der Prometheus-Endpunkt, aber für Ad-hoc-Fragen an historische Daten ist der CSV-Vorlade-Weg ein durchdachtes Detail.

Authentifizierung mit Argon2id und Bearer-Token im HTTP-Backend

Die Authentifizierung im HTTP-Backend ist optional. Bei Aktivierung nutzt Kula Argon2id für Passwort-Hashing, sichere Session-Cookies, reine Token-Validierung mit gleitender Ablaufzeit und eine Sitzungspersistenz, die gehasht am Liegen gespeichert wird. Authentifizierter API-Zugriff kann alternativ ein Bearer-Session-Token über den Authorization-Header verwenden, was Skriptzugriffe ohne Cookie-Handling erlaubt.

Das README beschreibt einen Befehl zum Erzeugen eines Passwort-Hashs, dessen Ausgabe in config.yaml unter web.auth eingetragen wird. Health-Endpunkte liegen unter /health und /status und antworten mit kula is healthy und 200 OK, was sich für Loadbalancer-Checks eignet. Nicht dokumentiert sind die exakten Cookie-Flags oder Standardwerte der Sitzungsdauer, hier bleibt nur ein Blick in den Quellcode. Angesichts von nur zwei offenen Issues bei 1318 Sternen wirkt der Code gepflegt, aber verifizieren lässt sich die Sicherheitsarchitektur allein aus dem README nicht.

Installation von install_v2.sh bis Snap und die AGPL-3.0-Frage

Kula wird für amd64-GNU/Linux ausgeliefert, ARM- und RISC-V-Pakete stehen in den Releases. Der geführte Weg läuft über bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install_v2.sh)", die vorsichtige Variante lädt das Skript nach mktemp, prüft die SHA-256-Prüfsumme bad61ee9eed4595d20fa7e613bd27c3b8700c67f8a5fcac756d282a811705398 und führt es erst danach aus. Wer es puristisch mag, lädt das tar.gz von Release 0.18.8, prüft 45ce3a6a06be92caec938d6d01884da0d81f1092ee9741c73b4ee03566411316 und startet ./kula.

Alternativ gibt es Docker-Befehle mit --pid host und --network host, mit kula_data-Volume für persistente Speicherung, dazu .deb- und .rpm-Pakete mit Prüfsummen, ein AUR-Paket und ein Snap. Beim Snap warnt das README selbst, dass die standardmäßig strenge Sandbox Funktionen einschränkt. Bemerkenswert ist die Warnung im README, niemals Befehle gedankenlos einzufügen, denn Prüfsummen seien kein Ersatz fürs Lesen des Codes. Die AGPL-3.0-Lizenz verlangt, dass Betreiber eines Netzwerkdienstes Nutzern den Quellcode modifizierter Versionen anbieten, bei reinem internen Monitoring ohne Weitergabe an Nutzer ist das unkritisch, bei angepasstem externem Hosting aber zu beachten. Aktuelle Release-Folge: 0.18.6 vom Juli 2026, 0.18.7 und 0.18.8 wenige Tage später.

Redaktionelles Fazit

Kula eignet sich für Admins, die auf einzelnen Linux-Servern schnell Echtzeit-Monitoring aufbauen wollen, ohne Datenbanken oder Agentenlandschaften zu installieren, und die AGPL-3.0 akzeptieren. Ungeeignet ist es, wenn lange Aufbewahrungszeiträume jenseits der Ringpuffer-Kapazität oder zentrale Multi-Host-Sichten im Vordergrund stehen. Vor dem Produktiveinsatz sollte man den Prometheus-Endpunkt in die bestehende Observability-Stack einbinden und mit config.yaml prüfen, ob Authentifizierung und Tier-Größen zum eigenen Setup passen.

Offizielle Quellen

Community-Notizen