В системах резервного копирования наблюдаемость давно перестала быть вспомогательной функцией – сегодня это неотъемлемая часть эксплуатационной архитектуры. Стабильность СРК определяется не только успешным выполнением задач, но и возможностью быстро отслеживать ключевые метрики, своевременно обнаруживать отклонения и реагировать на инциденты.

В этой статье на примере ПО «Береста» мы разберём, как устроен компонент «Монитор состояния» и какую роль он играет в обеспечении отказоустойчивости инфраструктуры резервного копирования.

Архитектура и место монитора в системе

«Береста» реализует централизованную модель управления. Мастер-сервер выступает основным управляющим узлом, который хранит актуальную конфигурацию, координирует выполнение заданий резервного копирования и восст��новления, а также обеспечивает взаимодействие со всеми внешними компонентами.

На рис. 1 показано логическое взаимодействие компонентов системы.

Рис. 1 – Типовое размещение компонентов
Рис. 1 – Типовое размещение компонентов

 Монитор состояния встроен непосредственно в управляющий контур мастер-сервера и работает как слой наблюдаемости. Он собирает телеметрию со всех ключевых элементов инфраструктуры (рис. 2):

  • аппаратная часть мастер-сервера;

  • сервисы мастер-сервера;

  • агентские узлы;

  • силовые серверы;

  • подсистемы хранения. 

Рис. 2 – Расположение монитора состояния в СРК «Береста РК»
Рис. 2 – Расположение монитора состояния в СРК «Береста РК»

Благодаря такой архитектуре достигается централизованный сбор данных и консолидация состояния распределённой среды.

Как это выглядит в интерфейсе

Основными элементами мониторинга состояния являются:

  • карточки компонентов;

  • цветовая индикация статусов;

  • отображение задержек при передаче данных.

На рис. 3 показан пример: монитор фиксирует ошибку подключения сервисов из-за остановки Docker-контейнера и отсутствия связи с БД. 

Рис. 3 – Ошибка подключения сервисов в мониторе состояния
Рис. 3 – Ошибка подключения сервисов в мониторе состояния

Управление компонентами монитора

Интерфейс позволяет гибко настраивать отображаемые элементы.

Добавление компонента:

1.    Нажать кнопку «Добавить» и выбрать шаблон системного элемента (рис. 4).

Рис. 4 – Выбор шаблона системного элемента
Рис. 4 – Выбор шаблона системного элемента

2.    Задать предустановки для виджета (рис. 5).

Рис. 5 – Шаблон предустановки виджета
Рис. 5 – Шаблон предустановки виджета

3.    Подтвердить добавление – новый компонент появится на панели мониторинга.

Редактирование и сброс:

Чтобы изменить расположение карточек, нужно перевести тумблер «Изменение» в активное положение (рис. 6). После сохранения изменений можно вернуть исходный вид через меню шестерёнки – пункт «Восстановить по умолчанию».

Рис. 6 – Редактирование компонентов монитора состояния
Рис. 6 – Редактирование компонентов монитора состояния

Эксплуатационные возможности

Отметим, что в продуктивной среде монитор состояния решает несколько ключевых задач:

  • снижает MTTR за счёт раннего обнаружения сбоев;

  • делает инфраструктуру прозрачной и контролируемой;

  •  повышает SLA;

  •  снижает нагрузку на администраторов благодаря автоматическому контролю.

Критически важным фактором эффективности остаётся корректная настройка правил и интервалов мониторинга – именно она определяет, насколько быстро система сможет отреагировать на отклонения.

Что именно контролирует монитор

Мониторинг охватывает все ключевые элементы:

  •  сервисы мастер-сервера;

  • агентские службы;

  • силовые серверы;

  • базы данных;

  • сетевые компоненты;

  • соответствие целевым показателям RTO/RPO;

  •  выполнение заданий системы.

Основные отслеживаемые метрики:

  • доступность компонентов;

  • задержки передачи данных (latency) между мастер-сервером и другими компонентами инфраструктуры;

  • CPU / память;

  • сетевые показатели;

  •  ошибки выполнения заданий.

Итог

Монитор состояния в «Бересте» – это не просто дополнительная опция, а фундаментальный элемент эксплуатационной модели. Его архитектура обеспечивает централизованный контроль, своевременное выявление проблем и, в конечном счёте, устойчивость всей инфраструктуры резервного копирования.