Мониторинг здоровья системы

Сервис basyx-monitor контролирует состояние всех микросервисов платформы Стрикс. Он периодически проверяет выходные субмодели каждого сервиса и формирует единую картину здоровья системы. Интервал проверки — 30 секунд.

Назначение

В продуктовой среде одновременно работают более 10 сервисов. Monitor обеспечивает централизованный контроль: какие сервисы работают нормально, какие деградировали, а какие остановились. Результаты отображаются на дашборде фронтенда и могут использоваться для внешнего алертинга.

Принцип работы

Monitor не обращается к контейнерам напрямую. Вместо этого он проверяет результаты работы каждого сервиса:

1. Находит выходные субмодели сервисов (OEE, AlarmHistory, EnergyConsumption и др.)
2. Читает временную метку последнего обновления
3. Сравнивает с ожидаемым интервалом обновления
4. Подсчитывает количество обслуживаемых устройств
5. Записывает результат в субмодель SystemHealth

Monitor                           BaSyx
  │                                │
  │── GET OEE submodels ──────────→│
  │←── lastUpdate, devicesCount ───│
  │                                │
  │── GET AlarmHistory submodels ─→│
  │←── lastUpdate, devicesCount ───│
  │                                │
  │── PUT SystemHealth ───────────→│
  │                                │

Определение статуса

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

Статус	Условие	Описание
ok	lastUpdate < 3 × interval	Сервис работает нормально
degraded	3 × interval ≤ lastUpdate < 5 × interval	Сервис замедлился или пропускает циклы
error	lastUpdate ≥ 5 × interval	Сервис не отвечает, вероятно остановлен
unknown	Субмодель не найдена	Сервис ещё не запускался или не обслуживает устройства

Пример расчёта

Для сервиса OEE с интервалом 60 секунд: если субмодель OEE не обновлялась более 180 секунд (3 × 60) — статус degraded. Если более 300 секунд (5 × 60) — статус error.

Контролируемые сервисы

Сервис	Выходная субмодель	Ожидаемый интервал
OEE	OEE	60 с
Alarms	AlarmHistory	30 с
Energy	EnergyConsumption	60 с
Runtime	Runtime	60 с
MTBF	MTBF	60 с
Data Quality	DataQuality	60 с
Emulator	(MQTT heartbeat)	5 с
Data Bridge	OperationalData	10 с
Telemetry Writer	(ClickHouse heartbeat)	30 с

Выходная субмодель SystemHealth

Сервис создаёт единую субмодель SystemHealth на facility shell проекта:

Свойство	Тип	Описание
OverallStatus	Property (xs:string)	Общий статус: ok / degraded / error
LastCheck	Property (xs:dateTime)	Время последней проверки
Services	SMC	Коллекция состояний сервисов
Services/{name}/Status	Property (xs:string)	Статус: ok / degraded / error / unknown
Services/{name}/LastSeen	Property (xs:dateTime)	Время последнего обновления выходной субмодели
Services/{name}/DevicesCount	Property (xs:int)	Количество обслуживаемых устройств
Services/{name}/ErrorMessage	Property (xs:string)	Сообщение об ошибке (если есть)

Общий статус

OverallStatus определяется по наихудшему статусу среди всех сервисов. Если хотя бы один сервис в состоянии error — общий статус error. Если есть degraded, но нет error — общий статус degraded.

Docker Compose

basyx-monitor:
  build: ./services/monitor
  depends_on: [aas-environment]
  environment:
    - BASYX_URL=http://aas-environment:8081
    - MONITOR_INTERVAL_SEC=30
  restart: unless-stopped

Интеграция с фронтендом

Фронтенд Стрикс отображает данные SystemHealth:

• Статусные чипы в заголовке приложения — цветовая индикация общего состояния
• Панель здоровья — детальный статус каждого сервиса с временем последнего обновления
• Уведомления — при переходе сервиса в статус degraded или error

Масштабирование

При добавлении нового сервиса в платформу:

1. Сервис начинает записывать свою выходную субмодель в BaSyx
2. Monitor автоматически обнаруживает новую субмодель при следующем цикле discover
3. Новый сервис появляется в SystemHealth без изменения кода Monitor

Для регистрации ожидаемого интервала нового сервиса необходимо добавить запись в конфигурацию Monitor (субмодель MonitorConfig на facility shell).