Система мониторинга ИТ-инфраструктуры — это программное обеспечение, которое собирает данные о серверах, сети и приложениях, помогает обнаруживать отклонения и оповещает о проблемах. Но наличие мониторинга не означает, что операторы быстро понимают, что произошло и какие сервисы затронуты. Поэтому выбор начинается с задачи: организовать сбор данных, заменить действующую систему или наладить обработку событий из нескольких источников.
Когда в организации используются несколько систем мониторинга, один технический сбой может сопровождаться множеством связанных оповещений. Дежурным приходится сопоставлять их вручную, чтобы оценить масштаб нарушения и перейти к диагностике.
С чего начать выбор системы мониторинга
Для разных задач нужны разные решения, поэтому сначала определяется задача. Если мониторинга нет, составляется перечень объектов и сервисов, которые нужно контролировать, определяется, какие сбои критичны, кто получает оповещения и как должен на них реагировать.
Если мониторинг уже работает, фиксируется, чего именно не хватает. Система может не поддерживать новое оборудование, не справляться с нагрузкой или не соответствовать требованиям организации. Другая ситуация: данные собираются исправно, но операторы работают в нескольких консолях и тратят время на повторяющиеся оповещения. В первом случае рассматривается замена или развитие системы мониторинга, во втором проверяется, можно ли решить проблему на уровне обработки событий, сохранив действующие инструменты.
«Выбирая систему мониторинга, имеет смысл начинать не с функций, а с вопроса, какие решения будет принимать оператор мониторинга на основании её данных. Источники, пороги и интеграции вытекают из этого.»
Обязательные требования: какие продукты вообще можно рассматривать
Прежде чем сравнивать функции, нужно ответить на три вопроса.
1. Обязательно ли для организации российское ПО? Да, если система закупается по 44-ФЗ или 223-ФЗ либо будет работать на значимом объекте критической информационной инфраструктуры (КИИ). Закупки иностранного ПО с 2025 года регулирует постановление Правительства РФ № 1875 от 23.12.2024: запреты установлены для позиций из приложения к нему, поэтому нужный класс ПО проверяется по перечню. Использование иностранного ПО на значимых объектах КИИ ограничивает Указ Президента РФ № 166. Если требование распространяется на закупку или объект, для каждого кандидата проверяется запись в реестре российского ПО: совпадение продукта, версии, редакции, правообладателя и состава модулей с тем, что планируется закупить. Название в рекламных материалах может отличаться от реестрового. Применимость норм и исключений подтверждает юрист или закупочный специалист.
Если эти нормы на организацию не распространяются, тогда критерии выбора определяются, опираясь на политику организации, качество поддержки и риски доступности зарубежных продуктов, а замена действующей системы может не потребоваться.
2. Какие ограничения у площадки? Главное из них — закрытый контур. Если у системы не будет доступа в интернет, нужен продукт, который устанавливается, лицензируется и обновляется без внешних сервисов. Отдельно проверяется совместимость с используемыми операционными системами, СУБД и средствами виртуализации.
3. Что требуют служба безопасности и заказчики? Это может быть разграничение доступа, аудит действий, сертификаты и определённые условия поддержки.
В итоге остаётся короткий список продуктов, которые имеет смысл сравнивать по функциям и критериям ниже.
Классы решений IT-мониторинга
Границы между классами условны: один продукт может решать несколько задач.
| Класс | Назначение | Примеры |
|---|---|---|
| Инфраструктурный мониторинг | Серверы, операционные системы, виртуализация, системы хранения, сеть и базовый уровень приложений; основа наблюдения за инфраструктурой | Российские: wiSLA, «Пульт», Astra Monitoring, Glaber. Зарубежное ПО с открытым кодом: Zabbix |
| Сетевой мониторинг (NMS) | Углублённый контроль устройств, интерфейсов, каналов связи и топологии сети | Российская разработка: wiSLA, EcoNMS. Зарубежная: PRTG |
| Управление журналами | Централизованный сбор, хранение, поиск и анализ логов | Зарубежное ПО с открытым кодом: ELK-стек, Graylog; отечественные решения подбираются по реестру |
| Платформы наблюдаемости (observability) и APM | Исследование работы приложений по метрикам, журналам и распределённым трассировкам: есть готовые платформы и наборы компонентов для самостоятельной сборки | Российские: Astra Monitoring, Sage Observability (Т-Банк). Зарубежные открытые компоненты: Prometheus и Grafana, Loki, Jaeger, OpenTelemetry |
| Платформы анализа событий и AIOps | Принимают события из разных источников, нормализуют и обогащают их, устраняют дубликаты, выявляют связи алгоритмической и/или ML-корреляцией, формируют контекст инцидента для расследования; набор возможностей зависит от платформы | Российская: Artimate. Зарубежные: BigPanda, Moogsoft |
Сначала определяется, на каком уровне находится проблема. Новая система сбора данных не обязательно устранит перегрузку операторов оповещениями, а платформа анализа событий не заменит сбор данных. Если решения ещё нет, построение мониторинга начинается с универсальной системы сбора данных и оповещений. Специализированные классы (сетевой мониторинг, журналы, наблюдаемость) добавляются там, где нужна глубина, а платформа анализа событий — когда сбор налажен, но операторы перегружены оповещениями.
Как сравнивать продукты на своей инфраструктуре
После обязательных требований, при выборе системы мониторинга ИТ-инфраструктуры, оцениваются следующие характеристики.
- Охват. Поддерживаемые устройства, версии ПО, протоколы и способы подключения.
- Производительность. Число объектов, скорость поступления данных, сроки хранения и ресурсы серверов.
- Надёжность. Отказоустойчивость, резервное копирование и восстановление.
- Интеграции. API, webhook, обмен событиями с другими системами и создание заявок.
- Доступ. Роли, разделение данных между подразделениями или заказчиками (мультитенантность).
- Сопровождение. Документация, обновления, сроки реакции поддержки и язык, на котором она ведётся.
- Лицензирование. Условия лицензии и поддержки конкретного продукта: исходный код может быть открытым, а поддержка при этом коммерческой, поэтому сравниваются реальные условия.
- Стоимость владения. Лицензии, инфраструктура, внедрение, обучение и работа инженеров мониторинга.
Если мониторинг уже есть: 3 сценария
Вопрос о замене системы мониторинга чаще всего возникает по одной из причин. Вендор прекращает поддержку продукта или уходит с рынка; вводятся требования к отечественному ПО; инфраструктура выросла, и система не справляется с нагрузкой или с новым оборудованием; за годы накопилось несколько систем, которые дублируют друг друга; данные собираются исправно, но операторы не успевают разбирать поток оповещений. Причины разные, поэтому и решения различаются: в одном случае систему нужно заменить, в другом объединить сбор данных в одной системе, в третьем оставить действующие системы и надстроить над ними анализ событий.
Заменить действующую систему
Замена оправдана, если продукт не соответствует обязательным требованиям или больше не решает техническую задачу и начинается с инвентаризации.
| Объект инвентаризации | Что фиксируется | Зачем нужно |
|---|---|---|
| Контролируемые объекты | Серверы, сетевое оборудование, приложения, способ сбора данных по каждому | Показывает, какие источники нужно подключить в новой системе |
| Шаблоны и триггеры | Список правил, пороги, зависимости между триггерами | Определяет объём переносимых настроек |
| Сценарии оповещений | Получатели, каналы, расписание смен, эскалация | Позволяет сохранить действующий порядок реакции |
| Отчёты и панели | Кто и для чего ими пользуется | Исключает потерю отчётности, которую запрашивает руководство |
| История | Срок хранения, форматы, потребность в ретроспективном анализе | Определяет, нужно ли переносить архив или достаточно сохранить его в прежней системе |
Дальше новая система запускается параллельно с прежней, а за период в несколько недель сопоставляются оповещения: расхождения указывают на пропущенные источники и неверные пороги. Операторов переводят на новую систему поэтапно, сначала по некритичным сервисам, затем по критичным, с возможностью отката. Если новая система не импортирует данные, архив прежней сохраняется в доступном виде на срок, необходимый для анализа и отчётности. Прежняя система отключается последней и только после согласования со службой мониторинга.
Объединить сбор данных в одной системе
Этот вариант подходит, когда несколько инструментов дублируют функции и усложняют сопровождение. Потребуется сопоставить объекты, унифицировать идентификаторы, статусы и правила и перенести необходимые настройки. Специализированные инструменты стоит сохранять, если единая система не обеспечивает нужную глубину контроля.
Сохранить системы и объединить обработку событий
Если источники работают исправно, но общей картины нет, события можно объединить на отдельном уровне.
Artimate получает события из подключённых систем, приводит их к общей модели, выполняет дедупликацию и обогащение, сопоставляет связанные сигналы с помощью правил и алгоритмов/ML и формирует инциденты с доступным оператору контекстом: хронологией, связанными оповещениями и картой связей.
Сбор данных остаётся за исходными системами: Artimate не заменяет систему мониторинга, а дополняет её анализом событий, поэтому при выборе системы мониторинга нужно учитывать возможность интеграции. Готовые коннекторы есть для Zabbix, «Пульт», wiSLA, Astra Monitoring, UDV ITM и Glaber; остальные источники подключаются через универсальный коннектор по Webhook. Актуальный состав указан на странице «Коннекторы». Платформа устанавливается на серверах заказчика, работает в закрытом контуре и внесена в реестр российского ПО.
Сценарии часто идут последовательно: сначала заменяют систему, которая не проходит по требованиям, затем приводят сбор данных к единому виду, и только после этого оценивают, нужен ли отдельный слой анализа событий.
Вопросы вендору системы мониторинга и пилот
Вопросы относятся к вендору системы мониторинга любого класса.
- Подтверждена ли запись в реестре российского ПО и какие модули в неё входят?
- Поддерживается ли эксплуатация в изолированном (закрытом) контуре без исходящих подключений к внешним сервисам и как доставляются обновления и исправления: офлайн-дистрибутив, внутренний репозиторий, сроки выпуска патчей по уязвимостям?
- Какие версии оборудования и протоколов поддерживаются без доработок?
- Какой объём данных проверен на практике и на какой конфигурации серверов?
- Что нужно для импорта шаблонов и истории из текущей системы?
- Как устроена поддержка: часы, каналы, сроки реакции, кто отвечает за обновления?
- Каковы известные ограничения продукта?
- Каковы условия пилота и критерии его успешности?
Для платформы анализа событий дополнительно уточняется:
- Как объясняется объединение оповещений и можно ли править результат вручную?
- Как инцидент передаётся в используемую тикет-систему?
- Какая история событий нужна для обучения и в каком объёме?
Сценарии проверки и критерии успеха согласуются заранее. Для системы мониторинга это охват объектов, своевременное обнаружение проблем, доставка оповещений и трудозатраты на сопровождение. Для платформы анализа событий — сокращение повторных оповещений, корректность их объединения и время, необходимое оператору для разбора инцидента. Уменьшение числа уведомлений само по себе недостаточно: важно не потерять значимые сигналы.
Выбор системы мониторинга начинается с задачи и исходной точки: есть ли работающая система и чего именно ей не хватает. Затем проверяются обязательные требования — запись в реестре российского ПО, закрытый контур, условия заказчиков, — и только после этого сравниваются функции кандидатов в нужном классе. Окончательное решение подтверждает пилот на инфраструктуре заказчика. Иногда нужна замена мониторинга, иногда дополнительный специализированный инструмент, а иногда достаточно объединить события из уже работающих систем.
Если системы мониторинга уже работают, но поток оповещений перегружает смену, проведите пилот Artimate на собственных событиях. Согласуйте заранее критерии: корректность группировки, пропуски значимых сигналов, время до формирования инцидента и удобство анализа.
