Журнал обращений к источникам

Платформа записывает, кто и каким запросом обращался к источнику данных. Журнал отвечает на вопрос «кто это выполнил» — например, когда на боевой базе всплыл тяжёлый запрос или служба безопасности спрашивает, кто читал таблицу с персональными данными.

Экрана пока нет

Журнал доступен запросом GET /api/data-source/{id}/audit тому, у кого есть право управления этим источником. Страница в интерфейсе запланирована отдельно; когда появится, раздел будет дополнен.

Что попадает в журнал

Записываются все шесть путей, которыми запрос уходит на источник:

Вид записи	Когда появляется
Произвольный SQL	Пользователь выполняет запрос к источнику вручную
Запрос метаданных по SQL	Платформа выясняет состав колонок произвольного запроса
Просмотр объекта	Открыта карточка источника, показаны строки таблицы
Прямой запрос виджета	Виджет читает данные из источника
Федеративный запрос	Данные собираются из нескольких источников сразу
Чтение при извлечении	ETL забирает данные в витрину

Что видно в записи

Поле	Что показывает
Вид записи	Один из шести путей выше
Источник	Его идентификатор, тип, хост и база — координаты на момент запроса
Кто	Идентификатор и имя пользователя
Текст запроса	Полный SQL, усечённый до предела из настроек (по умолчанию 10 000 символов)
Когда и сколько	Время начала и длительность в миллисекундах
Чем закончилось	Успех или ошибка с текстом
Идентификатор запроса	Сшивает запись с логами приложения

Имя пользователя хранится копией, а не ссылкой: удаление учётной записи не должно стирать след её действий. По той же причине записи неизменяемы — их пишут один раз и больше не трогают.

У фоновых задач исполнителя нет

У записей ETL-извлечения и других фоновых операций пользователь не указан: их запускает не человек, а расписание. У федеративного запроса не указан и источник — он обращается сразу к нескольким, поэтому вместо единого SQL сохраняется план запроса.

В записи виден итоговый SQL — тот, что реально ушёл в базу, вместе с подставленными правилами видимости строк. Проверено на демо-стенде: в журнале сохранился запрос виджета с условием WHERE city = 'Москва' OR 'explorer' = 'creator' — так выглядит правило-выражение после подстановки. По журналу видно не только кто и что запрашивал, но и какие ограничения к нему применились.

Как читать журнал

Запрос отдаёт записи одного источника постранично, свежие сверху. Доступны фильтры:

• период — с какого по какое время;
• вид записи — например, только произвольный SQL;
• только ошибки — когда нужно разобрать неудачные обращения.

Право на чтение журнала даёт управление доступом к источнику: тот, кто может менять права на источник, видит и его журнал. Сводного журнала по всем источникам сразу пока нет.

Сколько хранится

Записи старше срока хранения удаляются по расписанию; по умолчанию срок — 90 суток. Значение меняет администратор при развёртывании.

Удаление идёт пачками, а не одним запросом: на миллионах строк одиночная операция удерживала бы блокировки и мешала работе базы.

Чего в журнале нет

• Изменений самого источника. Кто поменял хост, пароль или Initial SQL, журнал не покажет — это отдельная задача, она решается историей значений полей.
• Запросов, выполненных в обход платформы. Журнал видит только то, что прошло через неё.