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

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

Поиска по журналу нет

Фильтры отбирают период, вид обращения и неудачные попытки. Отобрать записи одного пользователя или найти обращения к конкретной таблице нечем: колонки Пользователь и Начало сортируются, но поиска по тексту запроса в текущей версии нет. На большом журнале отбирайте узкий период и сортируйте по пользователю, а дальше просматривайте записи глазами.

Как открыть

Откройте источник и нажмите Журнал на его карточке — страница живёт по адресу /sources/<номер источника>/audit. Журнал видит тот, у кого есть право управления этим источником.

Записи идут свежими сверху; счётчик рядом с заголовком показывает, сколько их попало в текущий отбор. Кнопка Обновить перечитывает список, К источнику возвращает на карточку.

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

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

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

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

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

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

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

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

В записи виден итоговый SQL — тот, что реально ушёл в базу, вместе с подставленными правилами видимости строк. Например, условие WHERE city = 'Москва' OR 'petrov' = 'ivanov' — это правило-выражение [customers.city] = 'Москва' OR USER_NAME() = 'ivanov' после подстановки: вместо USER_NAME() встал логин того, кто выполнял запрос, и сравнение 'petrov' = 'ivanov' оказалось ложным. По журналу видно не только кто и что запрашивал, но и какие ограничения к запросу применились.

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

В таблице шесть колонок: Начало, Вид, Результат, Длительность, Пользователь и Запрос. Ещё две — Ошибка и Запрос HTTP — по умолчанию скрыты и включаются настройкой колонок. Время показывается в часовом поясе вашего компьютера, длительность — в миллисекундах, секундах или минутах, смотря сколько запрос занял. У обращений без пользователя в колонке стоит «Система», а у пришедших по публичной ссылке на дашборд — share:<номер ссылки>: данные считаются от имени того, кто ссылку выпустил, и по такой записи видно, что запрос пришёл снаружи и по какой именно ссылке.

Щелчок по времени открывает запись целиком — с полным текстом запроса и ошибки. То же даёт пункт Подробнее в меню строки; соседний пункт Скопировать запрос кладёт SQL в буфер обмена.

Над таблицей три фильтра:

• Период — диапазон с датой и временем;
• Вид обращения — можно отметить несколько сразу;
• Только ошибки — переключатель для разбора неудачных обращений.

Когда фильтры заданы, рядом появляется Сбросить все.

Федеративного запроса в фильтре нет

Такое обращение принадлежит нескольким источникам сразу и в журнал отдельного источника не попадает — фильтр по нему всегда возвращал бы пустой список.

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

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

Записи старше срока хранения удаляются по расписанию; по умолчанию срок — 90 суток. Значение задаётся в настройках установки — их правит тот, кто разворачивал платформу (в интерфейсе этих настроек нет). Если срок важен для ваших регламентов, уточняйте его у администратора платформы.

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

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

• Изменений самого источника. Кто поменял хост, пароль или Initial SQL, журнал не покажет: он фиксирует только обращения к данным.
• Запросов, выполненных в обход платформы. Журнал видит только то, что прошло через неё.
• Личности зрителя публичной ссылки. Видно, что обращение пришло по ссылке (share:<номер>), но не кто её открыл: у анонимного зрителя нет учётной записи — публикация по ссылке.
• Запросов виджетов к извлечённым датасетам. Датасет в режиме извлечения отвечает из витрины платформы, до источника такой запрос не доходит — в журнале появляется только само извлечение (ETL-экстракт). Обращения виджетов видны у датасетов в режиме прямого запроса — материализация.

Что дальше

• Видимость строк (RLS) — правила, которые подставляются в итоговый SQL.
• Кеши и лимиты — сколько живёт кеш выборки: ответ из кеша до источника не доходит и в журнал не попадает.
• Решение проблем — что делать с ошибкой из журнала.