Как устроена on-prem PanDev Metrics
Кратко. On-prem PanDev Metrics — стек из трёх обязательных компонентов: Spring backend, React frontend и PostgreSQL 17. Backend — мозг: всё читается и пишется через него. PostgreSQL — source of truth. Redis опционален и нужен только для горизонтального шарирования сессий. На этой странице — как компоненты собираются вместе, как идёт типичный запрос и как модель данных изолирует состояние внутри одной организации.
Стек целиком
On-prem PanDev Metrics — это три обязательных runtime-компонента. На отдельную машину выносится только база; остальные комфортно живут на одном application-хосте.
Reverse proxy терминирует TLS и маршрутизирует трафик. Backend — Spring Boot на Java 17, отдаёт REST API на порту 8080 и actuator на порту 9090. Frontend — статический React-бандл. 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)
Frontend — single-page application на React и Vite. Поставляется как статика, отдаётся через reverse proxy. Всё состояние тянется с backend через REST API. Бизнес-логики во frontend нет — вынос вычислений в backend держит security-границу чистой и даёт один UI и для Cloud, и для on-prem.
PostgreSQL 17
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.
Redis 7 — опционально
Redis в on-prem не обязателен. В режиме single-node backend сам кеширует сессии и rate-limit-счётчики в памяти — этого хватает для одной организации. Redis имеет смысл подключать только если потом захочется горизонтально масштабировать backend и шарить сессии между инстансами; в текущем on-prem-дистрибутиве такая топология не поддерживается.
Как идёт типичный запрос
Репрезентативный read-запрос — например, админ открывает DORA-дашборд — проходит по стеку так:
- Браузер → reverse proxy по HTTPS. Proxy терминирует TLS и пробрасывает на backend на порт 8080.
- Backend парсит JWT и смотрит роли вызывающего. Поиск сессии идёт в внутреннем in-memory-кеше (или в Redis, если он подключён).
- 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 кеш сессий, Redis опционален | Меньше движущихся частей в 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, памяти и диска. Выделение базы позволяет масштабировать профили независимо, проводить обслуживание базы без затрагивания приложения и изолировать I/O-нагрузку. Для маленькой evaluation-инсталляции можно совместить; для прода рекомендуется разнесение.
Можно ли поднять два 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, frontend, PostgreSQL (плюс Redis, если включён). Helm-чарт упаковывает те же env-переменные в values.yaml вместо .env. Сеть — Services и Ingress вместо bridge-сети Compose.
Связанные материалы
- How-to: Установка PanDev Metrics on-prem
- Reference: Системные требования
- Reference: Сеть и порты