Сравнение версий

Ключ

  • Эта строка добавлена.
  • Эта строка удалена.
  • Изменено форматирование.


Тип статьиПознавательная
КомпетенцииАдминистратор
Необходимые праваАдминистратор платформы и root на сервере
Версия платформы2.2223
Статус
Статус
colourGreyYellow
titleЧерновикБета
Сложность легко
Полезные ссылкиhttps://www.hangfire.io/
Дополнительные сведенияUbuntu 20.04, включен SEQ


Введение


Под превью (превьюшки, эскизы, thumbnails) подразумеваются небольшие картинки-снимки внутри разделов на портале платформы. С ними  временами могут происходит непонятные вещи. Превью может вовсе не создаться, либо создаться, но виджеты на нём будут с ошибками. Чтобы понять с какой стороны подойти к этой проблеме и была написана эта небольшая статья.


1. Триггеры, вызывающие создание превью.


Существует несколько тригеров, которые приводят к созданию и обновлению превьюшек. Они показаны на схеме ниже.

  1. Сохранение в DD. Нажимаем кнопку "Сохранить" в Дэшборд Дизайнере.
  2. Обновление по расписанию. Существует регулярная задача в контейнере schedule (внутри используется Hangfire для управления запланированными задачами), которая запускается раз в 10 минут.
  3. Постановка флажка в настройках дашбордов (в веб администрировании) - "Создавать превью автоматически". Т.е., если мы её отключим, а затем включим (по умолчанию она включена), то превью создастся. 


2. Где хранятся картинки и настройки.



  • Сами превью хранятся в компоненте mongodb - DashboardScreenshots. Также в этой коллекции хранятся такие параметры как дата последнего обновления и флаг "Создавать превью автоматически".
  • Также в Монге в коллекции GeneralSettings хранится информация о расписании обновлении превьюшек, создании новых и удалении неактуальных.

         

  • Заглушка для случаев неуспешного создания превью хранится внутри компонента экспорт-сервис. Во время неудачной попытки создания превью картинка записывается в соответствующий дашборд в mongodb - DashboardScreenshots.

          


3. Описание работы и имеющиеся логи.



Центральный компонент работы этого механизма - Dashboard-service. Пайплайн следующий:

  1. Dashboard-service говорит компоненту export-service, что надо создать превью. Делает он это через прокси, используя внешний адрес платформы.
  2. Внутри export-service работает puppeteer, который открывает дашборд от системного юзера PreviewMaker, ждет 30 сек, делает скрин и отправляет обратно на Dashboard-service (тоже все через прокси). Если скрин сделать не удалось, то отправляет заглушку.

    Информация

    Есть фича, реализованная для очень длинных по высоте дашбордов с фиксированной шириной (с версии 2.24). Если высота дашборда больше ширины, то ширина умножается на 9/16 и присваивается высоте. Далее pupeteer открывает дашборд с этими размерами и делает скриншот, соотношение которого получается 16:9. Нужно это для заполнения всей области с превью дашборда в разделах на веб портале платформы.

    Пример: дашборд 2000 х 5000. Размер скриншота: 2000 x 1125.


  3. Dashboard-service сохраняет скриншот в Монгу уже напрямую внутри докер подсети без использования прокси.


Случай 1.

Давайте рассмотрим случай, когда мы сохраняем дашборд в ДД или включаем флажок в настройке дашборда. 

После любого из этих действий на адрес "/corelogic/api/command" посылается запрос:

Блок кода
languagejava
themeRDark
{
    DashboardGuid: "...",
    CommandType: "MakeDashboardPreview+Command"
}


Если для "Dashboard service" уровень логирования установить Full, то в событие Seq выглядит следующим образом:


Image RemovedImage Added


Случай 2.

По расписанию задача на обновление превью выполняется каждые 10 мин (это видно и по логам и по записи в Монге). Логика работы следующая: у каждого превью есть дата создания, поэтому выбирается ОДНО самое старое превью и для него одного обновляется картинка.

Примечание

Отсюда вытекает, например, такой кейс: есть 1000 дашбордов уже готовых, и мы за сутки обновляем превьюшки только 144 из них (1 даш за 10 мин, 6 дашей за час). Значит, если где-то данные обновились (и это супер заметно в превьюшке) или роли превью понизили права, то ждать актуальной превьюшки для самого старого из 1000 дашбордов придется около недели.


Выполняются следующие 2 запроса от компонента schedule на dashboard-service, адрес "/corelogic/api/command":

Блок кода
languagejava
themeRDark
{
    CommandType: "RefreshOutdatedDashboardPreviews+Command"
}

Данный запрос (картинка выше) обновляет устаревшие превью.

Блок кода
languagejava
themeRDark
{
    CommandType: "MakeBrandNewDashboardPreviews+Command"
}

А этот запрос (картинка выше) создаёт превью для дашбордов, у которых его еще нет. Это в первую очередь нужно для дашбордов по внешней ссылке, добавленных внутри настроек портала.



Информация

Запросы посылаются на внешний адрес платформы.

4. Известные проблемы.



СимптомПричинаВерсия платформыДействия
Превью не создается, видим серую заглушку или белый снимок или не все виджеты.Ошибки в виджетах препятствую препятствуют созданию превью.2.19 и ранееУстранить ошибки в виджетах на проблемном дашборде.
Аналогично предыдущему.Дашборд грузится слишком долго (более 30 сек).Предположительно любаяОптимизировать дашборд. Проверить загрузку сервера (возможно стоит добавить мощностей). Увеличить 30 сек на данный момент 21.09.2021 нельзя.
Превью создаётся, но у виджетов ошибки или не все/не те данные.У системной роли для превью недостаточно прав.Предположительно любаяПроверить права этой роли на просмотр дашбордов и на доступ к данным на ViQube.
Аналогично предыдущему.Синдром Пьера Ришара из фильма "Невезучие". Создание превью попало на работу загрузчиков для данных на дашборде, поэтому данных на дашборде временно не было.Предположительно любая

Быстрое решение: вызвать создание превью руками: сохранением даш-да в ДД или флажком в веб администрировании в свойствах дашборда.

Как избегать в будущем:

Смириться и ждать реализации реквеста на "доступность данных на дашбордов во время работы загрузчиков".

Реализовывать свою инкрементную загрузку на ViQube API.

В разделе на портале наблюдаем серую заглушку у дашборда.Аналогично предыдущему, но создание превью попало на работу аналитика с Дашбордом. То есть аналитик, работая, временно сломал дашборд путем подкладывания кастомных скриптов в customjs. Далее проблемный скрипт убрал, но ведь дашборд не сохранялся вручную, а следующее регулярное обновление превью может быть нескоро. В итоге ошибка.Предположительно любая

Быстрое решение: вызвать создание превью руками: сохранением даш-да в ДД или флажком в веб администрировании в свойствах дашборда.

Как избегать в будущем:

Обкатывать скрипты и доводить до ума дашборды на дев сервере, а не на проде.


В целом диагностику проблем после исключения всего, что выше, стоит начинать с логов, вот по этим событиям:

  • MakeBrandNewDashboardPreviews;
  • MakeDashboardPreview;
  • RefreshOutdatedDashboradPreviews.

От этих ошибок можно отталкиваться куда копать далее, если они конечно будут.


5. Созданные реквесты на доработку.


На дополнительные логи для диагностики - #43194