Как устроена on-prem PanDev Metrics
Кратко. On-prem PanDev Metrics — стек из трёх компонентов: Spring backend (поставляется как нативный образ GraalVM), React-workspace и PostgreSQL 16. Backend — мозг: всё читается и пишется через него. PostgreSQL — source of truth. Backend кеширует сессии в собственной памяти, поэтому внешний кэш не требуется. На этой странице — как компоненты собираются вместе, как идёт типичный запрос и как модель данных изолирует состояние внутри одной организации.
Стек целиком
On-prem PanDev Metrics — это три обязательных runtime-компонента. По умолчанию все три работают на одном хосте; для крупных установок базу можно вынести на отдельный хост или managed-сервис.
Reverse proxy терминирует TLS и маршрутизирует трафик. Backend — Spring Boot, поставляемый как нативный образ GraalVM, отдаёт REST API на порту 8080 и actuator на порту 9090. Workspace — статический React-бандл, который отдаёт Nginx на порту 8090. PostgreSQL хранит всё, что должно пережить рестарт. Сессии и rate-limit-счётчики backend держит в собственной памяти — в режиме single-node этого достаточно.
Ответственность компонентов
Backend (Spring + Java 17)
Backend — единственный, кто общается с базой. Он несёт всю доменную логику:
- Ingestion. Принимает события IDE-плагинов, синхронизирует Git-провайдеров, синхронизирует таск-трекеры, забирает CI/CD-сигналы
- Расчёты. Считает DORA-метрики, активное IDE-время, переработки, индикаторы продуктивности
- Агрегация. Поддерживает materialized views и роллинг-агрегаты, обновляемые планировщиком
- API. Отдаёт REST-эндпоинты для frontend и IDE-плагинов
- Аутентификация. Валидирует JWT, аутентифицирует через LDAP, если интеграция включена
- Авторизация. Резолвит роли (Owner / Maintainer / Viewer) и department-scoped права
Backend намеренно один деплой. Внутри on-prem-дистрибутива нет деления на микросервисы. Это упрощает эксплуатацию и даёт row-level security (RLS) PostgreSQL роль единой и аудируемой точки enforcement.
Frontend (React + Vite)
Workspace — single-page application на React и Vite. Поставляется как статика, которую отдаёт собственный контейнер Nginx на порту 8090, за reverse proxy. Всё состояние тянется с backend через REST API. Бизнес-логики во workspace нет — вынос вычислений в backend держит security-границу чистой и даёт один UI и для Cloud, и для on-prem.
PostgreSQL 16
PostgreSQL — source of truth. Хранит:
- Сотрудников, департаменты, команды
- Подключённых Git-провайдеров, таск-трекеры, CI/CD-сигналы
- Сырые события от IDE-плагинов и интеграций
- Посчитанные метрики и materialized-агрегаты
- Аудит, системные настройки, license state
PanDev Metrics применяет схему и Flyway-миграции автоматически на старте backend. Row-level security включён на multi-tenant-таблицах — в on-prem политики всегда сводятся к «одной организации», но тот же слой enforcement работает как defense in depth. В дистрибутив входит PostgreSQL 16; для внешней базы также поддерживается PostgreSQL 17.
Кэширование
On-prem-дистрибутив не включает отдельный кэш. В режиме single-node backend сам кеширует сессии и rate-limit-счётчики в памяти — этого хватает для одной организации. Шарирование сессий между горизонтально масштабируемыми backend-инстансами сегодня не входит в поддерживаемую on-prem-топологию.
Как идёт типичный запрос
Репрезентативный read-запрос — например, админ открывает DORA-дашборд — проходит по стеку так:
- Браузер → reverse proxy по HTTPS. Proxy терминирует TLS и пробрасывает на backend на порт 8080.
- Backend парсит JWT и смотрит роли вызывающего. Поиск сессии идёт во внутреннем in-memory-кеше.
- Backend применяет авторизацию — Owner / Maintainer / Viewer ограничивают запрос разрешёнными департаментами.
- Backend запрашивает PostgreSQL через materialized views и индексированные таблицы. RLS-политики ограничивают данные одним тенантом.
- Backend сериализует ответ и возвращает JSON во frontend.
- Frontend рендерит дашборд с полученными числами.
Write-пути — например, IDE-плагин отправляет событие — идут тем же маршрутом, но заканчиваются на ingestion-эндпоинтах backend, которые буферизуют и сохраняют событие в PostgreSQL.
Изоляция внутри одной организации
On-prem PanDev Metrics работает в режиме одна организация на инсталляцию. Cloud-стиль multi-tenant разделения отсутствует. При этом модель данных всё равно несёт колонку tenant_id на каждой релевантной таблице, и RLS-политики применяются. Причина — единообразие: тот же код, что в Cloud, работает в on-prem с тем же enforcement. Одна организация становится одним тенантом, и каждый запрос отскейплен соответственно.
Внутри этого одного тенанта изоляция — логическая:
- Департаменты группируют сотрудников и задают организационную иерархию
- Команды вложены в департаменты
- Роли (Owner, Maintainer, Viewer) ограничивают видимость на уровне организации
- Department-роли (Owner, Maintainer, Viewer, Finance) уточняют доступ внутри департамента
Колонка tenant_id — техническая страховка. Роли и иерархия департаментов — повседневная модель доступа.
Trade-offs
Любой архитектурный выбор — trade-off. Решения on-prem PanDev Metrics явные:
| Решение | Плюс | Минус |
|---|---|---|
| Backend одним деплоем | Просто эксплуатировать, одна точка отладки | Нет service-level изоляции между подсистемами |
| PostgreSQL как source of truth | Зрелая, известная, легко бэкапится через pg_dump | Один database-хост держит всё хранилище |
| In-memory кеш сессий | Меньше движущихся частей в single-node on-prem | После рестарта пользователи логинятся заново |
| RLS даже на single-tenant on-prem | Defense in depth, тот же код, что в Cloud | Мизерный overhead на запрос |
| Вертикальное масштабирование | Предсказуемая стоимость и топология | Горизонтальное масштабирование — задача roadmap |
Эти решения отражают то, что реально работает в продакшене у клиентов PanDev Metrics.
Чего нет в архитектуре on-prem сегодня
Несколько компонентов есть в Cloud и пока отсутствуют в on-prem:
- Multi-tenant-плоскость — multi-organization-воркспейсы только в Cloud
- Google sign-in — только Cloud; on-prem аутентифицируется через LDAP / AD
Это не архитектурные пробелы, а намеренное сужение скоупа. On-prem-стек специально меньше Cloud — клиенты предпочитают меньше движущихся частей.
FAQ
Можно ли держать PostgreSQL на отдельном хосте?
Да. По умолчанию PostgreSQL входит в стек и работает на том же хосте — это самый простой вариант. Поскольку базе полезен независимый sizing по CPU, памяти и диску, для прода её можно вынести на отдельный хост или managed-инстанс: в Docker Compose — направив подключение к базе на внешний инстанс, в Helm — через externalDatabase (postgresql.enabled=false).
Можно ли поднять два backend за load balancer?
On-prem-дистрибутив — single-instance на организацию. Горизонтальное масштабирование сегодня не входит в поддерживаемую топологию. Если упираетесь в вертикальный потолок — пишите в support: такая беседа обычно случается на масштабе сотен инженеров.
Где живут IDE-события до того, как стать метриками?
IDE-плагины делают POST-события на backend. Backend сразу записывает сырые события в PostgreSQL. Агрегационные джобы по расписанию читают эти события, строят materialized views, дашборды читают из view. Сырые события хранятся — retention-политики сегодня нет.
Как PanDev Metrics использует row-level security при одной организации?
PanDev Metrics включает RLS на multi-tenant-таблицах и гоняет тот же механизм политик, что в Cloud. В on-prem ровно один тенант, поэтому политика сводится к «разрешено в пределах этого тенанта». Бонус — идентичные code paths в Cloud и on-prem: та же защита работает, если клиент мигрирует туда или обратно.
Архитектура отличается на Kubernetes?
Нет, компоненты идентичны — тот же backend, workspace и PostgreSQL. Helm-чарт упаковывает ту же конфигурацию в values.yaml вместо .env, а PostgreSQL работает как StatefulSet (или внешняя база). Сеть — Services и Ingress вместо bridge-сети Compose.
Связанные материалы
- How-to: Установка PanDev Metrics on-prem
- Reference: Системные требования
- Reference: Сеть и порты