Перейти к основному содержанию

Администрирование системы

Около 4 мин

Администрирование системы

🔧 Система уже работает и её надо поддерживать? Мониторинг, резервные копии, обновление версии и восстановление после сбоев — всё здесь.

Руководство по мониторингу, резервному копированию, обновлению и устранению неисправностей StormBPMN Enterprise.

Основные задачи администратора

  • Мониторинг - отслеживание состояния системы и производительности
  • Резервное копирование - регулярное сохранение данных
  • Обновления - установка новых версий и исправлений
  • Устранение неисправностей - диагностика и решение проблем

Мониторинг системы

Метрики Prometheus

StormBPMN предоставляет HTTP-endpoint с метриками в формате Micrometer для мониторинга через Prometheus.

Конфигурация Prometheus:

- job_name: "stormbpmn-node-1"
  metrics_path: "/actuator/prometheus"
  scrape_interval: 15s
  static_configs:
      - targets: ["10.1.0.3:8080"]

Готовый дашборд Grafana

Используйте Spring Boot Statistics Dashboardopen in new window для визуализации метрик.

Настройка алертов

Рекомендуемые пороги для срабатывания алертов:

МетрикаУсловие срабатыванияОписание
CPU Usage> 90% в течение 5 минутВысокая загрузка процессора
Request Count /api/v1/> 100 запросов в минутуАномально высокая нагрузка
HEAP Memory Used> 90% в течение 5 минутНехватка памяти JVM
No Data> 5 минут без данныхНедоступность сервиса

При срабатывании алертов

Переходите к разделу Disaster Recovery

Health Checks

StormBPMN предоставляет эндпоинты для проверки состояния:

livenessProbe:
    httpGet:
        path: /api/health/liveness
        port: 8080
    initialDelaySeconds: 30
    periodSeconds: 5

readinessProbe:
    httpGet:
        path: /api/health/readiness
        port: 8080
    initialDelaySeconds: 30
    periodSeconds: 5

Резервное копирование

Что необходимо копировать

Диаграммы, описания и пользователи хранятся в PostgreSQL. Лицензионные секреты LICENSE_KEY_V2 и временно используемый или сохранённый для отката LICENSE_KEY находятся вне базы данных: включите их защищённое хранилище в DR-процедуру или предусмотрите отдельное восстановление секретов.

База данных, файлы и секреты

PostgreSQL содержит основные данные. S3-файлы (изображения, документы) также рекомендуется включить в backup-стратегию, а внешние секреты, включая актуальные лицензионные ключи, необходимо сохранять в защищённом хранилище.

Создание резервной копии

Пример команды для PostgreSQL:

pg_dump -h localhost -d storm_db -U storm_user -W -Ft -b > /backup/storm_$(date +%Y%m%d_%H%M%S).tar

Рекомендуемый скрипт автоматизации:

#!/bin/bash
BACKUP_DIR="/backup/stormbpmn"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/storm_backup_$DATE.tar"

# Создание резервной копии
pg_dump -h $DB_HOST -d $DB_NAME -U $DB_USER -W -Ft -b > $BACKUP_FILE

# Проверка успешности
if [ $? -eq 0 ]; then
    echo "Backup successful: $BACKUP_FILE"
    # Отправка уведомления об успехе
else
    echo "Backup failed!"
    # Отправка алерта администратору
fi

# Очистка старых копий (старше 30 дней)
find $BACKUP_DIR -name "storm_backup_*.tar" -mtime +30 -delete

Требования к резервному копированию

Восстановление из резервной копии

Восстановление PostgreSQL

# Остановка приложения
docker stop stormbpmn

# Восстановление базы данных
pg_restore --format=t -c -N -O -h localhost -p 5432 -U storm_user -d storm_db /backup/storm_backup_20231201_120000.tar

# Запуск приложения
docker start stormbpmn

Проверка восстановления

  1. Проверьте подключение к базе данных
  2. Убедитесь в работе health checks
  3. Восстановите лицензионные секреты из защищённого хранилища: LICENSE_KEY_V2 и, пока инсталляция использует v1 или допускает откат на него, LICENSE_KEY
  4. Проверьте выбранный режим лицензии: для v1 подтвердите работу с восстановленным LICENSE_KEY; для v2 сравните полный код активации на /admin-onboarding с кодом, для которого выдан ключ, и при изменении получите перевыпущенный ключ для этой инсталляции
  5. Проверьте лицензию обычным пользователем: выполните вход и откройте лицензированную функцию
  6. Протестируйте основные функции (например, создание диаграммы)
  7. Проверьте логи на наличие ошибок

Обновление версии

Процедура обновления

ШагДействиеОписание
0Сделать бэкап базы данных
1Убедиться, что бэкап базы разворачивается
2Определить текущую версиюdocker images | grep stormbpmn
3Изучить changelogЖурнал изменений
4Выбрать целевую версиюПроверить совместимость
4.1Инвентаризировать все инсталляцииProduction, тестовые контуры, DR и клоны. На каждой снять код активации с /admin-onboarding и заранее запросить LICENSE_KEY_V2 — см. где взять код
4.2Спланировать миграцию лицензийСуществующий LICENSE_KEY работает временно; v2 можно внедрять по инсталляциям
5Создать резервную копиюОбязательно перед любым обновлением
6Сохранить текущий образdocker save stormbpmn:current > backup.tar
7Скачать новую версиюdocker pull stormbpmn....
8Подготовить миграцию на v2Сначала обновить образ с рабочим LICENSE_KEY; затем подставить полученный заранее LICENSE_KEY_V2 по порядку активации
9Обновить тег в текущем контейнереИзменить версию образа
10Перезапустить все экземпляры приложенияdocker-compose up -d
11Проверить health checks и лицензиюПроверить текущий режим и доступ обычного пользователя. При миграции на v2 проверить AI/DES и удалять LICENSE_KEY только после успешной проверки и окончания окна отката

