Оперативный центр в Monq
Оперативный центр в Monq

Привет, Хабр! 

Последние несколько лет мы активно строили зонтичный мониторинг и здорово в этом преуспели. Теперь у нас новая задача – построить лучший комплексный мониторинг на рынке РФ. С версией 8.0 Monq становится all-in-one мониторингом, который покроет максимум мониторинговых задач в крупных компаниях. Это самый крупный релиз за последнее время. Рассказываем, что теперь может платформа.

(Может показаться, что это тип статьи, при прочтении которых у участников сообщества возникает мысль — «Опять рекламируют свой продукт, никакой пользы». Правда, наша статья отличается двумя особенностями. Во-первых, мы предупреждаем сразу, что, действительно, речь про обзор функционала от вендора, но – обещаем – здесь не будет прилагательных в превосходной форме. Во-вторых, расскажем и о том, чего Monq не умеет).

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

В этой статье расскажем: 

  • об истории продукта;

  • о текущем функционале Monq и решаемых задачах;

  • о модуле зонтичного мониторинга, включая карты здоровья и построение ресурсно-сервисных моделей;

  • о модуле синтетического мониторинга, включая мониторинг пользовательских интерфейсов и веб-сервисов;

  • о том, как реализован мониторинг инфраструктуры в системе;

  • о модуле low и no-code автоматизации;

  • о возможных интеграциях. 

Кратко – как всё было

Вместо лишних слов – просто схема развития продукта c 2015 года и один комментарий: этот путь наглядно отражает развитие от зонтичного мониторинга к all-in-one платформе, которая покроет большинство задач мониторинга и автоматизации в крупных и средних компаниях. 

Таймлайн развития платформы
Таймлайн развития платформы

Важно: all-in-one не означает отказа от зонтика, а дополняет и развивает его. Это значит, что те пользователи, которые хотят интегрировать в Monq свои системы мониторинга, смогут делать это и дальше, а если какого-то функционала не хватает – пользоваться модулями из “коробки” платформы, которых с каждым релизом будет всё больше. 

Какой Monq сегодня?

Monq 8.0 – это платформа all-in-one мониторинга, которую можно гибко настраивать с помощью low no-code автоматизации. Платформа охватывает большинство задач мониторинга и эксплуатации в сложных и разрозненных ИТ-окружениях, помогает управлять состоянием инфраструктуры и бизнес-сервисов и и проактивно реагировать на сбои. Monq предоставляет только важную информацию о состоянии цифрового ландшафта, учитывает влияние состояния элементов ИТ-окружения на стабильность работы бизнеса и помогает быстро увидеть первоисточник проблемы и ускорить расследование инцидентов. 

Прежде всего, система нужна крупным компаниям со сложными окружениями и инфраструктурами – в небольших компаниях такой мониторинг может быть излишним. Именно поэтому добавим, что пока речь идет про мониторинг enterprise-уровня (хотя некоторые функциональные блоки, например, тот же мониторинг Kubernetes, может найти полезным каждый инженер – о нём будет ниже). А вот с выходом Saas-версии платформы в ближайшее время, ростом числа готовых контент-паков и уже вышедшей no-code автоматизацией Monq станет мониторингом и для малого и среднего бизнеса. 

Ремарка для “импортозамещающих” – Monq находится в Реестре Минцифры, сертифицирован ГК «Астра» и может заменить такие западные продукты, как Splunk, Micro Focus, Solar Winds, IBM и др.

А что такое "all-in-one мониторинг"? 

Аll-in-one мониторинг – это подход к управлению в ИТ, который объединяет в себе всевозможные инструменты и решения для мониторинга различных аспектов ИТ-окружения в единой системе. Такие системы обычно предоставляют возможности мониторинга для различных компонентов ИТ-окружения – инфраструктуры, приложений, бизнес-сервисов. Кроме того, они также могут предоставлять инструменты для анализа данных, создания отчётов, оповещений о проблемах и автоматизацию для управления задачами эксплуатации. Преимущества такого подхода включают в себя удобство централизованного управления, уменьшение сложности и издержек на интеграцию различных инструментов, а также повышение эффективности операций мониторинга и управления ИТ-инфраструктурой в целом. 

Monq обладает всеми этими характеристиками. Обзорно доступный из “коробки” функционал представлен на схеме: 

Функциональные модули Monq
Функциональные модули Monq

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

Зонтичный мониторинг

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

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

Оперативный центр в Monq как единое окно мониторинга
Оперативный центр в Monq как единое окно мониторинга

CMDB и ресурсно-сервисная модель (РСМ)

Ресурсно-сервисная модель (РСМ) – это логическая модель ИТ-сервиса, описывающая состав и взаимодействие ресурсов, которые совместно обеспечивают предоставление данного сервиса на согласованном уровне. 

В Monq РСМ имеет графовое представление, а информация о сервисах и их ресурсах (в обоих случаях это конфигурационные единицы) хранится в собственной CMDB. 

Особенность РСМ в Monq – в ориентации на бизнес-сервисы. Такой подход позволяет представить полную структуру услуги или сервиса, с которым сталкивается конечный потребитель (и от доступности которого зависят финансовые показатели компании). Это важное отличие от других подходов, ориентированных на инфраструктурную систему. 

Наполнение CMDB данными и построение РСМ может проходить как в ручном режиме, так и в автоматическом, по данным из различных информационных систем, подключаемых к Monq, – локальных разрозненных CMDB, ITSM-систем, различных систем управления конфигурациями, виртуализацией, контейнеризации др. 

CMDB в платформе организована на ArangoDB и позволяет определить абсолютно любой состав типов конфигурационных единиц. Для каждого типа можно настроить:

  • атрибутивный состав – набор обязательных параметров, который будет у каждой КЕ данного типа;

  • компонентный состав – составляющие части КЕ для расчета показателей здоровья и покрытия мониторингом;

  • параметры расчета здоровья для каждого компонента;

  • слоты обязательных элементов мониторинга (метрик) для каждого компонента для расчета показателя покрытия мониторингом;

  • правила расчета статуса КЕ.

Такой подход позволяет описать произвольную РСМ соответствующую требованиям заказчика.

Ресурсно-сервисная модель в Monq
Ресурсно-сервисная модель в Monq
CMDB в Monq
CMDB в Monq

Режимы обслуживания 

Кроме основной информации о конфигурационных единицах и их атрибутивном составе Monq позволяет собирать и обрабатывать информацию об их особом состоянии – режимах обслуживания. Эта информация может быть получена из внешних систем как из первоисточников, либо режимы обслуживания могут быть запланированы непосредственно в Monq. Информация о режимах обслуживания может быть использована при подготовке отчетов, выполнении автоматических действий, например, отправки оповещений или регистрации инцидентов.

Режимы обслуживания в Monq
Режимы обслуживания в Monq

Покрытие мониторингом КЕ

Если показатель здоровья КЕ дает пользователям представление о ее состоянии, то показатель покрытия мониторингом дает понимание, насколько хорошо ведется наблюдение за конфигурационной единицей. Ведь никто не застрахован от случая, когда здоровье КЕ – 100%, ее статус – “Ок”, но по ней не отслеживается ни один показатель. 

Покрытие мониторингом в платформе рассчитывается как соотношение обязательных для наблюдения на КЕ и непосредственно привязанных к ней метрик. Обязательные для сбора метрики определяются на типе КЕ в качестве “слотов”, а к этим “слотам” привязываются метрики, собранные в Monq из различных источников. Ну а для влияния этих метрик непосредственно на здоровье КЕ по ним создаются сигналы.

Метрики и покрытие мониторингом в Monq 
Метрики и покрытие мониторингом в Monq 

Root Cause и Impact Analysis здоровья КЕ

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

Настройка модели здоровья КЕ
Настройка модели здоровья КЕ

Модель позволяет учитывать при расчете здоровья КЕ как связанные с ней сигналы, так и влияющие конфигурационные единицы. Это важно при организации мониторинга сложных ИТ-сервисов, состояние которых невозможно определить стандартными методами мониторинга, но возможно рассчитать на основе состояния компонентов, из которых состоит данный сервис.

Данная модель позволяет проводить анализ корневых причин деградации здоровья КЕ (Root Cause Analysis) по всему графу влияния, а также рассчитывать влияние КЕ и сигналов на вышестоящую КЕ (Impact Analysis).

Анализ корневых причин деградации здоровья КЕ в Monq
Анализ корневых причин деградации здоровья КЕ в Monq

Ретроспективный анализ здоровья КЕ

Для проведения ретроспективного анализа здоровья конфигурационных единиц в Monq предусмотрена “Тепловая карта Здоровья” или, если говорить простым языком, визуализация изменения статусов КЕ за выбранный промежуток времени. Данное представление позволяет: 

  • понять, в каком наихудшем статусе находилась каждая КЕ в определенный период времени;

  • оценить изменения Здоровья КЕ за выбранный промежуток времени;

  • увидеть наличие либо отсутствие режимов обслуживания в это время у КЕ;

  • перейти к списку сигналов, повлиявших на КЕ, для выявления причины.

Статусы конфигурационных единиц во времени
Статусы конфигурационных единиц во времени

Отчеты 

Платформа позволяет настраивать различные шаблоны и формировать по ним отчеты как в ручном, так и в автоматическом режиме. 

Отчеты о доступности в Monq
Отчеты о доступности в Monq

Например, так выглядит отчет о доступности ИТ-сервиса, состоящей из 33 конфигурационных единиц. В отчете есть также данные о состоянии каждого элемента этого сервиса (КЕ).  

Пример одного из отчетов о доступности
Пример одного из отчетов о доступности

Подробнее о принципах расчета доступности ИТ-сервисов можно узнать из этой статьи.

Синтетическое тестирование в Monq

Кроме метрик, сигналов и логов, платформа позволяет запускать, собирать и обрабатывать результаты автоматизированного (синтетического) тестирования. Оно позволяет имитировать действия реальных пользователей в различных интерфейсах и выявлять возможные проблемы и узкие места в инфраструктуре и приложениях до того, как они начнут массово влиять на конечных пользователей. Сами тесты могут выполняться на стороне заказчика разнообразными средами тестирования, такими как Selenium/Selenide, Vanessa и другие. Среда тестирования выбирается от целей и задач заказчика и никак не зависит от Monq.  

Проекты синтетического тестирования
Проекты синтетического тестирования

Monq в свою очередь принимает в себя отчеты о выполнении тестов в формате Allure (для этого инструмента есть готовый парсер, но внутри платформы можно написать любой другой), визуализирует их в системе и формирует по ним сигналы. Подробнее узнать о синтетическом мониторинге в Monq можно здесь, а кейс одного из клиентов – тут.

Пример визуализации отчета о синтетическом тестировании
Пример визуализации отчета о синтетическом тестировании

Как в Monq реализован мониторинг инфраструктуры?

В Monq можно отправлять данные мониторинга инфраструктуры, при этом платформа пока не собирает данные с конечных устройств самостоятельно. На текущий момент мониторинг инфраструктуры реализован с помощью агента и плагинов, которые собирают данные из первичных систем. Таким образом, с помощью Monq можно мониторить: 

  • сервера;

  • сетевые службы и сервисы;

  • системы резервного копирования и хранения данных;

  • телефония;

  • программное обеспечение;

  • электронная почта;

  • сетевые устройства;

  • рабочие станции.

Собственный безагентский мониторинг инфраструктуры – один из наших дальнейших шагов по развитию платформы (таким образом, инфраструктурный мониторинг Monq  сможет заменить Zabbix уже в этом году). 

Сбор данных в Monq

Сбор данных в Monq организован с помощью потоков. 

Потоки данных в Monq
Потоки данных в Monq

Данные в потоках собираются двумя способами: 

  1. Push-модель. Для отправки данных в поток используется API-ключ, который есть у каждого потока. На стороне подключаемой системы происходит подготовка данных, после чего они отправляются на точку API Monq.

  2. Pull-модель. Для сбора данных используются агенты Monq (собственная разработка), на которых установлены специальные плагины - экстракторы данных, позволяющие забрать информацию из внешних систем, оборудования, программного обеспечения любым доступным способом.

Плагины пишутся на C#, а для определения параметров их запуска используются задания в потоках – Yaml-сценарии. Задания могут запускаться вручную, по расписанию, или исполняться непрерывно.

Схема сбора данных в Monq
Схема сбора данных в Monq

Дальше эти данные обрабатываются с помощью автоматизации. 

Автоматизация в Monq

Автоматизация в платформе позволяет: 

  • автоматизировать сбор данных;

  • автоматизировать обработку собранных данных;

  • автоматически строить РСМ и карты здоровья;

  • запускать скрипты автохилинга;

  • настраивать корреляцию и дедупликацию;

  • работать с нотификациями;

  • запускать эскалацию;

  • настраивать регламентные действия;

  • автоматически закрывать сигналы. 

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

Пример low-code сценария
Пример low-code сценария

Выше приведен пример простого сценария, которые отвечает за небольшую задачу. Например, пришел сырой лог из Prometheus и из него нужно сформировать “удобоваримое” для нас как пользователей JSON-событие с определенным набором полей для того, чтобы с этими полями можно было работать  внутри системы и видеть их на экране работы с первичными событиям. 

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

После того, как произошли некий пре-процессинг и обогащение, событие отправляется дальше внутрь системы по определенному ключу – для этого внутри Monq используется Rabbit. Мы знаем, какой ключ нужно указать для того, чтобы дальше это событие пошло на дальнейшие сценарии. 

Корреляция и дедупликация: защита от «шторма алертов»

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

Low-code сценарий для дедупликации сообщений
Low-code сценарий для дедупликации сообщений

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

За всё это в Monq отвечают как раз сценарии автоматизации, которые позволяют по уникальным меткам и ключам найти объекты, уже существующие в системе, и присоединить нужные объекты друг к другу.

На базе таких сценариев можно строить и сами ресурсно-сервисные модели. Например, не всегда граф состоит из 100 объектов. Зачастую необходимо начать мониторить внешнюю CMDB, в которой сотни тысяч объектов. Ручное создание этих объектов с последующей поддержкой консистентности этих данных просто по умолчанию невозможно. Monq работает с такими объектами следующим образом: система забирает при помощи специально написанных заданий топологию в формате JSON и дальше на базе сценариев просто парсит их и забирает вне зависимости от степени вложенности (это может быть топология, кластеры, хосты VMware до конечных хостов и устройств, вплоть до порта условного коммутатора). Можно автоматически строить между ними связи, когда есть верхнеуровневая сущность и сущности более низкого порядка, и автоматически настраивая связи влияния по модели здоровья. 

Low-code сценарий для автопостроения РСМ
Low-code сценарий для автопостроения РСМ

Контент-паки на примере Kubernetes

Такие сценарии можно сделать и вручную, если хочется сделать какую-то интеграцию с нуля, но мы представляем для типовых решений из коробки уже готовый набор этих сценариев – для Zabbix, Prometheus, Kubernetes. Каталог контент-паков будет обогащаться, а среди ближайших – паки для VMware, Linux, Windows. 

Пример контент-пака для Kubernetes
Пример контент-пака для Kubernetes

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

Как это можно реализовать? На одну из нод кластера устанавливается агент Monq, который просто “сходит” в k8s, заберёт из него информацию по объектам кластера, сформирует JSON и отправит в Monq уже с помощью сценариев, которые, кстати, раскатываются при установке контент-пака автоматически. При запуске сценария в системе будут установлены объекты: 

–  координатор, который будет работать с агентом;

– сценарии построения РСМ. 

Таким образом, топология построится автоматически, и в системе начнут рассчитываться сигналы и метрики, которые поступают с объектов Kubernetes. В целом служба получает инструмент, который позволит за несколько минут перетащить топологию в Monq и начать её не только ее мониторить, но и динамически менять её состояние. Понятно, что Kubernetes – это динамическая среда, где количество объектов или сам тип объектов может меняться. Например, произошел автоскейлинг под, и вместо одного их стало уже уже десять или даже сорок. В Monq это отразится таким образом, что объект был один, а стало нужное количество. Связи будут установлены автоматически, мониторинг этих объектов также будет осуществляться автоматически. 

В сценариях, которые предоставляются через контент-паки уже есть все необходимые настройки и связи. При этом каждый сценарий можно “подтюнить”, – можно добавить различные блоки, парсеры, установить связи и пайплайны. Движок low-code автоматизации хорош тем, что для этого не нужно иметь сложных знаний языков программирования и держать штат разработчиков, которые будут строить скрипты под каждый сценарий. В случае с Monq любой средний инженер мониторинга за неделю может научиться писать сложные сценарии и дальше их поддерживать. 

No-code управление бизнес-процессами эксплуатации

Что делать, когда всё покраснело? Как инженеры мониторинга могут управлять алертингом, эскалацией и другими процессами? Для этого в Monq существует сервис бизнес-процессов – это уже не low-code технологии, а полноценный no-code движок, который позволяет строить пайплайн и конструкции в зависимости от того, какие действия необходимо выполнить в рамках этого бизнес-процесса. 

Пример no-code сценария
Пример no-code сценария

Рассмотрим пример такого бизнес-процесса – случился какой-то сигнал. Для него настраивается некий фильтр с условиями: например, если сигнал содержит такое-то название, влияет или связан с определенными конфигурационными единицами и имеет определенную критичность, то нужно запустить этот бизнес-процесс и выполнить следующие действия, например: 

  • отправить оповещения на почту с определенными переменными (их  можно забирать из первичных данных или вписать текст самостоятельно);

  • параллельно с этим оповестить группу инженеров в Telegram или другой мессенджер;

  • выполнить любой SSH-запрос, если предполагается, что эту ситуацию можно исправить таким образом;

  • завести инцидент в Jira или любой другой внешний сервис таск-трекинга. 

Настройка фильтра сигнала на no-code сценарии
Настройка фильтра сигнала на no-code сценарии

На базе этого можно выстроить матрицу эскалации – перечня действий в случае, если в течение заданного времени инцидент не решен. В этом случае настраивается отложенная проверка на наличие проблемы, эскалируется дальше на вышестоящее руководство или на другую службу. Параллельно можно сигналить ответственным инженерам, чтобы они взяли проблему в работу. Такие сценарии собираются из кубиков действий, которые есть в системе. Эти действия можно как создать самостоятельно, так и скачать из контент-паков. 

Даже если вы используете какую-то внешнюю интеграцию, которая не поставляется из коробки в Monq (это могут быть непопулярные или самописные решения), то сделать любую интеграцию можно также средствами low-code движка. На скрине ниже представлена “начинка” блока Telegram, который представляет из себя ту же самую low-code конструкцию, задачей которого является просто формирование правильного запроса к API Telegram. 

Возможность редактирования no-code сценария на low-code 
Возможность редактирования no-code сценария на low-code 

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

Ролевая модель 

В Monq реализована ролевая модель, которая позволяет управлять доступами к разной информации внутри организации. 

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

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

Ролевая модель в Monq
Ролевая модель в Monq

Вместо завершения

Если вы дочитали до конца, то, кажется, тема мониторинга вам интересна. Обязательно: 

  1. скачайте комьюнити-версию Monq (важная ремарка – установщик для версии Monq 8.0 с no-code автоматизацией будет готов в ближайшие несколько недель, пока для инсталляции доступна предыдущая версия платформы);

  2. приходите на бесплатные вебинары – ближайший состоится уже в эту среду, 27 марта (регистрация – по ссылке);

  3. запишитесь на демо платформы, чтобы узнать, какие задачи Monq может решить в контуре вашей компании, а также обсудить возможности пилотного проекта. 

Комментарии (20)


  1. DarkHost
    23.03.2024 18:03
    +2

    Выглядит интересно, обязательно попробую. А 28Гб RAM - это минимальные требования?


    1. Olenitskaya Автор
      23.03.2024 18:03

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


  1. evoq
    23.03.2024 18:03
    +2

    Лого у вас " вкусно и точка" угнала или вы у них? Один из двух выглядит убого. И даже если они у вас - ваш значок вызывет ощущение плагита из-за разницы в популярности. Схожесть настолько велика, что первой мыслью было, что В и Т является вендором данного софта. В общем кажется крайне желателен ребрендинг, если вы не хотите ассоциироваться с бургерами


    1. Olenitskaya Автор
      23.03.2024 18:03
      +1

      Спасибо за комментарий. Логотип Monq появился в 2020 году. Нам он нравится, и в ближайшей перспективе ребрендинга мы не планируем. “Вкусно и точка”, где, кстати, идет внедрение решения, как и мы, к ситуации относится с юмором.


  1. ZlobniyShurik
    23.03.2024 18:03
    +8

    Я не фанат Zabbix'а и неторопливо подыскиваю возможные альтернативы ему на замену.

    Но требование для community-версии "CPU 8 Cores, RAM 28Gb, HDD 100Gb" отбивает желание даже пробовать. Если это минимальные требования, то сколько же потребуется в оптимальном режиме?

    К тому же, Zabbix - Open Source, а Monq?


    1. Olenitskaya Автор
      23.03.2024 18:03
      +1

      Monq и Zabbix – разные продукты, поэтому напрямую сравнивать их производительность не стоит. В Monq нагрузка возрастает в том числе за счет последующей обработки данных (а не только их  сбора) и дальнейшей автоматизации работы с ними (построение РСМ, сигналы и т.д.). Указанных ресурсов достаточно для минимальной работы системы. Сколько потребуется в оптимальном режиме – зависит от количества и сложности используемых вами сценариев автоматизации. И да, Monq – не open source.


    1. Olenitskaya Автор
      23.03.2024 18:03
      +1

      Хочется еще отметить, что у нас большая микросервисная платформа, с поддержкой сложных ролевых моделей, автоматизацией, шардингом, кластеризацией и т.д., а Zabbix или тем более Prometheus – это утилитарные системы мониторинга. Если бы вы создавали нечто подобное Monq на таких системах, то потребовалось бы ставить для синтетики тот же Gitlab CI или Jenkins, рядом Zabbix для парсинга данных из отчетов и превращения в метрики, рядом Пром с Таносом или Викторией, отдельно средство для On-call и т.д. Monq – это уже готовая платформа. Ее стоит сравнивать с тем же Micro Focus, и тут требования не кажутся на столько большими, там они еще выше.
      Указанных ресурсов достаточно для минимальной работы системы. Для крупных инсталляций с 5000+ хостов, мониторингом логов и приложений, развитой автоматизацией используется порядка 32 CPU, 92 RAM и несколько терабайт HDD. Для более точного сайзинга лучше обратится к нашим специалистам.


  1. reallord
    23.03.2024 18:03
    +4

    И даже цен нет на сайте монк. Нафига статьи если купить нельзя?


    1. Olenitskaya Автор
      23.03.2024 18:03
      +1

      Купить Monq можно) Страница с ценами на обновлении, так как была выпущена новая версия и скоро о принципах лицензирования и о стоимости стартового пакета можно будет узнать там. Но надо понимать, что стоимость проекта будет сильно зависеть от конкретной компании, ее окружения, архитектуры технического решения. Узнать подробнее можно на демо, а запросить цены можно по электронной почте askformonq@monqlab.com


  1. ALexhha
    23.03.2024 18:03

    Требования: CPU 8 Cores, RAM 28Gb, HDD 100Gb

    Ну так то да. Даже prometheus офигел. А что же надо будет для обслуживания хотя бы 1к хостов ?

    Эталонное значение контрольной суммы

    SHA256:166...c15

    звучит как то странно. А что, значение контрольной суммы может быть и не эталонным ?


    1. Olenitskaya Автор
      23.03.2024 18:03

      Все зависит от того, сколько данных (событий, метрик) будет генерировать эти 1к хостов и сколькими сценариями автоматизации они будут обрабатываться. 


    1. Olenitskaya Автор
      23.03.2024 18:03
      +1

      Кстати, скоро у нас выйдет SaaS, и в нем будут доступны функции Monq даже для небольших объемов инфраструктур.

      А эталонное значение контрольной суммы мы держим на сайте по просьбе некоторых клиентов. Это от их ИБ подразделений.


  1. NIKEtoS1989
    23.03.2024 18:03

    Хотите заменить Графану?)


    1. Olenitskaya Автор
      23.03.2024 18:03
      +2

      Нет, Monq – это платформа для мониторинга, сбора и анализа данных, для оркестрации и автоматизации, а не только для визуализации. При этом Grafana может быть использована в конечном решении для клиента при создании кастомных дашбордов из Monq. 


  1. high_panurg
    23.03.2024 18:03

    А есть те, кто использовал Monq в проде и какие отзывы о нём?
    Стоит переходить с prom`a или zabbix`a?


    1. Olenitskaya Автор
      23.03.2024 18:03

      С кейсами внедрения платформы можно ознакомиться, например, тут (Х5 Group) и тут (ДИТ Москвы)


  1. RPLab
    23.03.2024 18:03
    +1

    Зашёл посмотреть цены - страница в разработке. Внедрять в компанию что бы то ни было, не зная итоговые цены - имхо довольно нелогично для любого бизнеса. Время и ресурсы будут потрачены, а после появления условий и цен возможно сие окажется неприемлемым и придётся потречанные время и ресурсы списать в помойку.


    1. Olenitskaya Автор
      23.03.2024 18:03

      Итоговая стоимость проекта складывается из стоимости лицензии, поддержки, услуг по внедрению (если они нужны). Узнать цены на лицензии, стоимость внедрения и поддержки можно на демо или по электронной почте askformonq@monqlab.com


      1. DonAlPAtino
        23.03.2024 18:03

        Это же бизнес по русски. Попросят ИНН, посмотрят на обороты и сделают индивидуальное предложение. :-) Кроме Каспера и 1с у кого сейчас цены в открытом доступе есть?


        1. NuGan
          23.03.2024 18:03

          Так любые вендоры работают, это рынок же такой. Цен открытых нет ни на один Eterprise продукт. Ни на Veaam, ни на IBM, ни на варю, ни на рэдхат и т.д.