Жизненный цикл компонентов

Система состоит из 3 основных циклов: сбор информации, обработка информации и выполнение действий.

Сбор информации

Цикл сбора информации включает в себя работу оркестратора, репозитория, агентов и баз данных. Оркестратор запускает агентов, которые собирают данные с таргетов. Собранные данные сохраняются в репозитории.

При запуске оркестратора выполняется следующий процесс взаимодействия между ним и агентами системы.

1. Запуск системы и инициализация компонентов:

Оркестратор начинает свою работу первым и рассылает широковещательное уведомление всем известным агентам.
Агенты (уже работающие или новые) регистрируются в оркестраторе, подтверждая свою доступность.

2. Регистрация таргетов и распределение задач:

Каждый агент передает список действий, выполнение, которых он поддерживает. Каждый агент имеет определенный тип таргета, с которым он может взаимодействовать.
Оркестратор формирует матрицу распределения:
Для каждого таргета выбирается один случайный агент, чтобы распределить нагрузку. Чтобы избежать дублирования, мы блокируем "таргет" на время сбора данных агентом.

3. Сбор данных агентом

Агент получает одно из двух заданий - собрать данные для таргета X при помощи учетной записи Y, либо выполнить действие X на таргете Y, при помощи учетной записи Z.

Процесс сбора:

Агент подключается к таргету и собирает данные в том формате, в котором отдает API
Данные конвертируются в нашу модель, которая используется на платформе
Конвертированные данные агент отправляет на платформу

4. Формирование подграфов и проверка уникальности

Объединение связанных объектов:

Система ищет связи между таргетами (например, один IP-адрес привязан к виртуальной машине и DNS-записи). Например, Zabbix адаптер собрал ВМ с IP адресом X и VMWare адаптер собрал ВМ с IP адресом X, значит между таргетами есть связь и их данные должны быть объединены и обрабатываться совместно
Связанные объекты объединяются в подграф (единый логический объект).

Проверка уникальности:

Основываясь на метаданных, присланных агентом, задача репозитория - обеспечить уникальность объектов, собранных с разных таргетов. Агент обеспечивает уникальность объектов в рамках одного таргета.
Конфликты разрешаются по времени последнего обновления.

5. Сохранение данных в БД

Репозиторий принимает данные от агентов и:

ClickHouse: Пишет «сырые» метрики (оптимизировано для временных рядов).
PostgreSQL: Сохраняет топологию (связи между объектами) и метаданные.

6. Завершение цикла:

Таймер оркестратора запускает следующий цикл сбора
Логирование - Статус «успех/ошибка» каждого агента записывается в лог (для анализа проблем).

Завершив этап формирования подграфа и сохранения данных, система переходит к следующему этапу обработки, который включает применение политик, расчет целевой загрузки системы и последующий анализ собранных данных.

Анализ

Это ключевой этап, который оценивает исходную топологию ресурсов и предлагает оптимизированную конфигурацию. После анализа формируются рекомендуемые изменения — действия, которые определяют, куда переместить ресурсы или изменить их емкость. Эти рекомендации сохраняются в базу данных.

Оркестратор принимает список действий (экшенов), полученных из базы данных, и обеспечивает правильное исполнение изменений в нужной последовательности. Он предотвращает конфликты между действиями, направленными на один и тот же объект или агента, обеспечивая последовательное и упорядоченное выполнение операций.

Tapology worker - компонент, ответственный за объединение данных из различных источников (например, VMware и Zabbix). Его задача состоит в создании единого представления ресурса («объединенного объекта»), которое далее предоставляется пользователям через API.

Через интерфейс пользователи получают доступ к обработанным данным и результатам анализа. Данные предоставляются только после обработки в Tapology worker, гарантируя целостность и согласованность информации.

Выполнение действий

1. Получение команды

Команда поступает в оркестратор из одного из двух источников:

API – пользователь нажал кнопку (ручное действие).
Анализа – автоматическая рекомендация (например, на основе собранных данных). В случае, если есть активная политика, связанная с объектом и меняющая режим работы рекомендаций с ручного на автоматический

2. Передача в оркестратор

Оркестратор проверяет, есть ли агент, способный выполнить это действие:

Если агент доступен → передает ему действие и таргет (объект, на котором выполняется операция).
Если агент недоступен → действие откладывается и остается ждать в очереди первого доступного подходящего агента

3. Выполнение действия агентом

Агент:

Получает задачу от оркестратора.
Выполняет её.
Отправляет информацию о ходе выполнения действия, а также о результате действия в репозиторий.

4. Возврат результата

Репозиторий принимает данные от агента и сохраняет их в PostgreSQL.

5. Конец текущего цикла

Если действие было выполнено, то система возвращается в режим ожидания.

Примечания по работе каждого этапа:

Оркестратор: играет ключевую роль в координации процесса. Отсутствие оркестратора делает невозможным функционирование всей системы.
Агент: ответственен непосредственно за выполнение конкретных задач. Однако его потеря легко компенсируется путём повторного запуска другого экземпляра агента. Если агент выходит из строя, оркестратор перераспределяет его таргеты среди функционирующих агентов.
Репозиторий: хранит важные данные и состояние системы. При потере репозитория вся дальнейшая обработка становится невозможной, пока репозиторий не восстановлен.