Какую архитектуру приложения использовать для мониторинга?

Question

[IvanSerachev]

Хочу написать приложение, которое бы являлось рабочим местом менеджера, в котором он мог бы получить нужную для него информацию по метрикам, посмотреть графики и динамику метрик за разные периоды. Менеджеров в компании около 50.
Мне нужно, что бы это работало без тормозов. Что бы каждый мог зайти и посмотреть статистику продаж и производные от нее параметры.
Как мне это правильно организовать? Нужно ли постоянно делать прямые запросы к БД для расчета каждой метрики или диапазона данных? Или подумать насчет кеширования? Не перегрузят ли пользователи сервер? Какие вычисления стоит делать локально?
Есть достаточно сложные вычисляемые параметры, которые могут прилично нагрузить машину. К сожалению, я не могу предварительно посчитать все вычисляемые параметры и записать в табличку, так как выбираемый период произвольный и не кратен, например, неделе.
Возможно есть литература, которую мне стоит почитать на эту тему? Я пока "зелёный" разработчик.

Comments

[pavelsha]

Хочу написать приложение, которое бы являлось рабочим местом менеджера, в котором он мог бы получить нужную для него информацию по метрикам, посмотреть графики и динамику метрик за разные периоды. Менеджеров в компании около 50.

Рисуете в SVG / PNG статическую картинку и поднимаете во внутренней сети сайт на nginx, который по URL-у типа такого
SuperManDash.FIRMA.local
будет открывать ее на экране менеджера.

Можно также настроить ярлык для запуска браузера в полноэкранном режиме и добавить его запуск в автозагрузку.

Почти идеальная система?

Но я могу предложить еще лучше. Еще быстрее. Уберем зависимость от задержек в локальной сети предприятия.

Берем бесплатный (для некоммерческого использования) IrfanView, копируем картинку локально на все рабочие места менеджеров (доменные политики в помощь) и настраиваем Irfan в полноэкранном режиме в меню автозапуска.

Всё! АРМ менеджера внедрен!
Вся поддержка будет заключаться в ответах на вопросы типа: Иван, а как свернуть картинку, чтобы открыть Солитера и ПорнХаб? / Иван, а как после закрытия Солитера и ПорнХаба вывести на экран показатели?

В качестве DRP рекомендую распечатать диаграммы с показателями на плоттере, вставить в богатую рамку и раздать руководителям департаментов. Менеджерам поменьше будет достаточно цветной распечатки на формате А3, которая заламинирована и прикреплена на пробковую доску.

Answer 1

[d'Ivan]

Предлагаю хранить данные в СУБД временных серий Prometheus и дать менеджерам доступ к админке в Grafana. Кто-нибудь один должен создать панели с графиками, подключая к СУБД источника данных.

Добавлено
Чтобы не тормозить основную СУБД приложения, создать slave replica и подключить Grafana к ней.

Схема:

App (W) -> DB master
Grafana (R) -> DB slave
   \
    (R)
   Prometheus

Добавлено
Забыл, что Prometheus сама забирает метрики с устройств, у которых есть HTTP endpoint торчащие наружу и выдающие данные по строго заданому темпу сэмплирования (скажем, раз в 5 сек). Тогда может и слейв реплика нужна разве что веб-сервисам, которые берут данные с нее.

Comments

[IvanSerachev]

Давать админку менеджерам не вариант, но идея пойти через веб неплохая.

[d'Ivan]

IvanSerachev,
https://grafana.com/docs/grafana/latest/permissions/ ?

[IvanSerachev]

Роман Мирр, звучит хорошо. Спасибо

Answer 2

[pavelsha]

Выбрать и использовать систему BI-отчентности, которая удовлетворит по функциям и бюджету. Вместе с Заказчиком прошерстите рынок систем отчетности. Решение о допустимом бюджете, перечне необходимых "красивостей" и методикам расчета показателей принимать им.

В вопросе пишите, что в компании "50 менеджеров". Многое зависит от того, что у Вас в компании вкладывают в понятие "менеджер". Если это действительно лица, которые принимают управленческие и производственные решения, то у них уже скорее всего есть какая-то система показателей и отчетности, которую могут вести вручную, в Excel, в отчетах Учетных систем.
Свести все эти показатели в более менее стройную систему, а потом заставить пользоваться ей... обычно эта задача оказывается сложнее технической реализации.

Подумайте о промежуточном хранилище НУЖНОЙ информации в необходимом и достаточном объеме. Реализуйте репликацию данных / сбор показателей в нее из продуктивных систем.
Про прямые запросы к продуктивным рабочим базам и рабочим сервисам советую забыть. Иначе "отчеты менеджеров" положат основные производственные процессы, а виноват будет разработчик, который создал систему.
В самом запущенном случае на него будут вешать и "срыв подготовки отчетности для принятия управленческих решений", и "остановку отгрузки / производства / продаж", и "репутационные издержки" как внутри так и снаружи компании.

Хотя если основной продукт Вашей компании - это менеджеры и их красивые отчеты, то туда ей и дорога.

Comments

[IvanSerachev]

BI система одно из решений. Думаем в этом направление, но параллельно есть мысли насчет создания чего то своего, более легковесного, а для меня это будет отличной практикой.

Текущая отчётность строится в куче excel файлов. Частично оптимизируем, объединяя отчеты, систематизируем хранение. Эксель хорош, пока не приходится открывать кучу разных файлов одновременно. Начинается путаница в версиях файлов, их расположении и тд. Единая точка консолидации была бы хорошим решением.

[pavelsha]

IvanSerachev,
Самая большая проблема - это "отчёт ради отчёт' и "запишите мне почасовую динамику показателя" (при этом события, которые приводят к его изменению происходят раз в неделю, а использовать показатель Я буду один раз в квартал на совещании)
А да ещё "не помню какие правила и формулы закладывали в excel, но он считает правильно. А из-за вашего нового отчёта у меня показатели упали".
Надеюсь у вас хватит сил и поддержки со стороны владельца, чтобы преодолеть эти трудности.
И учтите ещё одно: чем больше кастома и вариативности в показателях, тем больше хаоса.

[pavelsha]

IvanSerachev,
Самая большая проблема - это "отчёт ради отчёт' и "запишите мне почасовую динамику показателя" (при этом события, которые приводят к его изменению происходят раз в неделю, а использовать показатель Я буду один раз в квартал на совещании)
А да ещё "не помню какие правила и формулы закладывали в excel, но он считает правильно. А из-за вашего нового отчёта у меня показатели упали".
Надеюсь у вас хватит сил и поддержки со стороны владельца, чтобы преодолеть эти трудности.
И учтите ещё одно: чем больше кастома и вариативности в показателях, тем больше хаоса.

[IvanSerachev]

pavelsha, как не странно, отчёты, в большинстве своем, рабочие. В каких то местах не хватает унификации.

Спасибо за поддержку. Буду думать, может быть действительно BI спасет мир)

[pavelsha]

IvanSerachev,
Нее...
BI - это ящик Пандоры.
Особенно, если он имеет хорошую PR-поддержку и "лоу-код интерфейс для разработки отчётов"

Самое важное - жёстко выдерживать единую методологию отчётности.
Иначе легко можете получить Совет Директоров, на который придут две или три противоборствующие группировки и у каждой будет свой технически правильный отчёт с выгодными только им значениями показателей.

Удачи. Смелости. Хорошей Наглости.
Построение BI-системы хороший кейс для резюме

[IvanSerachev]

pavelsha, спасибо Павел!