ltm — это отладчик истории выполнения для Linux. Он записывает метаданные процессов, файлов, сети, памяти и блочного ввода-вывода через eBPF, а затем позволяет запрашивать временную шкалу.
Отладчик истории машин для Linux. Записывает операции процессов, файлов, сети, памяти и блочного ввода-вывода через eBPF, сохраняет метаданные в SQLite и отвечает на вопросы о временной шкале / различиях / обычным английским / SQL о том, что произошло на машине.
⚠️ Запись только через tracepoint — в настоящее время запись использует программы tracepoint. Она еще не использует kprobes, uprobes, XDP или перехватчики TC, поэтому отдает предпочтение стабильным метаданным системных вызовов/блоков/процессов, а не более глубоким внутренним компонентам ядра, трассировке функций пользовательского пространства или инспекции пути пакета.
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
Для записи требуется root (или CAP_BPF + CAP_PERFMON). Запросы не требуют. Без работающего рекордера Linux: ltm benchmark --count 1000 заполняет базу данных синтетическими событиями, которые можно просматривать с помощью , и .
timelinediffqueryГлобальные флаги указываются перед подкомандой (ltm --db /tmp/ltm.db status). По умолчанию: БД ~/.local/share/ltm/ltm.db, PID ~/.local/run/ltm.pid. Добавьте --json к любой команде чтения для вывода в машиночитаемом формате.
| Команда | Описание |
|---|---|
start / stop / status | управление рекордером |
timeline | фильтрация по --pid --uid --comm --category --action --path --exe --since --until --limit (повторяемо; --path/--exe — это SQL LIKE) |
watch | прямой просмотр в реальном времени (--interval --since --category --comm --pid) |
diff --from --to | изменения состояния машины между двумя временными точками |
query "<question>" | обычным английским (шаблоны или агент → SQL) |
query sql ["<SELECT>"] | только для чтения SQL; без аргумента выводит схему (ltm sql также работает) |
prune --older-than 720h [--vacuum] | удаление старых строк, с возможностью освобождения дискового пространства |
benchmark --count N | запись N синтетических событий (без eBPF) |
version | версия сборки, коммит, платформа |
Одна база данных SQLite, писатель WAL удерживается демоном. Каждый путь чтения открывается только для чтения (PRAGMA query_only=ON) — запросы никогда не конкурируют с писателем и не изменяют журнал. Только метаданные; содержимое файлов не сохраняется.
export LTM_AGENT=claude # or codex, cursor, gemini, auto, or a custom command
ltm query "which process wrote to files the most today?"
SQL агента выводится, затем выполняется в соединении только для чтения и отклоняется, если это не одиночный SELECT. Если агент отсутствует (или произошел сбой агента) → встроенные шаблоны.
~60 tracepoints: process (exec, exit, fork, clone, kill), file (open/close, read/write, rename, unlink, link, symlink, mkdir, rmdir, chmod, chown, stat, access, truncate, dup, pipe, …), memory (mmap, munmap, mprotect), network (socket, connect, bind, listen, accept, send/recv, shutdown), block (block_rq_issue).
BPF пропускает /proc, /sys, /dev и собственный PID демона. Рукописный манифест tracepoint находится в internal/abi/abi.yaml; проверенная таблица времени выполнения генерируется в internal/abi/tracepoints_gen.go. После редактирования collector.bpf.c пересоберите с помощью make ebpf. После редактирования метаданных ABI в internal/abi/abi.yaml выполните make generate, а затем make ebpf, если изменилась раскладка событий ядра или таблица tracepoint.
-D__TARGET_ARCH_x86 (#2). Запросы и демонстрационные данные, сгенерированные benchmark, не требуют поддержки записи на Linux.readv/writev/sendmsg/recvmsg сообщают 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
Структура: точка входа cmd/ltm; все остальное в internal/ (abi, cli, daemon, collector, ebpf, storage, agent, diff, query).
Генератор ABI/схемы хранит определения событий, DDL для хранения, метаданные tracepoint и структуры для ядра, привязанные к единому источнику истины: internal/abi/abi.yaml. Он намеренно похож по духу на рабочий процесс Argument Clinic из CPython (исходник): при добавлении новой захватываемой поверхности событий/модулей обновляйте манифест и перегенерируйте проверенные выходные файлы вместо ручного редактирования производных файлов Go или C.