@IvanSerachev

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

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

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

Схема:
App (W) -> DB master
Grafana (R) -> DB slave
   \
    (R)
   Prometheus


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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы