Эксплуатация и мониторинг

Около 2 мин

Эксплуатация и мониторинг модуля симуляций

Здоровье сервиса

Контейнер storm-des отдаёт стандартную проверку здоровья:

GET http://storm-des:8081/actuator/health   →   {"status":"UP"}

В примере compose-файла из установки на этот адрес уже настроен docker-healthcheck. Рекомендуем дополнительно включить автоматический перезапуск при нездоровье — например, контейнер autohealopen in new window:

    autoheal:
        image: willfarrell/autoheal:latest
        restart: unless-stopped
        environment:
            - AUTOHEAL_CONTAINER_LABEL=autoheal
            - AUTOHEAL_INTERVAL=15
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock

и метку autoheal=true на сервисе storm-des. Это закрывает редкий, но неприятный сценарий: после длительного обрыва связи с базой данных сервис может остаться в нерабочем состоянии, и без перезапуска очередь симуляций стоит.

Метрики Prometheus

Метрики доступны на GET http://storm-des:8081/actuator/prometheus — подключите этот адрес в ваш Prometheus (см. «Мониторинг и резервное копирование»). Ключевые метрики:

Метрика	Что показывает
`des_worker_up`	Нода жива и опрашивает очередь (1/0)
`des_queue_tasks`	Размер очереди по статусам (метка `status`)
`des_queue_oldest_wait_seconds`	Сколько ждёт самая старая задача в очереди
`des_tasks_in_progress`	Сколько симуляций считается прямо сейчас
`des_task_queue_wait_seconds`	Время ожидания задач в очереди (гистограмма)
`des_task_duration_seconds`	Длительность прогонов (гистограмма)
`des_simulations_finished_total`	Завершённые прогоны по результатам
`des_poll_errors_total`	Ошибки опроса очереди — рост означает проблемы с БД
`des_throttler_available_permits`	Свободные слоты параллельных симуляций

На что поставить алерты в первую очередь:

des_worker_up == 0 или отсутствие метрик — сервис не работает;
des_queue_oldest_wait_seconds растёт при живой ноде — очередь не разбирается (все слоты заняты или пул БД неисправен);
рост des_poll_errors_total — проблемы соединения с базой данных.

Защита от «зависших» симуляций

Система защищается от зависаний на двух уровнях; все пороги настраиваются переменными окружения из раздела «Установка».

На стороне storm-des — лимиты одного прогона:

SIMULATION_TIMEOUT_MINUTES (по умолчанию 10) — жёсткий потолок длительности прогона;
защита от бесконечных циклов: если модель долго не продвигается по времени, прогон останавливается с понятной ошибкой.

На стороне основного приложения — «санитар» очереди:

задача, простоявшая в очереди дольше SIMULATION_JANITOR_STALE_QUEUED_MINUTES (30 минут), помечается ошибкой «не была обработана в отведённое время» — значит, ни одна нода её не взяла;
прогон без ответа от ноды дольше SIMULATION_JANITOR_STUCK_RUNNING_MINUTES (20 минут) помечается ошибкой «DES-нода не ответила».

Пользователь в обоих случаях видит ошибку симуляции и может запустить её заново — вручную ничего чистить не нужно.

Файлы отладки

Для разбора инцидентов с техподдержкой сервис умеет сохранять входные данные и журнал проблемных прогонов:

        environment:
            - SIMULATION_DEBUG_ENABLED=true
        volumes:
            - ./debug:/app/debug

По умолчанию сохраняются только проблемные прогоны (ошибки и таймауты). Файлы содержат данные ваших процессов — примонтируйте каталог в защищённое место и очищайте его по своим правилам хранения.

Типовые проблемы

Симптом	Причина	Что делать
Симуляции висят «В очереди», затем падают с «не была обработана в отведённое время»	Контейнер `storm-des` не работает, не видит базу или все слоты заняты	Проверить `docker ps` и `/actuator/health`; заглянуть в логи контейнера; при нездоровье — `docker restart storm-des`
Симуляции падают с «DES-нода не ответила», хотя сервис жив	Расхождение `TZ` между `storm-des` и основным приложением — «санитар» ложно считает прогоны зависшими	Выставить одинаковый `TZ` в обоих контейнерах и перезапустить их
Ошибка при создании или проверке конфигурации симуляции в интерфейсе	Основное приложение не достучалось до `storm-des` по `DES_BASE_URL`	Проверить адрес и сетевую связность из контейнера приложения (шаг 4 установки)
Прогон завершается по таймауту	Слишком большой горизонт моделирования или бесконечный цикл в процессе	Уменьшить горизонт/число экземпляров; проверить логику диаграммы; при необходимости поднять `SIMULATION_TIMEOUT_MINUTES` и память
Контейнер перезапускается с ошибкой памяти	Памяти меньше, чем требует число параллельных прогонов	Увеличить память контейнера и `-Xmx` либо уменьшить `SIMULATION_MAX_CONCURRENT`
Очередь стоит после сбоя базы данных, сервис «Up (unhealthy)»	Пул соединений не восстановился после обрыва	`docker restart storm-des`; чтобы происходило автоматически — настройте autoheal (выше)