ltm ist ein Maschinenverlaufs-Debugger für Linux. Es zeichnet Prozess-, Datei-, Netzwerk-, Speicher- und Block-I/O-Metadaten via eBPF auf und ermöglicht es dir, die Zeitleiste abzufragen.
Debugger für den Maschinenverlauf unter Linux. Zeichnet Prozess-, Datei-, Netzwerk-, Speicher- und Block-I/O über eBPF auf, speichert Metadaten in SQLite und beantwortet Zeitachsen-/Diff-/Klartext-/SQL-Fragen zu dem, was auf dem Rechner passiert ist.
⚠️ Derzeit nur Tracepoint-Erfassung — die Aufzeichnung verwendet derzeit Tracepoint-Programme. Es verwendet noch keine kprobes, uprobes, XDP oder TC-Hooks, bevorzugt also stabile Syscall-/Block-/Prozess-Metadaten gegenüber tieferen Kernel-Interna, User-Space-Funktionstracing oder Paketpfad-Inspektion.
go build -o bin/ltm ./cmd/ltm
sudo ./bin/ltm start # record (eBPF; root, Linux/x86_64)
./bin/ltm timeline --since 5m
./bin/ltm watch # live tail; Ctrl-C to stop
./bin/ltm diff --from 10m --to now
./bin/ltm query "who modified /etc/some.conf?"
sudo ./bin/ltm stop
Für die Aufzeichnung ist root (oder CAP_BPF + CAP_PERFMON) erforderlich. Für Abfragen nicht. Ohne einen Live-Linux-Recorder: ltm benchmark --count 1000 erzeugt synthetische Ereignisse in einer DB, die Sie mit timeline, und untersuchen können.
diffqueryGlobale Flags stehen vor dem Unterbefehl (ltm --db /tmp/ltm.db status). Standardwerte: DB ~/.local/share/ltm/ltm.db, PID ~/.local/run/ltm.pid. Fügen Sie --json zu jedem Lesebefehl hinzu, um maschinenlesbare Ausgabe zu erhalten.
| Befehl | Was er tut |
|---|---|
start / stop / status | Recorder steuern |
timeline | filtern nach --pid --uid --comm --category --action --path --exe --since --until --limit (wiederholbar; --path/--exe sind SQL LIKE) |
watch | Live-Tail (--interval --since --category --comm --pid) |
diff --from --to | Maschinenstatusänderungen zwischen zwei Zeitpunkten |
query "<question>" | Klartext (Vorlagen oder ein Agent → SQL) |
query sql ["<SELECT>"] | schreibgeschütztes SQL; kein Argument gibt das Schema aus (ltm sql funktioniert auch) |
prune --older-than 720h [--vacuum] | alte Zeilen löschen, optional Speicherplatz freigeben |
benchmark --count N | N synthetische Ereignisse schreiben (kein eBPF) |
version | Build-Version, Commit, Plattform |
Eine SQLite-Datenbank, WAL-Schreiber vom Daemon gehalten. Jeder Lesepfad öffnet schreibgeschützt (PRAGMA query_only=ON) — Abfragen konkurrieren niemals mit dem Schreiber oder verändern das Log. Nur Metadaten; keine Dateiinhalte.
export LTM_AGENT=claude # or codex, cursor, gemini, auto, or a custom command
ltm query "which process wrote to files the most today?"
Agent-SQL wird ausgegeben, dann auf der schreibgeschützten Verbindung ausgeführt und abgelehnt, sofern es sich nicht um ein einzelnes SELECT handelt. Kein Agent (oder Agent-Fehler) → eingebaute Vorlagen.
~60 Tracepoints: Prozess (exec, exit, fork, clone, kill), Datei (open/close, read/write, rename, unlink, link, symlink, mkdir, rmdir, chmod, chown, stat, access, truncate, dup, pipe, …), Speicher (mmap, munmap, mprotect), Netzwerk (socket, connect, bind, listen, accept, send/recv, shutdown), Block (block_rq_issue).
BPF überspringt /proc, /sys, /dev und die eigene PID des Daemons. Das handgeschriebene Tracepoint-Manifest befindet sich in internal/abi/abi.yaml; die eingecheckte Laufzeittabelle wird in internal/abi/tracepoints_gen.go generiert. Nach Bearbeitung von collector.bpf.c mit make ebpf neu erstellen. Nach Bearbeitung der ABI-Metadaten in internal/abi/abi.yaml führen Sie make generate und dann make ebpf aus, wenn sich das Kernel-Ereignis-Layout oder die Tracepoint-Tabelle geändert hat.
-D__TARGET_ARCH_x86 erstellt (#2). Abfragen und benchmark-generierte Demodaten erfordern keine Linux-Aufzeichnungsunterstützung.readv/writev/sendmsg/recvmsg melden 0.go test ./... # local/unit tests
make generate # regenerate ABI/schema outputs from abi.yaml
make ebpf # regenerate checked-in BPF object/bindings (Linux)
make integration # real eBPF recording; Linux + root
Aufbau: cmd/ltm Einstiegspunkt; alles andere unter internal/ (abi, cli, daemon, collector, ebpf, storage, agent, diff, query).
Der ABI/Schema-Generator hält Ereignisdefinitionen, Speicher-DDL, Tracepoint-Metadaten und Kernel-seitige Strukturen an eine einzige Quelle der Wahrheit gebunden: internal/abi/abi.yaml. Er ist bewusst ähnlich im Geiste wie CPythons Argument Clinic-Workflow (Quelle): Wenn Sie neue erfasste Ereignis-/Moduloberflächen hinzufügen, aktualisieren Sie das Manifest und generieren Sie die eingecheckten Ausgaben neu, anstatt abgeleitete Go- oder C-Dateien manuell zu bearbeiten.