Web UI#

Trino предоставляет web-based пользовательский интерфейс (UI) для мониторинга кластера Trino и управления запросами. Web UI доступен на coordinator через HTTP или HTTPS с использованием соответствующего порта, указанного в Config properties координатора. Он может быть настроен с помощью Web UI properties.

Web UI можно полностью отключить с помощью свойства web-ui.enabled.

Authentication#

Web UI требует аутентификации пользователей. Если Trino не настроен на обязательную аутентификацию, можно использовать любое имя пользователя, при этом пароль не требуется и не допускается. Обычно пользователи входят в систему с тем же именем пользователя, которое они используют для выполнения запросов.

Если не установлен system access control, все пользователи могут просматривать и завершать любые запросы. Это можно ограничить с помощью query rules и Системный контроль доступа. Пользователи всегда имеют право просматривать и завершать свои собственные запросы.

Password authentication#

Обычно для защиты сервера Trino и Web UI используется аутентификация на основе пароля, например LDAP или password file. Когда сервер Trino настроен на использование password authenticator, тип аутентификации Web UI автоматически устанавливается в FORM. В этом случае Web UI отображает форму входа, принимающую имя пользователя и пароль.

Fixed user authentication#

Если требуется доступ к Web UI без аутентификации, можно задать фиксированное имя пользователя, которое будет использоваться для всех обращений к Web UI, установив тип аутентификации FIXED и указав имя пользователя с помощью свойства web-ui.user. Если используется system access control, этот пользователь должен иметь права на просмотр (и, возможно, на завершение) запросов.

Другие типы аутентификации#

Web UI также поддерживает следующие типы аутентификации:

Для этих типов аутентификации имя пользователя определяется через Сопоставление пользователей.

Обзор пользовательского интерфейса#

Главная страница содержит список запросов с информацией, такой как уникальный ID запроса, текст запроса, состояние запроса, процент выполнения, имя пользователя и источник, из которого был инициирован запрос. Текущие выполняющиеся запросы отображаются вверху страницы, за ними следуют недавно завершённые или завершившиеся с ошибкой запросы.

Возможные состояния запросов:

  • QUEUED – Запрос принят и ожидает выполнения.

  • PLANNING – Выполняется планирование запроса.

  • STARTING – Запускается выполнение запроса.

  • RUNNING – У запроса есть как минимум одна выполняющаяся задача.

  • BLOCKED – Запрос заблокирован и ожидает ресурсов (buffer space, memory, splits и т.д.).

  • FINISHING – Запрос завершается (например, commit для autocommit-запросов).

  • FINISHED – Запрос выполнен, и все результаты были получены.

  • FAILED – Выполнение запроса завершилось ошибкой.

Состояние BLOCKED является нормальным, но если оно сохраняется длительное время, это требует анализа. Причин может быть много: недостаток памяти или splits, узкие места в disk или network I/O, перекос данных (data skew, когда данные попадают на небольшое число workers), недостаточный уровень параллелизма (доступно мало workers) или ресурсоёмкие этапы запроса после определённой стадии. Также запрос может находиться в состоянии BLOCKED, если клиент не обрабатывает данные достаточно быстро (часто встречается при запросах вида “SELECT *”).

Для получения более подробной информации о запросе просто нажмите на ссылку с ID запроса. Страница деталей запроса содержит summary-раздел, графическое представление различных стадий запроса и список задач (tasks). По каждому ID задачи можно перейти для получения дополнительной информации.

В разделе summary есть кнопка для завершения текущего выполняющегося запроса. Доступны две визуализации: выполнение задач (task execution) и временная шкала (timeline). Полный JSON-документ с информацией и статистикой по запросу доступен по ссылке JSON. Эти визуализации и другие метрики можно использовать для анализа того, где тратится время при выполнении запроса.

Настройка истории запросов#

Следующие параметры конфигурации влияют на то, как собирается история запросов для отображения в Web UI:

  • query.min-expire-age

  • query.max-history

Независимо от хранения запросов и истории запросов в памяти, вы можете использовать event listener для публикации событий запросов, таких как начало или завершение выполнения, во внешнюю систему.