ltm est un débogueur d'historique machine pour Linux. Il enregistre les métadonnées de processus, fichiers, réseau, mémoire et E/S de bloc via eBPF, puis vous permet d'interroger la chronologie.
Débogueur d'historique machine pour Linux. Enregistre les E/S de processus, fichiers, réseau, mémoire et bloc via eBPF, stocke les métadonnées dans SQLite, et répond aux questions de type chronologie / diff / langage naturel / SQL sur ce qui s'est passé sur la machine.
⚠️ Capture exclusivement par tracepoints aujourd'hui — l'enregistrement utilise actuellement des programmes tracepoint. Il n'utilise pas encore kprobes, uprobes, XDP ou crochets TC, privilégiant ainsi des métadonnées stables d'appels système/bloc/processus plutôt que des mécanismes noyau plus profonds, le traçage de fonctions en espace utilisateur ou l'inspection du chemin des paquets.
go build -o bin/ltm ./cmd/ltm
sudo ./bin/ltm start # enregistrer (eBPF ; root, Linux/x86_64)
./bin/ltm timeline --since 5m
./bin/ltm watch # suivi en direct ; Ctrl-C pour arrêter
./bin/ltm diff --from 10m --to now
./bin/ltm query "qui a modifié /etc/some.conf ?"
sudo ./bin/ltm stop
L'enregistrement nécessite root (ou CAP_BPF + CAP_PERFMON). Les requêtes non.
Sans enregistreur Linux actif : ltm benchmark --count 1000 génère des événements synthétiques dans une base de données que vous pouvez inspecter avec timeline, diff et query.
Les options globales se placent avant la sous-commande (ltm --db /tmp/ltm.db status). Valeurs par défaut : base ~/.local/share/ltm/ltm.db, PID ~/.local/run/ltm.pid.
Ajoutez --json à toute commande de lecture pour une sortie exploitable par machine.
| Commande | Ce qu'elle fait |
|---|---|
start / stop / status | contrôler l'enregistreur |
timeline | filtrer par --pid --uid --comm --category --action --path --exe --since --until --limit (répétable ; --path/--exe sont SQL LIKE) |
watch | suivi en direct (--interval --since --category --comm --pid) |
diff --from --to | changements d'état machine entre deux instants |
query "<question>" | langage naturel (modèles, ou un agent → SQL) |
query sql ["<SELECT>"] | SQL en lecture seule ; sans argument, affiche le schéma (ltm sql fonctionne aussi) |
prune --older-than 720h [--vacuum] | supprimer les anciennes lignes, éventuellement récupérer de l'espace disque |
benchmark --count N | écrire N événements synthétiques (sans eBPF) |
version | version du build, commit, plateforme |
Une base de données SQLite, le journal WAL est détenu par le démon. Chaque chemin de lecture ouvre en lecture seule (PRAGMA query_only=ON) — les requêtes n'entrent jamais en conflit avec l'écrivain ni ne modifient le journal. Métadonnées uniquement ; pas de contenu de fichiers.
export LTM_AGENT=claude # ou codex, cursor, gemini, auto, ou une commande personnalisée
ltm query "quel processus a le plus écrit dans des fichiers aujourd'hui ?"
Le SQL de l'agent est affiché, puis exécuté sur la connexion en lecture seule, et rejeté s'il ne s'agit pas d'un unique SELECT. Pas d'agent (ou échec de l'agent) → modèles intégrés.
~60 tracepoints : processus (exec, exit, fork, clone, kill), fichier (open/close, read/write, rename, unlink, link, symlink, mkdir, rmdir, chmod, chown, stat, access, truncate, dup, pipe, …), mémoire (mmap, munmap, mprotect), réseau (socket, connect, bind, listen, accept, send/recv, shutdown), bloc (block_rq_issue).
BPF ignore /proc, /sys, /dev et le propre PID du démon. Le manifeste des tracepoints écrit à la main se trouve dans internal/abi/abi.yaml ; la table d'exécution vérifiée dans le dépôt est générée dans internal/abi/tracepoints_gen.go. Après avoir modifié collector.bpf.c, reconstruisez avec make ebpf. Après avoir modifié les métadonnées ABI dans internal/abi/abi.yaml, exécutez make generate puis make ebpf si la disposition des événements noyau ou la table des tracepoints a changé.
-D__TARGET_ARCH_x86 (#2). Les requêtes et les données de démonstration générées par benchmark ne nécessitent pas de support d'enregistrement Linux.readv/writev/sendmsg/recvmsg rapportent 0.go test ./... # tests locaux/unitaires
make generate # régénérer les sorties ABI/schéma depuis abi.yaml
make ebpf # régénérer l'objet BPF/liens vérifiés dans le dépôt (Linux)
make integration # enregistrement eBPF réel ; Linux + root
Disposition : point d'entrée cmd/ltm ; tout le reste sous internal/ (abi, cli, daemon, collector, ebpf, storage, agent, diff, query).
Le générateur ABI/schéma maintient les définitions d'événements, le DDL de stockage, les métadonnées des tracepoints et les structures noyau liés à une source unique de vérité : internal/abi/abi.yaml. Il est intentionnellement similaire en esprit au flux de travail Argument Clinic de CPython (source) : lors de l'ajout d'une nouvelle surface d'événement/module capturée, mettez à jour le manifeste et régénérez les sorties vérifiées dans le dépôt au lieu de modifier à la main les fichiers Go ou C dérivés.
Documentation : docs/ (ABI, CLI, fichiers générés, interrogation, enregistrement, architecture, sécurité). Règles pour les contributeurs : AGENTS.md.