Архитектура
В современной IT-инфраструктуре, где изменения происходят постоянно, статичные системы мониторинга быстро устаревают. Ручная настройка мониторинга для каждого нового сервера, сервиса или приложения — это путь к ошибкам, "слепым зонам" и неоправданным трудозатратам. Мы разработали архитектуру, которая решает эту проблему, ставя в центр системы актуальную модель инфраструктуры (CMDB) и автоматизируя все процессы на её основе.
Философия системы
Наша ключевая идея — мониторинг должен следовать за инфраструктурой, а не наоборот. Система должна автоматически знать, что нужно контролировать, как это делать и какие связи существуют между компонентами. Для этого мы используем CMDB (Configuration Management Database) не как пассивное хранилище данных, а как активный центр управления для всей системы мониторинга.
Ключевые компоненты архитектуры

1. CMDB — Сердце системы Основой всей системы является CMDB. В отличие от классических реализаций, наша CMDB — это живая, постоянно обновляемая модель вашей IT-инфраструктуры.
- Хранилище: PostgreSQL, обеспечивающий надежность, транзакционность и возможность сложных запросов к данным.
- Содержимое: В CMDB хранятся Конфигурационные Единицы (КЕ) — серверы, базы данных, приложения и т.д. Каждая КЕ имеет типизированные атрибуты (например, IP-адрес, версия ПО, владелец) и, что крайне важно, связи между собой (например, "приложение А использует базу данных Б").
2. Автоматическое наполнение CMDB: Фетчеры и Парсеры Чтобы CMDB всегда была актуальной, мы используем автоматизированный конвейер сбора данных:
- Фетчеры (Fetchers): подключаются к различным источникам (облачные API, гипервизоры, Kubernetes, сетевое оборудование) и забирают сырые конфигурационные данные.
- Парсеры (Parsers): принимают сырые данные от фетчеров, разбирают их, приводят к единой модели и записывают в CMDB в виде КЕ, атрибутов и связей.
3. Подсистема сбора метрик: Prometheus + VictoriaMetrics Для сбора и анализа метрик мы используем проверенный и мощный стек:
- Prometheus: Собирает метрики с объектов контроля в режиме реального времени. Он отвечает за оперативный мониторинг, алертинг и краткосрочное хранение данных.
- VictoriaMetrics: Выступает в роли долговременного хранилища метрик (Long-Term Storage). Prometheus записывает в неё все собранные данные, что позволяет нам строить аналитику, отчеты и дашборды за длительные периоды.
4. Асинхронная шина данных: RabbitMQ Все ключевые компоненты системы являются независимыми микросервисами. Для их взаимодействия мы используем брокер сообщений RabbitMQ. Это обеспечивает:
- Отказоустойчивость: Если один из сервисов временно недоступен, сообщение для него не потеряется, а будет ждать в очереди.
- Масштабируемость: Мы можем легко добавлять новые экземпляры сервисов-обработчиков для увеличения производительности.
- Слабую связанность (Decoupling): Сервисы не знают о существовании друг друга напрямую, они просто обмениваются сообщениями через шину.
5. Единый интерфейс: Web UI (React) + REST API Доступ ко всем функциям системы осуществляется через современный веб-интерфейс, написанный на React. Он взаимодействует с бэкенд-сервисами через единый шлюз REST API, который обеспечивает унифицированный и безопасный доступ к данным CMDB, метрикам и другим функциям.
6. Система уведомлений Отдельный сервис, который подписан на события в RabbitMQ. Как только в системе происходит важное событие (например, Prometheus зафиксировал проблему или в CMDB была добавлена критичная КЕ), он формирует уведомление и отправляет его пользователю по настроенным каналам (Email, Telegram, Webhook).