Как я перевёл свой self-hosted мониторинг с JSONL на SQLite и заставил модули просить разрешения

[opium]

У WAL стоит отдельно проверить долгий запрос истории: он может удерживать старый снимок и мешать checkpoint завершиться, пока новые отчёты продолжают увеличивать WAL-файл. Проверил на двух соединениях SQLite: открытая читающая транзакция и 50 коротких INSERT с commit — checkpoint смог перенести только 2 из 52 страниц; после закрытия читателя журнал удалось обнулить. Это не означает, что у вас есть такая проблема, но для мониторинга полезен тест «читаем большой диапазон истории, пока агенты пишут». Ограничиваете ли вы время читающей транзакции и следите ли за размером WAL?

[zxchubbabubba]

Спасибо, проверили на используемом Go-драйвере и подтвердили сценарий. Закрытие транзакции предусмотрено, но отдельного deadline у HTTP-запроса истории и мониторинга WAL пока нет. Добавим ограничение времени чтения, наблюдение за WAL/checkpoint и конкурентный регрессионный тест.

[Fedasiaz]

Отличная статья. Переход с JSONL на SQLite в режиме WAL — это прямо классика эволюции self-hosted проектов.

Насчёт вашего вопроса про «операции с неизвестным исходом» и квитанции. Я разрабатываю агентов на базе LLM (для автоматизации обновления зависимостей и починки тестов), и там эта проблема стоит особенно остро. Агент может сделать коммит и запушить ветку, но если связь оборвется, мы не знаем, применился ли патч или нет.

В итоге мы пришли к тому же паттерну: храним состояние (хэш коммита, результат тестов) как «квитанцию». Но есть нюанс: если операция имеет внешние побочные эффекты (как перезапуск Docker-контейнера), квитанция подтверждает только то, что команда ушла, но не гарантирует, что сервис поднялся. Приходится делать отдельный идемпотентный healthcheck после выполнения. Интересно, как вы решаете эту проблему на уровне ОС — проверяете ли вы реальный статус процесса/контейнера перед тем, как считать операцию успешной, или просто полагаетесь на exit-code модуля?

И второй момент, про который вы писали: раз песочницы (seccomp/AppArmor) нет, а модуль живет с правами агента, то как вы отслеживаете, что модуль не оставил после себя «зомби»-процессы или не залез в чужие директории? Только аудит логов?

[zxchubbabubba]

Я, честно, в шоке от того, сколько можно узнать от людей в комментариях на Хабре. Когда писал проект, о некоторых таких сценариях даже не задумывался. Спасибо, что так подробно разобрали.

Полезли проверять код — и да, сейчас есть оба пробела. Мы проверяем не только exit-code, но и структурированный ответ модуля. Однако в Docker-модуле успешный ответ Docker API уже считается выполненной операцией. Отдельной проверки, что приложение внутри контейнера действительно поднялось и готово работать, пока нет. Состояние потом обновляется обычным сбором метрик, но это не то же самое, что проверка результата конкретного действия.

С дочерними процессами тоже нашли проблему: воспроизвели на Windows и Linux ситуацию, когда основной процесс модуля остановлен, а его потомок продолжает работать. Ограничения доступа к чужим директориям на уровне ОС сейчас нет — модуль работает с правами агента. Логами это надёжно не проконтролировать.

Так что не буду делать вид, что всё предусмотрел :) Забрал в доработку проверку состояния после действий и остановку дерева процессов. С файловой изоляцией нужно разбираться отдельно, пока нативный модуль — это именно доверенный код. Очень полезный комментарий, спасибо.