ltm é um depurador de histórico de máquina para Linux. Ele registra metadados de processos, arquivos, rede, memória e E/S de bloco via eBPF, e então permite consultar a linha do tempo.
Depurador de histórico de máquina para Linux. Registra processos, arquivos, rede, memória e E/S de bloco via eBPF, armazena metadados no SQLite e responde a perguntas de timeline / diff / inglês simples / SQL sobre o que aconteceu na máquina.
⚠️ Captura apenas com tracepoints atualmente — a gravação atualmente usa programas de tracepoint. Ainda não usa kprobes, uprobes, XDP ou hooks TC, portanto favorece metadados estáveis de syscall/bloco/processo em detrimento de internals mais profundos do kernel, rastreamento de funções em espaço de usuário ou inspeção de caminho de pacotes.
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
A gravação requer root (ou CAP_BPF + CAP_PERFMON). A consulta não. Sem um gravador Linux ativo: ltm benchmark --count 1000 semeia eventos sintéticos em um banco de dados que você pode inspecionar com timeline, diff e query.
Flags globais vão antes do subcomando (ltm --db /tmp/ltm.db status). Padrões: DB ~/.local/share/ltm/ltm.db, PID ~/.local/run/ltm.pid. Adicione --json a qualquer comando de leitura para saída legível por máquina.
| Comando | O que faz |
|---|---|
start / stop / status | controla o gravador |
timeline | filtra por --pid --uid --comm --category --action --path --exe --since --until --limit (repetível; --path/--exe são SQL LIKE) |
watch | acompanhamento ao vivo (--interval --since --category --comm --pid) |
diff --from --to | mudanças no estado da máquina entre dois horários |
query "<pergunta>" | inglês simples (modelos, ou um agente → SQL) |
query sql ["<SELECT>"] | SQL somente leitura; sem argumento imprime o esquema (ltm sql também funciona) |
prune --older-than 720h [--vacuum] | remove linhas antigas, opcionalmente recuperando espaço em disco |
benchmark --count N | escreve N eventos sintéticos (sem eBPF) |
version | versão da compilação, commit, plataforma |
Um banco de dados SQLite, gravador WAL mantido pelo daemon. Cada caminho de leitura abre somente leitura (PRAGMA query_only=ON) — as consultas nunca competem com o gravador nem alteram o log. Apenas metadados; sem conteúdos de arquivos.
export LTM_AGENT=claude # or codex, cursor, gemini, auto, or a custom command
ltm query "which process wrote to files the most today?"
O SQL do agente é impresso, então executado na conexão somente leitura, e rejeitado a menos que seja um único SELECT. Sem agente (ou falha do agente) → modelos internos.
~60 tracepoints: processo (exec, exit, fork, clone, kill), arquivo (open/close, read/write, rename, unlink, link, symlink, mkdir, rmdir, chmod, chown, stat, access, truncate, dup, pipe, …), memória (mmap, munmap, mprotect), rede (socket, connect, bind, listen, accept, send/recv, shutdown), bloco (block_rq_issue).
O BPF pula /proc, /sys, /dev e o próprio PID do daemon. O manifesto de tracepoint escrito à mão está em internal/abi/abi.yaml; a tabela de runtime verificada é gerada em internal/abi/tracepoints_gen.go. Após editar collector.bpf.c, reconstrua com make ebpf. Após editar metadados ABI em internal/abi/abi.yaml, execute make generate e depois make ebpf se o layout do evento do kernel ou a tabela de tracepoints mudaram.
-D__TARGET_ARCH_x86 (#2). Consulta e dados de demonstração gerados por benchmark não exigem suporte de gravação Linux.readv/writev/sendmsg/recvmsg reportam 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
Estrutura: cmd/ltm ponto de entrada; todo o resto sob internal/ (abi, cli, daemon, collector, ebpf, storage, agent, diff, query).
O gerador de ABI/esquema mantém definições de evento, DDL de armazenamento, metadados de tracepoints e structs voltadas para o kernel vinculados a uma única fonte de verdade: internal/abi/abi.yaml. É intencionalmente semelhante em espírito ao fluxo de trabalho do Argument Clinic do CPython (fonte): ao adicionar nova superfície de evento/módulo capturada, atualize o manifesto e regenere as saídas verificadas em vez de editar manualmente arquivos Go ou C derivados.
Documentação: docs/ (ABI, CLI, arquivos gerados, consulta, gravação, arquitetura, segurança). Regras para contribuidores: AGENTS.md.