Лента «Что нового»

В on-prem версии лента «Что нового» отображает статичный контент, запечённый в образ при сборке. Внешние ссылки на блог отсутствуют, дата отображается как дата сборки. Обновление ленты происходит автоматически при обновлении версии приложения.

Критические обновления

Версия ≥ 6.6.XXXX — переходный режим лицензирования v1/v2

6.6.XXXX — блокирующий выпуск placeholder. Перед публикацией документации релиза замените его на подтверждённый номер версии; не подставляйте предполагаемый номер.

Существующий LICENSE_KEY временно продолжает работать, поэтому немедленный перевыпуск всех ключей не требуется. V1 устарел и имеет известное ограничение безопасности: мигрируйте production, тестовые контуры, DR и клоны постепенно, получая для каждого отдельный LICENSE_KEY_V2. Непустой v2 имеет исключительный приоритет, и при его ошибке автоматического возврата к v1 нет. После подстановки v2 перезапустите все экземпляры, проверьте лицензию и только затем удалите LICENSE_KEY из рабочей конфигурации этой инсталляции. Подробности — «Активация инсталляции».

Версия < 6.3.231 → новее

Требуется миграция базы данных:

UPDATE databasechangelog
SET filename = CONCAT('/db/changelog/changes/', SUBSTRING(filename, 35));

Версия ≥ 6.6.441

Требуются новые ENV переменные:

ПеременнаяЗначениеОписание
STORM_ALLOWED_ORIGINShttps://your.domainCORS настройки (не используйте *!)
STORM_DISABLE_SIMPLE_AUTHfalseОтключение базовой авторизации
STORM_DISABLE_ENV_IN_UItrueСкрытие ENV в админке
STORM_DISABLE_ANON_SHARINGtrueЗапрет анонимного доступа
STORM_SENTRY_ENABLEfalseОтключение Sentry
STORM_ENABLE_SAAS_FEATURESfalseОтключение SaaS функций
GOTENBERG_URLhttp://gotenberg:3001URL сервиса конвертации

Версия ≥ 6.6.559

Требуется расширение PostgreSQL:

CREATE EXTENSION IF NOT EXISTS pgcrypto;

Расширение pgvector станет обязательным (быстрый поиск + база знаний)

Расширение pgvector становится базовым требованием платформы: на нём работает быстрый универсальный (семантический) поиск по данным — это нужно всем установкам, независимо от наличия AI-модуля (база знаний AI-чата — лишь один из потребителей). В ближайших версиях pgvector станет жёсткой зависимостью: без него миграция не выполнится и бэкенд не запустится. Готовьтесь заранее (можно уже сейчас):

  1. Перейдите на сборку PostgreSQL с pgvector — например, образ pgvector/pgvector:pg17 (тот же PostgreSQL + стандартные contrib-модули + pgvector), либо установите pgvector в свою сборку/DBaaS.
  2. Убедитесь, что в базе приложения доступны нужные расширения. Достаточно прав суперпользователя или роли с правом CREATE EXTENSION:
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS hstore;
CREATE EXTENSION IF NOT EXISTS pg_trgm;   -- для автодополнения, приложение его не создаёт само

Полный список расширений и кодировка БД — в разделе «Требования к PostgreSQL».

Disaster Recovery

При обновлении

Если обновление прошло неудачно:

  1. Сохранить логи контейнера

    docker logs stormbpmn > /tmp/update_error_logs.txt

  2. Восстановить базу данных

    pg_restore --format=t -c -N -O -h localhost -p 5432 -U storm_user -d storm_db /backup/latest_backup.tar

  3. Откатить версию контейнера

    docker load < backup_image.tar
docker-compose up -d

    Для отката лицензии сохраните обе переменные до конца согласованного окна. Непустой LICENSE_KEY_V2 имеет приоритет; чтобы временно вернуться к v1, удалите или очистите v2, восстановите LICENSE_KEY и перезапустите все экземпляры приложения.

  4. Перезапустить контейнеры

    docker-compose restart

  5. Проверить восстановление: дождитесь health checks, проверьте статус лицензии, затем выполните вход и откройте лицензированную функцию под обычной учётной записью.

  6. Обратиться в поддержку с информацией:

    • Исходная версия
    • Целевая версия
    • Логи ошибок
    • Конфигурация системы

При базовой эксплуатации

При проблемах в работе системы:

  1. Сохранить логи

    docker logs stormbpmn > /tmp/error_logs.txt

  2. Перезапустить контейнеры

    docker-compose restart

  3. Проверить состояние

    • Health checks отвечают
    • Метрики в норме
    • Пользователи могут войти

  4. При сохранении проблем - обращение в поддержку

Связанная документация