В менеджерской среде есть изречение: «Управлять можно только тем, что можно измерить». Рискнем его дополнить — данных сейчас генерируется так много, что одного измерения уже мало: «…а эффективно управлять — лишь когда результаты измерений представлены наглядно». В предыдущих статьях про адаптивное администрирование Sigla Vision мы описывали, как собирать данные об изменении объектов BI-системы. Теперь покажем, как представить эти данные наглядно, и приведем примеры наших дашбордов — мы назвали их «системными», чтобы отличать от пользовательских.
Статья пригодится BI-разработчикам и ИТ-специалистам, которые развивают или сопровождают Sigla Vision и другие BI-системы.
Здесь мы разбираем, как системные дашборды помогают решать задачи администрирования Sigla Vision, и прикладываем код для PostgreSQL, который готовит таблицы-источники датасетов для комплексного дашборда «Состояние системы». В нем можно отслеживать, как меняются во времени количественные показатели по объектам: дашбордам, подключениям, ролям, пользователям, рабочим книгам, элементам корзины и т. д.
Оглавление для навигации между материалами цикла
Системные дашборды как инструмент администрирования
Системные дашборды показывают состояние Sigla Vision в разных срезах и помогают решать задачи администрирования.
Дашборды могут быть основаны:
на текущем состоянии системы (объекты FineDB);
на историчных данных системы (в том числе логи, задачи выполнения, динамика количественных изменений).
Особенности построения системных дашбордов:
1. Дашборды основаны на витринах, которые создаются из таблиц объектной модели Sigla Vision.
2. Одну витрину можно использовать для разных дашбордов.
3. Полная объектная модель, как правило, избыточна для дашбордов. Поэтому число столбцов в витринах сокращают до минимального количества используемых данных.
4. Дашборды должны отвечать на вопросы сопровождения системы понятными количественными и качественными метриками.
Категории данных для задач администрирования
Административных задач много, и они разные. Основная задача администраторов — обеспечить стабильную работу системы. Для этого они разбирают уже возникшие проблемы и сбои, а также следят за тенденциями и аномалиями (скачки нагрузки, всплески ошибок и т. п.), чтобы предупредить сбои заранее.
Среди задач администрирования выделим приоритетные вопросы по работе системы:
1. Происхождение данных для дашбордов через связи между объектами: рабочие книги, дашборды, компоненты дашбордов, датасеты компонентов, родительские датасеты, подключения датасетов.
2. Состояние учетных записей (УЗ): лицензии и активность.
3. Публикации дашбордов и отчетов в «Коллекции».
4. Доступы УЗ через роли к объектам: подключения, дашборды.
5. Подключения к файловым источникам и СУБД.
6. Анализ датасетов по каталогам, типам, внутренней структуре.
7. Данные по обновлениям: логи загрузок датасетов, расписание обновлений датасетов и каталогов.
8. Мониторинг потенциально проблемных объектов (датасетов, дашбордов, расписаний обновления).
9. Аналитика просмотров дашбордов пользователями.
10. Мониторинг пользовательских действий на платформе (создание, изменение, удаление контента).
11. Настройка и состояние рассылок отчетов.
Перечень дашбордов
Мы реализовали довольно много системных дашбордов — в первую очередь для администраторов Sigla Vision:
1. Просмотры отчетов.
2. Роли и УЗ каталогов коллекции.
3. Состояние системы.
4. Объектная модель.
5. Песочница.
6. Коллекция.
7. Пользователи.
8. Сообщения интерфейса.
9. Параметры системы.
10. Действия УЗ в системе.
11. Учет обновлений датасетов.
12. Лог обновления датасетов.
13. Расписания обновлений.
14. Утилизация дискового пространства.
15. Лог выполнения функций БД FineDB.
16. Автоописание объектной модели (скриншот и описание этого дашборда мы приводили в статье про объектную модель).
17. Зависимости объектной модели.
18. Мониторинг версионирования FineDB.
К некоторым системным дашбордам мы открываем доступ и пользователям — с ролями разработчиков и модераторов публикаций. Например:
1. Просмотры отчетов.
2. Роли и УЗ каталогов коллекции.
Так сотрудники, которые развивают и сопровождают дашборды, сами следят за их использованием и видят, у кого есть доступ, не обращаясь за этими данными к администраторам.
Дальше подробнее разберем несколько системных дашбордов — те, что чаще всего используем в повседневной работе.
Пример 1. Дашборд «Просмотры отчетов»
Одна из ключевых задач — понять ценность контента и нагрузку, которую он создает на систему. Дашборд «Просмотры отчетов» отвечает как раз на эти вопросы. Термин «отчеты» здесь обобщает и дашборды, и публикации отчетов FineReport.
Дашборд предназначен для анализа того, как пользователи работают с отчетами во времени: в разрезе точек публикации в «Коллекции» и подразделений пользователя из оргструктуры компании.
Основные сценарии использования
Определение даты последнего доступа пользователей к отчету или группам отчетов, опубликованных в каталогах «Коллекции».
Наблюдение за общей динамикой просмотров отчетов с выделением уникальных пользователей и дашбордов.
Получение детальных выгрузок по использованию отчетов пользователями.
Использование ресурсов системы для отображения дашбордов, опубликованных в каталогах.
Примеры
По подразделениям для каждой УЗ найти просмотры в периоде.
По каталогу в «Коллекции» найти все подразделения, сотрудники которых просматривали отчеты.
Найти все факты просмотров в определенный день.
Оценить тенденцию изменения просмотров, посещаемости и потребляемых ресурсов.
Выявить наиболее используемые отчеты.
Ограничения
В дашборде доступ к данным ограничен механизмом Row-Level Security (RLS). Администраторам системы доступны все данные.
Источник данных ограничен RLS по полю «каталог “Коллекции” верхнего уровня», поэтому для подразделений доля от общего считается только по доступным значениям.
После применения RLS не видны действия УЗ с объектами в «Песочницах» пользователей, так как они не привязаны к каталогам.
Только опубликованные в «Коллекции» дашборды настроены для RLS.
Метрики
CU — количество пользователей (мера cnt_user);
CV — количество просмотров (счетчик таблицы: каждая запись — это факт просмотра);
CD — количество дашбордов (мера cnt_dsb);
CDS — количество дней в периоде с просмотрами (мера cnt_days);
LDA — последняя дата просмотра, дней назад (мера days_ago).
Основное представление показывает помесячную динамику метрик CV, CD и CU с процентным изменением от месяца к месяцу. Оно помогает лучше понять, как пользователи работают с контентом, и мы часто им пользуемся.
Еще мы используем показатель «Report Consume» (RC) — он точнее показывает нагрузку, которую создают пользователи. Показатель отражает, сколько секунд система записывает как время на обработку дашборда и его подготовку к показу. RC за период может совпадать у разных отчетов даже при разных сценариях использования. Быстрый отчет может открывать много пользователей или вызываться часто, а тяжелый — выполняться однократно одним пользователем; для обоих сценариев RC дает сопоставимые значения.
Представление «Универсальный процент» показывает нормированные доли по одной из метрик системы (просмотры, пользователи, потребление времени) на выбранных срезах для анализа — например, по каталогам «Коллекции» верхнего уровня:
С двумя сводными таблицами в представлении «Дашборды и пользователи» можно быстро ответить на вопрос «кто и что смотрит». Слева — организационная структура пользователя, справа — каталоги и дашборды для публикаций в «Коллекции». Выбираем любой элемент — и обе таблицы фильтруются по нему.
Представление с настройкой грануляции периодов наблюдения агрегирует данные помесячно, понедельно и подневно — так проще заметить отклонения метрик от их средних типовых значений.
Матрица просмотров показывает, сколько раз пользователи открывали дашборды по часам внутри суток. Цвет выделяет часы, когда систему активнее всего используют для просмотра контента.
Такая панель мониторинга дает подробный анализ того, как пользователи работают с контентом платформы, в том числе визуальный, — а штатный интерфейс от вендора этого не умеет.
Пример 2. Дашборд «Действия УЗ в системе»
Дашборд предназначен для анализа работы пользователей и разработчиков во времени — с разбивкой по типам операций «View», «Edit», «Export» и детализацией до УЗ пользователей.
Основные сценарии:
1. Понять типовые профили использования системы пользователями.
2. Выявить аномалии от обычного использования системы.
3. Оценить, как пики пользовательской активности влияют на производительность системы.
На скриншоте — количество событий каждого типа за день на логарифмической шкале с сортировкой категорий. Категории с малым числом событий — снизу, с большим — сверху. Так все события видны на одном графике независимо от их абсолютного количества.
Здесь — то же количество событий за день, но по часам. Так точнее видно часы пиковой нагрузки от действий пользователей на систему:
В этой таблице представлен свод количества событий по конкретному типу операции, более детальное представление. Метрики: EV (event) — количество событий, TT (total time) — потребляемое время RC.
А здесь количество событий View и Edit по месяцам за несколько лет. Так видно годовой прирост интенсивности работы с системой: пользователи совершают события View, разработчики — View и Edit.
Увеличим участок из красной рамки для лучшего понимания сравниваемых метрик:
Вывод: дашборд детальнее показывает действия пользователей и разработчиков, поэтому от поиска аномалии в интенсивности использования системы до ее причины проходит меньше времени.
Пример 3. Дашборд «Лог обновления датасетов»
Этот дашборд предназначен для анализа обновлений датасетов — чтобы находить нежелательные процессы.
Основные сценарии:
1. Мониторинг интенсивности загрузок и их статуса по дням и по часам (в течение суток).
2. Анализ ручных запусков разработчиками больших обновлений, которые «ломают» очередь запланированных обновлений.
На скриншоте — все загрузки датасетов в абсолютном и процентном выражении с делением по статусам «SUCCESS» и «WRONG». И дневной прирост абсолютной величины по категориям.
Тепловая карта начала обновлений датасетов по дням и часам. Так изменения в системе можно разбирать визуально. На скриншоте видно, что система наиболее загружена в утренние часы — с 8 до 11 часов.
Сводная таблица: в разделе «Источники» по каталогам и до отдельных датасетов считаются зависимые количественные показатели — число задач обновления, число событий о вызове обновлений, их среднее и максимальное время.
А здесь можно увидеть распределение обновлений: плановые «AUTO», внеплановые ручные «MANUAL» и обновления через обращение к системе по API. Критичны здесь ручные запуски больших и долгих обновлений — их при анализе производительности администраторы отслеживают в первую очередь.
Вывод: дашборд дает детальный анализ логов — насколько интенсивно и качественно обновляются датасеты.
Пример 4. Дашборд «Состояние системы»
Дашборд предназначен для количественного мониторинга метрик во времени на основе данных FineDB, объектной модели и версионных таблиц. Каждая метрика — это способ подсчета определенной сущности: дашбордов, подключений, ролей. Используется id элементов.
Стартовая панель состояния системы с последними значениями каждой метрики:
Последние доступные значения метрик (LAST), если данные за текущий день еще не рассчитаны; абсолютная дельта D7 к значению недельной давности и процентная дельта %7 для D7. Также построен период D30.
Можно выбрать тождественные или близкие по смыслу метрики и сравнить их между собой помесячно:
Значения на конец квартала:
Чтобы оценить, насколько интенсивно меняются метрики, открываем представление «Динамика во времени»: выбираем метрику и получаем полный визуальный анализ ее изменений в одном месте.
По записям в версионных таблицах о событиях insert (CI — count insert), update (CU — count update), delete (CD — count delete) для каждого дня строим накопительный итог (CS — count sum) и результирующее изменение (CC — count change).
Для примера — значения CS для метрики количества дашбордов в «Коллекции»:
Следующее представление показывает для метрики «Дашборды» динамику ее значений CI (зеленый), CU (желтый) и CD (красный). CI говорит об увеличении количества объектов, CD — об уменьшении, CU — о коррекции значений объектов без влияния на количество. Если CU нет, значит, сценария коррекции значений в таблице нет: чаще всего таблица полностью обновляется — все записи удаляются и вставляются заново.
Таблицу с данными формирует сама БД — серией схожих запросов в динамическом SQL-выражении. Правила подсчета метрики — какую таблицу и поле идентификатора взять, какой тип агрегации применить — хранятся в таблице настроек сборки метрик.
Чтобы значение метрики можно было проверить прямо из интерфейса дашборда Sigla Vision, мы собрали несколько детальных и сводных таблиц: когда добавили расчет, на каких таблицах считается метрика, какие параметры у строки расчета.
Вывод: когда в FineDB подключили версионирование и построили объектную модель, появилась историчная отчетность с более полным учетом сущностей системы. Дашборд показывает подневную динамику всех сущностей, перечисленных в его настройках.
Заключение
Мы разобрали, как работать с системными дашбордами при решении задач администрирования BI-системы. Штатная Sigla Vision «из коробки» администрируется только через представления в интерфейсе вендора, а системные дашборды дают более полный мониторинг работы системы.
В репозитории GitHub по ссылке лежит SQL-код (диалект PostgreSQL), который создает нужные объекты системы для дашборда «Состояние системы». Разверните это решение и используйте его в работе без каких-либо ограничений.
Наши дашборды — не единственный и не единственно правильный способ показывать данные для администрирования Sigla Vision. В разных организациях пользователи работают с дашбордами и отчетами по-своему, и задачи администрирования BI-системы у всех свои. Изучайте наши варианты, чтобы сделать свои системные дашборды!