Российская платформа для мониторинга ИТ-инфраструктуры, аналитический обзор «Астра Мониторинг»
12.11.2026
Современная корпоративная среда представляет собой многослойную систему, где в одном контуре работают кластеры контейнеров, виртуальные машины, сетевое оборудование, базы данных и сотни прикладных сервисов. Диагностика такой среды средствами разрозненных утилит давно уперлась в предел эффективности: инженер переключается между системой метрик, хранилищем журналов, консолью SNMP и трассировщиком приложений, теряя на переключениях время, которое при крупном инциденте определяет масштаб последствий. «Астра Мониторинг» (Astra Monitoring) — разработка «Группы Астра», представленная в 2024 году и включенная в Единый реестр российского ПО, — спроектирована как единый центр мониторинга, закрывающий сбор метрик, логов и трейсов в одной консоли.
С точки зрения функционального охвата речь идет о мониторинге всех компонентов ИТ-инфраструктуры: от физического сервера и коммутатора до пользовательской рабочей станции и бизнес-сервиса. Платформа позиционируется как российское решение в категории observability — не «очередной заменитель Zabbix», а инструмент полноценной наблюдаемости с вендорской поддержкой и предсказуемым лицензированием.
Трехслойная архитектура
В документации платформы архитектура описывается тремя слоями. Клиентская часть (Data Collection Layer) — это объекты мониторинга: физические и виртуальные узлы, контейнеры и устройства, идентифицируемые по FQDN или IP-адресу и автоматически регистрирующиеся в системе. Каждый объект поддерживает несколько интерфейсов сбора: HTTP-эндпоинты с метриками формата Prometheus, UDP-прием SNMP-трапов, аппаратный мониторинг по IPMI.
Центральная часть (Data Processing Layer) принимает поток телеметрии и пропускает его через конвейер обработки: нормализация входящих данных, привязка к объектам мониторинга, применение правил мониторинга, генерация событий и проблем, эскалация оповещений. Пользовательский слой построен на визуализации средствами Grafana с предопределенными дашбордами и аннотациями алертов, а административный интерфейс управляет конфигурацией агентов, просмотром логов и разбором проблем.
Модель данных: состояния, события, проблемы
Интересная деталь — собственная модель данных мониторинга. Диагностические данные сначала попадают в разряд «сырых», затем на их основе генерируются события, классифицируемые как положительные (возвращение к норме, успешные операции) и отрицательные (аномалии, превышения порогов). Проблемы строятся на событиях и эволюционируют вместе с ними, включая полную историю — от момента отклонения состояния объекта до его возвращения в норму.
Такой подход решает хроническую проблему классических систем мониторинга, где алерт «умирает» молча, и его закрытие приходится восстанавливать по логам. Здесь проблема несет на себе всю историю связанных событий, что упрощает и постмортемы, и расчет времени простоя.
Хранилища: разные движки под разные типы данных
Платформа сознательно отказывается от универсального хранилища и распределяет нагрузку по четырем СУБД. Метрики writes во временные ряды VictoriaMetrics, оптимизированные под высокую скорость записи и горизонтальное масштабирование; аналитика по логам возложена на колоночную ClickHouse; системные сущности и конфигурация живут в PostgreSQL с транзакционной целостностью; кэширование и очереди — на Redis с кластерной моделью.
Технологический стек платформы — Go в качестве языка ядра. Поддержка экосистем Prometheus и OpenTelemetry означает, что уже развернутые в инфраструктуре экспортеры подключаются без переписывания: совместимость с открытыми стандартами телеметрии здесь — не маркетинговая формулировка, а прямое следствие выбора стека. Cloud-native архитектура допускает развертывание в Docker Compose и Kubernetes, а Helm-чарты разделены по сценариям: umbrella-чарт разворачивает готовый стенд «всё в одном» с PostgreSQL, ClickHouse, VictoriaMetrics, Redis и Grafana, а продакшен-чарт подключает базы данных извне — VictoriaMetrics при этом переводится из single-режима в кластерный.
Агент: оркестратор на хосте
Агент платформы — не просто сборщик, а оркестратор процессов сбора на узле. Внутри него выделены модульные менеджеры: Metrics Manager для метрик, Logs Manager для журналов, Signals Manager для трапов и уведомлений от сетевых устройств, а также модуль Watcher & Configurator, отвечающий за healthcheck самого агента и удаленное конфигурирование. Поддерживается каскадная прокси-архитектура: контрольные точки сбора распределяются по инфраструктуре, что снимает нагрузку с наблюдаемых хостов и делает распределенный сбор естественным решением для территориально разнесенных площадок и многоуровневых контуров.
Отдельного упоминания заслуживает автоматизация подключения. Агент в фоновом режиме сканирует хост на наличие экспортеров и начинает опрашивать найденные самостоятельно: новое приложение — база данных или веб-сервер — попадает под наблюдение без заявки в отдел мониторинга. Конфигурация агентов и прокси управляется централизованно через Config API с сохранением версионности: удаленно ставятся экспортеры, меняются SNMP-трапы и сборщики логов, при этом история изменений доступна для аудита.
Мониторы и алертинг
Алертинг в платформе реализован не как докупаемый модуль, а как встроенный слой. Мониторы работают поверх всех собираемых сигналов:
- метрики — пороговые и статические правила на языке PromQL поверх временных рядов: загрузка CPU, память, диски, состояние Kubernetes-объектов, SNMP-счетчики;
- логи — срабатывание по шаблонам и по частоте записей в потоке журналов;
- трейсы — мониторинг бизнес-транзакций с RED-метриками (Rate, Errors, Duration) по сквозным маршрутам запросов через микросервисы;
- SNMP-трапы — реакция на поступающие события сетевого оборудования без ожидания очередного цикла опроса;
- аномалии — адаптивные мониторы, которые строят ожидаемый коридор поведения метрики и срабатывают при выходе за него без ручной настройки порогов.
Особняком стоит направление BTM (business transaction monitoring): трейс можно поставить под монитор не на уровне отдельного сервиса, а на уровне бизнес-операции — задержку оформления заказа или ошибку платежного маршрута. Это отличает решение от систем, где трассировки хранятся, но не участвуют в алертинге. В поставку включено несколько десятков преднастроенных мониторов, а новые правила создаются прямо из графика или PromQL-запроса — запрос подставляется автоматически, что сокращает время между обнаружением проблемы и появлением контроля за ней.
Эскалация настраивается цепочкой шагов «кому и через сколько» с разными каналами на каждом уровне: email, Telegram, Mattermost, webhook. Взятие проблемы в работу останавливает эскалацию, дедупликация событий отсекает повторные уведомления, а сбой контактной точки не обрывает цепочку оповещений. Для плановых работ монитор отключается целиком, а не только уведомлениями по нему.
Наблюдаемость вглубь: детализация и синтетика
К трем классическим столпам наблюдаемости платформа добавляет активные проверки. Раздел «Синтетика» собирает пробы доступности по протоколам HTTP, TCP, ICMP, DNS и gRPC, включая контроль сроков действия SSL/TLS-сертификатов: если внешний адрес перестает отвечать, первой узнает система мониторинга, а не служба поддержки пользователей. Результаты проб consolidируются на единой странице с фасетными фильтрами и детальными графиками по каждой проверке.
Комплексный мониторинг охватывает:
- серверное и сетевое оборудование — через агенты и протоколы SNMP и IPMI;
- виртуальные машины и рабочие станции под Linux и Windows;
- контейнерные среды Kubernetes и Docker, включая eBPF-метрики кластера;
- базы данных — PostgreSQL, ClickHouse, MySQL, MongoDB, Redis и другие;
- бизнес-сервисы, приложения и системы на базе «1С»;
- продукты экосистемы «Группы Астра»: Astra Linux, ALD Pro, «Брест», RuPost, RuBackup, Termidesk.
Для собственных продуктов «Группы Астра» действует экспертный мониторинг: метрики, пороговые значения и дашборды поставляются преднастроенными, что снимает типовую проблему внедрения, когда компонент формально подключен, но критичные для него показатели никто не настроил. Инфраструктурная экспертиза вендора здесь конвертируется в готовые шаблоны, а не в описание «как сделать самому».
Безопасность, закрытый контур и эксплуатация
Аутентификация и управление доступом вынесены на Keycloak: поддерживаются OAuth2 и SAML, интеграция с LDAP и Active Directory, ролевая модель разграничения прав. Версия 1.7.0 усилила сценарии изолированной инфраструктуры: платформа и агент для Kubernetes развертываются из единого офлайн-дистрибутива через утилиту platformctl, что позволяет поднять мониторинг в закрытом контуре без обращения к внешним репозиториям и без участия вендора на этапе установки. Для команд, работающих по принципам Infrastructure as Code, конфигурация описывается кодом; CLI-утилиты amctl и platformctl закрывают операционные задачи без веб-интерфейса.
Гибкое развертывание дополняется эволюцией интерфейса: глобальный поиск по всем разделам приложения, история запросов в разделе метрик с сохранением избранного, системный дашборд «Хост» на детальной странице узла. Детализация уровня «граф eBPF-метрик Kubernetes с переходом к странице любой сущности» показывает, что визуализация здесь выстроена как навигационный инструмент расследования, а не только как витрина показателей.
Лицензирование и позиционирование
Лицензирование привязано к количеству объектов мониторинга — физических и виртуальных серверов, хранилищ, маршрутизаторов, коммутаторов, контейнеров и рабочих мест: доступны пакеты на 100, 500, 1000, 2500 и 5000 объектов в срочном или бессрочном варианте. Такая модель делает стоимость внедрения предсказуемой и позволяет масштабировать контур поэтапно, по мере роста парка.
Контекст появления продукта очевиден: импортозамещение средств наблюдаемости на фоне ухода зарубежных вендоров. Платформа противопоставляет себя двум альтернативам одновременно — самостоятельной сборке стека из open-source компонентов, где за работоспособность отвечает собственная команда, а поддержка исчерпывается комьюнити-поддержкой, и «облегченным» импортозамещением, которое переименовывает чужой код. Astra Monitoring развивается как платформа для мониторинга бизнес-сервисов и инфраструктуры с гарантиями вендора, регулярными релизами и открытой документацией. Для организаций, уже эксплуатирующих продукты «Группы Астра», преднастроенный экспертный мониторинг экосистемы становится дополнительным аргументом; для остальных это российская платформа с современным технологическим стеком, которую имеет смысл оценивать на общих основаниях — по охвату объектов, глубине трассировки, гибкости алертинга и стоимости владения.
