ltm es un depurador de historial de máquina para Linux. Registra metadatos de procesos, archivos, red, memoria y E/S de bloque a través de eBPF, luego te permite consultar la línea de tiempo.
Depurador de historial de máquina para Linux. Registra procesos, archivos, red, memoria y E/S de bloque mediante eBPF, almacena metadatos en SQLite y responde preguntas sobre la línea de tiempo / diferencias / inglés simple / SQL sobre lo que sucedió en el sistema.
⚠️ Captura solo mediante tracepoints hoy — la grabación actualmente utiliza programas tracepoint. Aún no utiliza kprobes, uprobes, XDP o hooks TC, por lo que favorece metadatos estables de syscall/bloque/proceso sobre internas más profundas del kernel, rastreo de funciones en espacio de usuario o inspección de ruta de paquetes.
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
La grabación necesita root (o CAP_BPF + CAP_PERFMON). Consultar no.
Sin un grabador Linux en vivo: ltm benchmark --count 1000 siembra eventos sintéticos en una BD que puedes inspeccionar con , y .
timelinediffqueryLas banderas globales van antes del subcomando (ltm --db /tmp/ltm.db status).
Valores por defecto: BD ~/.local/share/ltm/ltm.db, PID ~/.local/run/ltm.pid.
Añade --json a cualquier comando de lectura para salida legible por máquina.
| Comando | Qué hace |
|---|---|
start / stop / status | controla el grabador |
timeline | filtrar por --pid --uid --comm --category --action --path --exe --since --until --limit (repetible; --path/--exe son SQL LIKE) |
watch | cola en vivo (--interval --since --category --comm --pid) |
diff --from --to | cambios de estado de la máquina entre dos tiempos |
query "<question>" | inglés simple (plantillas, o un agente → SQL) |
query sql ["<SELECT>"] | SQL solo lectura; sin argumento imprime el esquema (ltm sql también funciona) |
prune --older-than 720h [--vacuum] | elimina filas antiguas, opcionalmente recupera espacio en disco |
benchmark --count N | escribe N eventos sintéticos (sin eBPF) |
version | versión de compilación, commit, plataforma |
Una base de datos SQLite, escritor WAL mantenido por el demonio. Cada ruta de lectura abre en solo lectura (PRAGMA query_only=ON) — las consultas nunca compiten con el escritor ni mutan el registro. Solo metadatos; sin contenidos de archivos.
export LTM_AGENT=claude # or codex, cursor, gemini, auto, or a custom command
ltm query "which process wrote to files the most today?"
El SQL del agente se imprime, luego se ejecuta en la conexión de solo lectura, y se rechaza a menos que sea un único SELECT. Sin agente (o fallo del agente) → plantillas integradas.
~60 tracepoints: procesos (exec, exit, fork, clone, kill), archivos
(open/close, read/write, rename, unlink, link, symlink, mkdir, rmdir, chmod,
chown, stat, access, truncate, dup, pipe, …), memoria (mmap, munmap,
mprotect), red (socket, connect, bind, listen, accept, send/recv,
shutdown), bloque (block_rq_issue).
BPF omite /proc, /sys, /dev y el propio PID del demonio. El manifiesto de tracepoints escrito a mano está en internal/abi/abi.yaml; la tabla de tiempo de ejecución registrada se genera en internal/abi/tracepoints_gen.go. Después de editar collector.bpf.c, reconstruir con make ebpf. Después de editar metadatos ABI en internal/abi/abi.yaml, ejecutar make generate y luego make ebpf si la disposición de eventos del kernel o la tabla de tracepoints cambia.
-D__TARGET_ARCH_x86
(#2). La consulta y los datos de demostración generados por benchmark no requieren soporte de grabación en Linux.readv/writev/sendmsg/recvmsg reportan 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
Disposición: cmd/ltm punto de entrada; todo lo demás bajo internal/
(abi, cli, daemon, collector, ebpf, storage, agent, diff, query).
El generador de ABI/esquema mantiene las definiciones de eventos, DDL de almacenamiento, metadatos de tracepoints y estructuras orientadas al kernel vinculadas a una única fuente de verdad:
internal/abi/abi.yaml. Es intencionalmente similar en espíritu al flujo de trabajo de Argument Clinic de CPython
(fuente):
al agregar nueva superficie de evento/módulo capturada, actualiza el manifiesto y
regenera las salidas registradas en lugar de editar manualmente archivos Go o C derivados.