Системные требования PanDev Metrics on-prem
PanDev Metrics on-prem поставляется как самодостаточный стек — backend, workspace и PostgreSQL 16, — который вы запускаете из архива дистрибутива через Docker Compose или встроенный Helm-чарт. По умолчанию всё работает на одном хосте; для крупных установок базу можно вынести на отдельный хост или managed-сервис. На этой странице — параметры железа, поддерживаемые ОС, базовый набор CPU-инструкций и обязательные версии ПО.
Кратко
| Параметр | Значение |
|---|---|
| Топология | По умолчанию один хост (база в комплекте); внешняя/managed-база — опционально |
| Варианты deployment | Docker Compose или Kubernetes 1.28+ |
| Семейство ОС | Linux — x86_64 или arm64 |
| База данных | PostgreSQL 16 (в комплекте); поддерживается и 17 |
| Порт API backend | 8080 |
| Порт workspace UI | 8090 (host-порт Docker Compose; в Helm Service workspace слушает 80 за Ingress) |
| Порт actuator (внутренний) | 9090 |
Железо
Подбирайте конфигурацию по размеру организации — число отслеживаемых инженеров определяет объём событий, размер материализованных представлений и нагрузку запросов.
Что масштабируется, а что нет:
- Backend и workspace остаются лёгкими при любом размере. Backend — нативный образ GraalVM: он держит соединения с БД и оркеструет работу, а тяжёлые вычисления идут в базе, а не в приложении.
- Масштабируется именно PostgreSQL. На нём аналитическая нагрузка — ночной refresh материализованных представлений и запросы дашбордов.
- В повседневной работе CPU редко является узким местом — дашборды читают из заранее посчитанных материализованных представлений. Единственный реальный потребитель — ночной refresh материализованных представлений: почти однопоточный батч, занимающий примерно 10–15 минут для установки на ~70 инженеров на типичном облачном железе и растущий с объёмом данных. Он упирается в скорость одного ядра и диска — не в число ядер (лишние vCPU его не ускоряют), поэтому предпочтительнее несколько быстрых ядер на SSD/NVMe, чем много медленных. В ночное окно укладывается с запасом; для крупных установок его укорачивает быстрый диск.
- Реальные рычаги размера — RAM (чтобы рабочий набор — свежие события, все материализованные представления и их индексы — помещался в память) и диск, потому что сырые события хранятся бессрочно.
Профили конфигурации
| Профиль | Приложение (server + workspace) | PostgreSQL (CPU / RAM) | Диск PostgreSQL |
|---|---|---|---|
| XS — до ~10 инженеров (пилот / малая команда) | 2 ядра / 4 GB | 2 ядра / 8 GB | 50 GB SSD |
| Small — до ~50 инженеров | 2 ядра / 4 GB | 6 ядер / 16 GB | 100 GB SSD |
| Medium — ~50–200 инженеров | 4 ядра / 8 GB | 8 ядер / 32 GB | 100–250 GB SSD |
| Large — 200+ инженеров | 4 ядра / 8 GB | 16 ядер / 64 GB | 500 GB+ NVMe |
Встроенный Helm-чарт и Compose-стек поставляются настроенными на профиль Small — он подходит большинству установок. Для очень крупных развёртываний (500+ инженеров или несколько лет истории) держите PostgreSQL на 16 ядрах / 64 GB на выделенном или managed-хосте.
Это значения для комфортной, отзывчивой работы — не минимумы. Скорость дают RAM и SSD/NVMe, а не число ядер: дайте PostgreSQL быстрый диск и достаточно памяти, чтобы рабочий набор кэшировался.
Один хост или раздельно
На одном хосте — схема Docker Compose по умолчанию — суммируйте две колонки компонентов. Установка Small на одном хосте поэтому требует примерно 8 ядер / 20 GB; XS-пилот комфортно умещается в ~4 ядра / 12 GB. Начиная с Medium выносите PostgreSQL на отдельный хост или managed-инстанс, где его можно масштабировать и тюнить независимо от приложения.
Размер диска
Хранилище PostgreSQL растёт с числом инженеров, интеграций и объёмом хранимой истории — сырые события хранятся, политики удаления сегодня нет. Материализованные представления обновляются через REFRESH MATERIALIZED VIEW CONCURRENTLY, которому на время refresh нужно примерно 2× размера крупнейшего представления поверх постоянного объёма — закладывайте запас. Используйте быстрый SSD/NVMe: ночной refresh и крупные агрегации дашбордов чувствительны к I/O.
CPU и архитектура
Backend публикуется как нативный образ GraalVM, скомпилированный заранее под конкретную архитектуру CPU. Поэтому дистрибутив поставляет два варианта образа — выбирайте тот, что подходит вашему хосту:
| Архитектура | Тег образа | Примечания |
|---|---|---|
| x86_64 / amd64 | по умолчанию (например, :<version>) | Требует базовый набор инструкций ниже |
| arm64 | суффикс -arm (например, :<version>-arm) | Нативная arm64-сборка, включая Apple Silicon |
На x86_64 нативный backend требует современный набор инструкций. CPU хоста (и любой слой виртуализации перед ним) должен предоставлять:
CX8, CMOV, FXSR, MMX, SSE, SSE2, SSE3, SSSE3,
SSE4_1, SSE4_2, POPCNT, LZCNT, AVX, AVX2, BMI1, BMI2, FMA
Проверить на кандидате-хосте x86_64:
lscpu | grep -E "avx|avx2|fma|sse4"
Если этих инструкций нет — обычно потому, что их маскирует гипервизор, — нативный backend падает на старте с Illegal instruction. На хостах arm64 используйте теги образов -arm; список x86_64-инструкций выше к ним не применяется.
Настройки виртуализации
Если x86_64-backend не стартует на виртуальной машине, гипервизор скорее всего маскирует нужные нативному образу GraalVM CPU-инструкции. Пробросьте CPU хоста в гостевую систему настройкой для вашей платформы.
| Платформа | Настройка |
|---|---|
| Proxmox VE | cpu: host в конфиге VM |
| VMware ESXi | VM compatibility 7.0+, CPU passthrough |
| VirtualBox | Включите VT-x, Nested VT-x, PAE/NX. Команда: VBoxManage modifyvm "VM" --cpu-profile host |
| Hyper-V | VM generation 2, отключите CPU compatibility mode |
| XCP-ng / XenServer | CPU mode host-passthrough |
| QEMU / KVM | -cpu host или явные флаги +avx2,+fma,+bmi2 |
Операционная система
PanDev Metrics on-prem работает на любом современном Linux-дистрибутиве, в котором есть поддерживаемая версия Docker Engine.
| Дистрибутив | Тестируемые версии |
|---|---|
| Ubuntu Server | 22.04 LTS, 24.04 LTS |
| Debian | 11 (bullseye), 12 (bookworm) |
| RHEL / Rocky / AlmaLinux | 8, 9 |
| SUSE Linux Enterprise Server | 15 SP4+ |
Другие Linux-дистрибутивы, удовлетворяющие требованиям по ядру и Docker, также работают — как на x86_64, так и на arm64. Windows Server не поддерживается.
ПО
| Компонент | Требуется |
|---|---|
| PostgreSQL | 16 (в комплекте); поддерживается и 17 |
| Docker Engine | ≥ 20.10 |
| Docker Compose | ≥ v2.0 (рекомендуется v2.20+) |
| Kubernetes | ≥ 1.28 (путь Helm) |
| Helm | 3.x (путь Helm) |
PostgreSQL 16 входит в дистрибутив, поэтому отдельно его устанавливать не нужно — кроме случая, когда вы выбираете внешнюю базу. Backend совместим и с PostgreSQL 16, и с 17 — используйте 17, если на этой версии работает ваша внешняя или managed-база. Внешний кэш (например, Redis) не входит в дистрибутив и не требуется — backend кеширует сессии и rate-limit во внутренней памяти.
Сеть
Входящие и исходящие требования к сети документированы отдельно в Сеть и порты. Кратко:
- Публичный вход на 8080 (API backend) и 8090 (workspace UI) — или 443 за reverse proxy
- Внутренний вход на 9090 для actuator (health и метрики)
- PostgreSQL на 5432 — публикуется на хост поставляемым Compose-файлом; для не-локальных установок забиндите на localhost или закройте на firewall
- Исходящий HTTPS до сервера лицензирования PanDev, а также подключённых Git-провайдеров и таск-трекеров (egress минимальный и отключить нельзя)
Браузеры
Frontend PanDev Metrics — современный React single-page application. Поддерживаются актуальные версии Chrome, Edge, Firefox и Safari. Целимся в последние две мажорные версии каждого браузера.
Ограничения и edge-кейсы
- Одна организация на инсталляцию. В on-prem multi-tenant разделения нет. Одна установка = одна организация.
- Air-gapped развёртывания не поддерживаются. Для интеграций нужен минимальный исходящий доступ.
- Горизонтальное масштабирование backend не входит в on-prem-дистрибутив. Один backend-инстанс на инсталляцию; путь — вертикальное масштабирование через более мощные хосты.
Связанные материалы
- How-to: Установка PanDev Metrics on-prem
- Reference: Сеть и порты
- Концепция: Архитектура on-prem