Из плюсов встроенной системы мониторинга отметим, что данные о работе системы формируются непосредственно системой и являются рекомендованными вендором. Среди минусов отметим необходимость корректной работы системы для обеспечения доступности веб-интерфейса и работы модулей оповещения. Если веб-интерфейс не отзывается, мониторинг становится невозможным.
Внешние сервисы
Для мониторинга мы используем:
- Zabbix,
- Grafana,
- Airflow + Python,
- FineOps.
Zabbix «из коробки» поможет мониторить такие параметры платформы для ПО, как утилизация ЦП, использование оперативной памяти и дискового пространства, а также мониторинг URL-точек входа в сервис. Алертинг для событий по email и в Telegram также имеется.
Grafana также может использовать данные БД, собираемые другими агентами мониторинга, для формирования дашбордов и метрик. Позволяет сводить на одном графике разнородные параметры разных систем, что является большим плюсом по мониторингу. Имеет гибкие возможности по настройке оповещений на основе триггеров, в том числе по email и телеграмм.
FineOps - это отличное решение по мониторингу, позволяющее мониторить не только параметры ВМ, где развернут сервис, но и погружаться в онлайн-режиме в мониторинг процессов JVM. Позволяет даже просматривать файлы дампа процессов jstack, что является большим плюсом. Простой в своей настройке и подключению к ПО FineBI 6 версии.
Реализация системы мониторинга и алертинга на основе Airflow с использованием Python позволяет более гибко по сравнению с предыдущими вариантами настраивать правила автоматической обработки данных из систем.
Правильный подходЧто выбрать для мониторинга? Проще – встроенное. Сложнее – внешнее. Правильнее будет совмещение инструментариев встроенного и внешнего мониторинга и алертинга в рамках определённых регламентов.
Часть 3. Объектная модель системы в БДСравнение БД FineBI и Tableau
Так как перед использованием FineBI был опыт использования Tableau, то напрашивается сравнение структур объектных моделей системы в БД для данных систем.
Можно отметить, что ключевым отличием по возможности мониторинга работы Tableau является предельно подробная БД по основным сущностям системы с описаниями для таблиц «из коробки». FineBI предоставляет в пользование существенно менее удобную систему, в которой администратору предлагается разобраться самостоятельно.
По сути, в FineBI присутствует только техническая система хранения информации для работы с ПО, и она не адаптирована под цели полноценного администрирования системы на основе данных БД.
В 2024 году вендор предоставил возможность формирования ряда системных таблиц с информацией о сущностях системы и иерархиях в формате датасетов на основе подключаемых классов java. Решение в целом правильное, но есть некоторые сложности с первоначальной настройкой. Подключается к платформе с помощью FineReport. Из минусов отметим, что данные хранятся во внутреннем формате датасетов, а не таблицах БД. Поэтому для ряда кейсов мониторинга потребуется дополнительная синхронизация их с данными в таблицах БД. Мы подключали его на тест, но решили не использовать на PROD-среде, так как большая часть кейсов была решена нами в рамках данных из FineDB и LogDB.
В FineBI существуют две связанные концептом БД – FineDB и LogDB. При этом это разные БД по своей организации. FineDB – это реляционная БД, в то время как LogDB – это файловая БД, доступная только через драйвер swift. В FineDB, в основном, содержатся параметры, объекты и связи объектов. В LogDB содержатся события изменений, которые разработчик ПО посчитал нужным логировать. Отмечу, что полная история переходов записей может быть получена только при мониторинге каждой записи управляющих структур FineDB. Данной реализации не предусмотрено.
Избыточность структур FineDB подразумевает, что БД ориентирована, в первую очередь, на работу с ПО. Поэтому часть таблиц БД мало информативна и содержит по факту только 2-3 значимых свойства сущности.
В Tableau БД одна. Она более простая по своей организации и содержит выделенные базовые сущности. Правка сущностей на уровне БД способна изменять их свойства.
В случае с FineBI примечательна ситуация, что вендор по общему правилу не рекомендует вносить самостоятельно какие-либо изменения в БД. Но иногда он даёт на это прямые указания, как в случае с внесением изменений в настроечные параметры (таблица fine_conf_entity БД FineDB). То есть корректировка управляющих структур теоретически возможна, но с этим есть сложности.
Описание FineDB
На сайте вендора существует в целом достаточно полное описание БД на английском и китайском языках. При этом готовых кейсов сбора основных сущностей и формирования связей в интернете крайне мало. По некоторым вопросам их вообще нет.
В связи с необходимостью мониторинга внутреннего состояния объектов системы нами была проведена большая работа по приведению в единое целое разрозненной и связанной неявно информации об основных сущностях и отношениях между ними на основании документации по БД FineDB, LogDB, а также собственных изысканий по интеграции с нашими процессами. По части вопросов мы обращались к GlowByte и разработчику ПО.
Подробнее вопросы о структуре БД, особенностях и практических кейсах для FineDB, а также LogDB будут рассмотрены в последующих публикациях позднее.
Системные отчёты для мониторингаОбъединение информации позволило разработать группы системных отчётов, отражающих отдельные аспекты работы системы. Мы активно используем их в своей работе и готовы поделиться наработками. При этом реализация конечного решения всегда остаётся за командой сопровождения. Вариантов организации FineDB уже сейчас как минимум четыре: на основе бесплатных MySQL, Oracle, SQL Server и платного решения на Postgres. Это разные диалекты построения SQL-запросов и формирования процедур.
Уверен, что многие команды администрирования системы также имеют свои кейсы построения системной отчётности по работе системы. При этом, как правило, команды разных компаний не делятся своими наработками по разным соображениям.
Потребности администрирования системы FineBI, как правило, определяются кейсами решения практических задач обслуживания.
Условно их можно разделить на группы:
- Мониторинг доступов УЗ на объекты через всю схему ролей (с целью проверки и планирования).
- Мониторинг использования:
- учётных записей,
- дашбордов,
- датасетов,
- подключений,
- API,
- других объектов системы.
3. Мониторинг нагрузки системы через потребление ресурса:
- пользователями (просмотр, выгрузка данных),
- разработчиками (просмотр, редактирование, экспорты),
- загрузкой данных в датасеты,
- расчётами для датасетов производных данных.
4. Алертинг на критичные сбои в нормальной работе приложения.
Базовые сущностиСписок базовых сущностей системы:
- дашборды;
- компоненты (в версии старше 6.0);
- датасеты, производные от первичных источников данных разных уровней,
- первичные источники данных (таблицы БД, SQL выборки, Excel и CSV Server Dataset);
- подключения к источникам (БД, файловые коннекторы, в т.ч. swift);
- ролевые группировки УЗ:
7. разрешения УЗ на объекты;
8. связи вышеперечисленных объектов между собой, в том числе построение иерархии объектов;
9. расписания обновлений на каталоги и непосредственно датасеты.
Неправильно сказать, что в системе отсутствует информация о сущностях, но часть кейсов требует глубокого погружения в структуру БД FineDB. Я предпочёл бы иметь готовые кейсы построения таблиц данных работы системы “из коробки" вместо самостоятельного построения структур и их потенциальной повторной сборке от одной “мажорной” версии к другой. Так как вендор оставляет на своё усмотрение изменение состава и структуры используемых таблиц, то это приводит к тому, что часть кейсов сборки структур и связей напрямую из FineDB версии 5 не может быть воспроизведена в версии 6.
Потенциально данные преобразования могут произойти и при переходе между “минорными” версиями. Это способно нарушать уже собранные решения при описании модели системы. Таким образом, это потенциально может нарушить отдельные части функционала системной отчётности.
Вопросы построения базовых сущностей для версии 6.0.+ мы рассмотрим подробнее в последующих статьях.
Сложности выделения базовых сущностей и связейСложности при анализе данных FineBI через БД существуют и имеют определённые степени градации от малозначимых до практически нерешаемых.
Вряд ли решаемы в рамках текущей организации FineDB:
- Отсутствие в БД исчерпывающей информации о всех свойствах объектов и их связей. Например, до сих пор нет информации в FineDB об объёме занимаемых датасетов, последней дате обновления кэша данных Direct.
- В БД записываются только завершённые задачи обновления. Успешные или с ошибкой. Старт незавершенного обновления датасета в БД в данной таблице не отражён.
Существовала проблема построения Origin Dataset, так как прямого указания на построение связи датасетов нами найдено в сети не было. В декабре 2024 нам в целом удалось её решить.
Среди существенных сложностей понимания процессов обновления отметим, что сетка актуального расписания обновлений из БД собирается не совсем тривиальным способом через объединения настроек обновлений для каталога и для датасета в нём.
Последовательность шагов для получения расписаний:
- экстракция сущностей,
- построение иерархии датасетов и каталогов,
- привязка расписания на датасеты и их родительские каталоги,
- выделение часов запланированного старта из структур расписания обновлений simple и cron.
Часть 4. Примеры практических кейсов сопровождения системыПланирование потребления ресурса ЦП системы
В случае падения производительности системы FineBI и увеличения отклика Web-интерфейса необходимо выяснить причину.
Самый простой способ понять, что оказывает влияние в моменте, это отключить обновление в Update Task Scheduler по одному. Но не всегда такой вариант возможен. Например, ночью, когда нерабочее время.
При анализе производительности не в момент выполнения, а по прошествии времени потребуется оценка процессов, действующих на системы одновременно. Для этого уже необходим анализ логов БД и, возможно, даже системы.
Поэтому крайне желательно понимать размерность датасетов и сложность вычислений для оценки совместной одновременной нагрузки, оперировать используемым объёмом данных.
Кроме того, необходимо оценивать актуальность дашборда или датасета. Если объект используется нечасто и не имеет высокой степени критичности, то из пула объектов высокой критичности его можно вынести на другое, менее загруженное время.
Как правило, эти рекомендации позволяют решить данный кейс.
Аналитика прав пользователей и групп на сущности дашбордовИногда требуется предоставлять в табличном виде организацию всех доступов к объектам УЗ. Есть варианты использования плагина выгрузки от вендора или формирования данных напрямую из FineDB. При этом потребуется правильная иерархия объектов и корректное отнесение имеющихся разрешений учётных ролей на объекты. В целом задача вполне решаемая и подразумевают кастомный подход с расширением на категории пользователей согласно организационной структуре компании.
Подключение внешнего мониторинга к БД FineDBНесмотря на возможность использования функционала DataAlert в базовом виде и в виде плагина, плюсы дополнительного оповещения ботами по email или в Telegram всё же имеются. В связи с этим на часть состояний БД нами были настроены оповещения, например, о формировании очереди обновлений или о превышении лимитов УЗ на сервере.
Подробнее мы рассмотрим суть данной реализации в последующих публикациях, посвященных системным отчётам.
Коррекция данных структур БДFanRuan (вендор ПО) не рекомендует напрямую корректировать БД FineDB. Тем не менее, часть конфигураций системы находится в таблице fine_conf_entity, и при изменении некоторых из них вендор напрямую указывает на необходимость добавления или изменения в данной таблице.
Коварство данной таблицы в том, что там не только изменяемые параметры, но и кэшированные данные. В FineBI 5 версии в ней кэшировалось больше данных, чем в 6 версии. Изменение кэшированных данных в данной таблице не вносит изменения в конфигурацию. Они повторно кэшируются. Это источник, в первую очередь, для чтения данных.
Внутри БД возможно создание других таблиц со вспомогательным функционалом (списки, правила и так далее). Важно при этом разделять пространство самой системы и доработок функционала либо префиксами таблиц, либо выносить на другие схемы БД.
Стоит отметить, что коррекция БД напрямую не оставляет сведений о действиях в LogDB. Данный факт всегда стоит учитывать.
Что можно корректировать? Например, заполнение таблицы пользователей fine_user согласно правилам, принятым в компании. По факту, это табличное редактирование карточки, идентичное отображаемому в веб-форме.
Добавление версионности таблицТак как FineDB содержат данные преимущественно о состоянии системы, то отслеживание изменений в таблицах на основе триггеров является хорошим решением. Для этого используется версионная таблица, идентичная наблюдаемой. В неё заносятся при событиях after insert, delete, update данные об изменениях: событие, УЗ, время. Заполненная таким образом таблица позволит восстановить изменения в данных БД, дополнительно дублируя/расширяя возможности мониторинга событий LogDB.
Также возможна обработка ненагруженных таблиц триггерами before insert, delete, update, чтобы не допустить коррекцию данных отдельными УЗ или ввести расширенную обработку.
Данный кейс, вероятно, мы также рассмотрим отдельным постом.
ЭпилогВ данной статье рассмотрели ряд важных вопросов сопровождения системы FineBI на уровне администраторов. Она является первой в цикле статей, посвящённых нашему практическому опыту при использовании системы.
Надеюсь, что материал будет вам полезен и улучшит ваш опыт при работе с этой перспективной системой сквозной аналитики от FanRuan.
Спасибо за помощь в подготовке результатов всех причастных из нашей компании, коллег из GlowByte, а также представителей разработчика данного ПО.
Надеемся, кейс был наглядным и полезным. Больше полезной информации о работе FineBI вы найдете в нашем сообществе
FineBIChat.Теги:
администрирование,
server,
аналитика,
анализ,
анализ данных,
bi,
dashboard,
анализ и проектирование систем,
tableau,
finebiХабы:
Блог компании GlowByte,
Big Data,
Data Engineering,
DevOps,
Системное администрирование