27 марта 2025 года состоялся , посвященный выходу новой версии 1.1 системы «Умный мониторинг», в рамках которого провели живой показ продукта, а также рассказали о новой функциональности и «дорожной карте» развития продукта.
Вебинар получился очень насыщенным, особенный интерес вызвали блоки вопросов и ответов. Поэтому, помимо видеозаписи, прилагаем ответы на вопросы в текстовом виде.
Вопросы и Ответы по системе «Умный мониторинг» версии 1.1
Вопрос: Почему заказчики не хотят графану?
Ответ: Во-первых, это open source. Во-вторых, Grafana, начиная с версии 9, поменяла свою лицензионную политику. И по состоянию «на сегодня» у некоторых наших заказчиков есть ограничения на использование подобного рода продуктов.
---
Вопрос: Входит ли в Реестр программного обеспечения?
Ответ: Да, реестровая запись от 11.04.2022
---
Вопрос: «Умный мониторинг» это как SIEM-система в итоге получается или я ошибаюсь?
Ответ: SIEM-системы, в первую очередь, ориентированы на решение задач информационной безопасности. Мы тоже делаем решение с точки зрения информационной безопасности (САКУРА) и понимаем, что наш «Умный мониторинг» (далее УМ) можно тоже использовать как SIEM-систему.
Тем не менее, УМ позиционируем и ориентируем, в первую очередь, на решение задач ИТ – дать больше метрик мониторинга и возможностей для анализа, не связанных жестко с инфобезом. Наши агенты мониторинга сейчас больше ориентированы на бизнес-показатели и показатели производительности. Сетевой трафик тоже можем собирать, но потребуются более сложные настройки чем у современных SIEM-систем. Т.е. мы решаем вопросы мониторинга ИТ «вообще». Например, а где у нас в kafka самая большая очередь, почему она такая и сколько у нее консьюмеров.
Еще пример: мы хотим посмотреть, сколько у нас пользователей сидит в 1С и почему просаживается производительность СХД при этом, и какие самые длинные запросы на это влияют.
---
Вопрос: Умеет ли «Умный мониторинг» разруливать шторм алертов, если вышла из строя верхнеуровневая КЕ, обеспечивающая функциональность подчиненной КЕ?
Ответ: Пока не умеет. Сейчас алерты настраиваются либо точечно для каждой КЕ с помощью Grafana (там уже как настроят), либо с помощью внутренних алертов. Мы работаем над тем, чтобы снизить эффект «шторма» на оператора УМ.
---
Вопрос: Что нативно «Умный мониторинг» умеет собирать с приложений 1С? Как это анализировать, как пользоваться?
Ответ: Да практически все: из коробки: ЖР, ТЖ, APDEX, а сеансы и лицензии умеем получать через RAS; метрики кластера тоже собираем. Анализ в виде нативных инструментов появятся в УМ версии 1.2. Уже сейчас можно всеми этими собранными артефактами пользоваться в графане.
---
Вопрос: Есть ли в «Умном мониторинге» подсистема CMDB, существует ли автодискаверинг?
Ответ: Есть, существует.
---Ответ: Во-первых, это open source. Во-вторых, Grafana, начиная с версии 9, поменяла свою лицензионную политику. И по состоянию «на сегодня» у некоторых наших заказчиков есть ограничения на использование подобного рода продуктов.
---
Вопрос: Входит ли в Реестр программного обеспечения?
Ответ: Да, реестровая запись от 11.04.2022
---
Вопрос: «Умный мониторинг» это как SIEM-система в итоге получается или я ошибаюсь?
Ответ: SIEM-системы, в первую очередь, ориентированы на решение задач информационной безопасности. Мы тоже делаем решение с точки зрения информационной безопасности (САКУРА) и понимаем, что наш «Умный мониторинг» (далее УМ) можно тоже использовать как SIEM-систему.
Тем не менее, УМ позиционируем и ориентируем, в первую очередь, на решение задач ИТ – дать больше метрик мониторинга и возможностей для анализа, не связанных жестко с инфобезом. Наши агенты мониторинга сейчас больше ориентированы на бизнес-показатели и показатели производительности. Сетевой трафик тоже можем собирать, но потребуются более сложные настройки чем у современных SIEM-систем. Т.е. мы решаем вопросы мониторинга ИТ «вообще». Например, а где у нас в kafka самая большая очередь, почему она такая и сколько у нее консьюмеров.
Еще пример: мы хотим посмотреть, сколько у нас пользователей сидит в 1С и почему просаживается производительность СХД при этом, и какие самые длинные запросы на это влияют.
---
Вопрос: Умеет ли «Умный мониторинг» разруливать шторм алертов, если вышла из строя верхнеуровневая КЕ, обеспечивающая функциональность подчиненной КЕ?
Ответ: Пока не умеет. Сейчас алерты настраиваются либо точечно для каждой КЕ с помощью Grafana (там уже как настроят), либо с помощью внутренних алертов. Мы работаем над тем, чтобы снизить эффект «шторма» на оператора УМ.
---
Вопрос: Что нативно «Умный мониторинг» умеет собирать с приложений 1С? Как это анализировать, как пользоваться?
Ответ: Да практически все: из коробки: ЖР, ТЖ, APDEX, а сеансы и лицензии умеем получать через RAS; метрики кластера тоже собираем. Анализ в виде нативных инструментов появятся в УМ версии 1.2. Уже сейчас можно всеми этими собранными артефактами пользоваться в графане.
---
Вопрос: Есть ли в «Умном мониторинге» подсистема CMDB, существует ли автодискаверинг?
Ответ: Есть, существует.
Вопрос: Есть ли коннекторы к популярным системам мониторинга, дискаверинга и т.д.? Есть ли механизм, похожий на BPM платформы, конструкторы? Выполнить цепочку действий при наступлении триггера?
Ответ: Коннекторы есть. Выполнить цепочку действий – можно. На вебинаре показали, как.
---
Вопрос: Насколько широкие возможности для построения API (входящегоисходящего)?
Ответ: Есть, но пока не очень широкие. Уже есть API для регистрации инцидентов. В ближайших планах, в рамках проектов внедрений, безусловно, мы будем строить две схемы API: одна для интеграции с внешним/сторонним CMDB, потому что такая интеграция нужна в обе стороны, а вторая для интеграции с Service Desk
---Ответ: Коннекторы есть. Выполнить цепочку действий – можно. На вебинаре показали, как.
---
Вопрос: Насколько широкие возможности для построения API (входящегоисходящего)?
Ответ: Есть, но пока не очень широкие. Уже есть API для регистрации инцидентов. В ближайших планах, в рамках проектов внедрений, безусловно, мы будем строить две схемы API: одна для интеграции с внешним/сторонним CMDB, потому что такая интеграция нужна в обе стороны, а вторая для интеграции с Service Desk
Вопрос: Существует ли возможность кастомизации системы на уровне UI (дополнительные поля, логика и т.д.)? Ведь условная КЕ может кучу интересных параметров содержать в зависимости от типа, на которые важно смотреть при траблшутинге.
Ответ: Дополнительные поля – да. Остальное можно уточнить, написав нам подробнее, что интересует.
---
Вопрос: Можно ли «Умный мониторинг» использовать как коллектор логов, сливая в него всевозможные логи приложений?
Ответ: Да, можно.
---Ответ: Дополнительные поля – да. Остальное можно уточнить, написав нам подробнее, что интересует.
---
Вопрос: Можно ли «Умный мониторинг» использовать как коллектор логов, сливая в него всевозможные логи приложений?
Ответ: Да, можно.
Вопрос: Есть ли таблица сравнения с конкурентами?
Ответ: Мы считаем, что не нужно продвигаться на рынке за счет сравнения себя с конкурентами. Мы готовы с заказчиком обсуждать детали и отличия нашего продукта от продуктов конкурентов, если возникает такая необходимость. А вместо создания «табличек» предпочитаем делать востребованный полезный продукт, чтобы он выдерживал серьезную конкуренцию на рынке.
---
Вопрос: Какое ПО под капотом? От базы до визуализации?
Ответ: СУБД – PostgreSQL Timescale. Визуализация сейчас на Grafana, потом будет собственная. Все остальное – java.
---
Вопрос: Какой стек технологий используется в продукте? Есть ли возможность кастомизации системы своими руками?
Ответ: Рассказали и показали на вебинаре + смотрите ответы на подобные вопросы. Кастомизация есть, пока в ограниченном режиме. Кастомизация ИИ доступна. Есть возможности кастомизации через настройки системы УМ.
---Ответ: Мы считаем, что не нужно продвигаться на рынке за счет сравнения себя с конкурентами. Мы готовы с заказчиком обсуждать детали и отличия нашего продукта от продуктов конкурентов, если возникает такая необходимость. А вместо создания «табличек» предпочитаем делать востребованный полезный продукт, чтобы он выдерживал серьезную конкуренцию на рынке.
---
Вопрос: Какое ПО под капотом? От базы до визуализации?
Ответ: СУБД – PostgreSQL Timescale. Визуализация сейчас на Grafana, потом будет собственная. Все остальное – java.
---
Вопрос: Какой стек технологий используется в продукте? Есть ли возможность кастомизации системы своими руками?
Ответ: Рассказали и показали на вебинаре + смотрите ответы на подобные вопросы. Кастомизация есть, пока в ограниченном режиме. Кастомизация ИИ доступна. Есть возможности кастомизации через настройки системы УМ.
Вопрос: Сколько КЕ и сколько метрик держит система?
Ответ: Мы не ориентируемся на показатели – сколько метрик и КЕ. Мы ориентируемся на показатель транзакций/метрик в секунду (TPS). Целевые значения – 50 000 TPS. Целевые запросы от наших заказчиков, на которые мы сейчас ориентируемся: 1000+ агентов мониторинга. Исходя из этого можно спрогнозировать, сколько должно быть метрик – точно больше 100 000.
---Ответ: Мы не ориентируемся на показатели – сколько метрик и КЕ. Мы ориентируемся на показатель транзакций/метрик в секунду (TPS). Целевые значения – 50 000 TPS. Целевые запросы от наших заказчиков, на которые мы сейчас ориентируемся: 1000+ агентов мониторинга. Исходя из этого можно спрогнозировать, сколько должно быть метрик – точно больше 100 000.
Вопрос: Есть интеграция с Prometheus, VictoriaMetrics, Open Search, Loki, Elasticsearch, Tempo?
Ответ: Мы поддерживаем стандарт OpenTelemetry – это закрывает бóльшую часть потребностей. Другие интеграции надо обсуждать, уточнив что и в каком формате отгружать. Вообще, все наши метрики лежат в нашей базе данных в открытом видео – вы можете их экспортировать так, как вам нужно.
---
Вопрос: На каких данных строится модель нейросетей? Хватает ли данных для построения качественных моделей только данными заказчика или у вас есть готовая модель, которая концептуально охватывает весь пул проблем внутри себя и дообучаете на данных заказчика?
Ответ: Даже если брать одинаковые типы серверов, но с разной пользовательской нагрузкой, в итоге получаем сильно разные профили загрузки. И там, где мы ориентируемся на метрики, к сожалению, нельзя дать заказчику пред-обученную модель и сказать, мол, вот эта модель предсказывает поведение сервера 1С, так как сервера ведут себя по-разному даже внутри одного кластера.
Мы рассчитываем на то, что модель обучается на данных заказчика, и чем дольше она наблюдает за сервером, тем качественнее дает прогнозы. По большому счету, модель сама следит за ошибками своего предсказания и, при необходимости, запускает собственное переобучение. Мы показывали это в вебинаре – посмотрите!
Вопрос: Как выглядит решение для сбора метрик с оборудования, где нет возможности поставить агента?
Ответ: Можно использовать стандартный способ мониторинга – SNMP, как в Zabbix и других решениях.
---
Вопрос: Логи хранятся в Postgresql?
Ответ: Да, логи хранятся в PostgreSQL. При этом важно понимать – мы используем Timescale, а не чистый Postgres. Все хранится в гипер-таблицах. Можно управлять Retention policy, можно управлять колоночным типом хранения. В целом, это сильно помогает давать хорошую компрессию по логам и, особенно, по размеченным логам.
---
Вопрос: Как развертывается ваша система? Можно ли своими силами раскатать приложение на своих серверах или требуется внедрение?
Ответ: Систему УМ можно развернуть самостоятельно, у нас есть хорошая инструкция. Если кратко: нужно поставить сервер УМ, поставить Postgres и поставить агента на систему, которую следует мониторить.
---
Вопрос: Правильно понял, что сбор метрик с оборудования с API интерфейса не реализована сейчас?
Ответ: Свяжитесь с нами пожалуйста – мы на вебинаре попросили отдельно обсудить этот вопрос и связанные с ним задачи.
---
Вопрос: Что устанавливается в клиентскую инфраструктуру? Только агенты или ещё есть какие-то требования к развёртываемым компонентам в исследуемом контуре?
Ответ: Устанавливается только агент. Из требований – разве что открыть порт, по которому будут общаться агент и сервер УМ. Еще нужна java: подойдет любая, включая сертифицированные российские сборки.
---
Вопрос: Есть ли мониторинг контейнерных решений Docker/CRI и систем оркестрации контейнеров (кластеров Kubernetes)?
Ответ: Технически мы их можем мониторить уже прямо сейчас, исходя из тех наборов мониторов, которые у нас есть. В релизе УМ 1.2 планируем выпустить отдельные преднастроенные мониторы, отвечающие за работу с системами виртуализации.
---
Вопрос: Какая глубина хранения метрик? Для предсказания нужно много данных, и лучше за года 2, чтобы сравнивать разные периоды и учитывать сезонность?
Ответ: Глубина хранения определяется исключительно вашими доступными ресурсами. Мы выбрали в качестве базы данных PostgreSQL Timescale, потому что она на борту умеет управлять такими понятиями, как retention policy и compression policy. То есть, мы можем сами определить, что и с какой детализацией у нас хранится.
Например, метрики хранятся в сыром виде за последний месяц. Далее, если нам так нужно – они группируются до одной минуты и так хранятся еще полгода. Дальше при необходимости они группируются, скажем, до часа и хранятся еще 5 лет. Все это происходит автоматически, так как за это отвечает СУБД. Соответственно, настройку глубины и детализации хранения мы определяем на каждом уровне индивидуально – в зависимости от требований заказчика.
По метрикам – наш опыт эксплуатации говорит о том, что базы на 50-80 Гб более, чем достаточно для работы. Что касается сравнения разных периодов и учета сезонности, наш опыт мониторинга говорит о том, что сезонность из серии декабрь к декабрю – это максимальная глубина, которую надо делать. Существенное влияние в наших системах оказывают другие факторы за период: изменение количества пользователей, изменение инфраструктуры или функциональности. Поэтому сезонность как фактор влияния на прогноз сильно теряет свою значимость.
Сейчас мы развиваем anomaly detection, что позволит не просто оценивать метрику самой к себе, но и делать оценку на основании соседних метрик. То есть, учитывать метрики, влияющие внутри самой конфигурационной единицы и в связанных конфигурационных единицах. Основываясь на прогнозе, созданном на основание не одного фактора, а многих, мы получаем более точные предсказания. Единственное, обучение идет дольше, поэтому сейчас ищем «золотую середину» между количеством данных, которые нужно загрузить в модель, и функциональностью, позволяющей адекватно обучаться на CPU-ресурсах (не все могут позволить себе GPU).
---
Вопрос: Есть ли какая-то инструкция для новичков, где был бы подробно в картинках расписан порядок действий, который нужно совершить, чтобы в итоге получился конкретный результат. Например: «Инструкция как вывести на дашборд УМ топ-10 событий CALL из ТЖ длительностью более 10 сек», либо «Инструкция как вывести на график/дашборд кол-во событий "Конфликт блокировок при выполнении транзакции»
Ответ: Такой инструкции пока нет. Есть документация по настройке дашбордов. Пока используется Grafana – можно изучить возможности по ее настройке. Планируем задеплоить наш кастомный датасорс для нее, чтобы пользователям УМ было полегче. Следите за новостями!
---
Вопрос: Есть ли возможность для скриптов использовать внешнее хранилище в системе контроля версий?
Ответ: Планируем реализовать в ближайших версиях. Если не успеем в УМ 1.2 – в УМ 1.3 точно сделаем. При настройке можно будет выбрать место хранения скриптов – либо «внутри» УМ, либо во внешнем репозитории.
---
Вопрос: Связи между КЕ для дашборда ландшафта определяются автоматически при автодискавери или как-то вручную настраиваются?
Ответ: Оба варианта – те решения, которые установлены на самом сервере или связаны с конфигурационной единицей, устанавливаются автоматически при автодискаверинге. В случае, если какие-то связи не нашлись, их можно указать вручную. В УМ версии 1.2 попробуем реализовать AI-анализатор, который будет смотреть на корреляции между метриками и событиям по конфигурационным единицам и предлагать достроить отсутствующие связи.
---
Вопрос: Вы концептуально скажите, УМ сам это все разберет (включая блокировки ресурсов и т.д.) или надо самому по TLOCK'ам в UI ходить? Или условный TDEADLOCK
Ответ: Вообще, мы не создавали УМ как помощника «1С:Эксперта», который помогает глубоко расследовать проблемы производительности прикладных решений на платформе «1С:Предприятие 8». Тем не менее, УМ позволяет саккумулировать и комплексно изучить много информации, связанной с функционированием систем 1С. Поэтому УМ может реально ускорить и упростить расследования, проводимые «1С:Экспертом». Если нужно детальнее обсудить этот момент – напишите нам!
---Ответ: Мы поддерживаем стандарт OpenTelemetry – это закрывает бóльшую часть потребностей. Другие интеграции надо обсуждать, уточнив что и в каком формате отгружать. Вообще, все наши метрики лежат в нашей базе данных в открытом видео – вы можете их экспортировать так, как вам нужно.
---
Вопрос: На каких данных строится модель нейросетей? Хватает ли данных для построения качественных моделей только данными заказчика или у вас есть готовая модель, которая концептуально охватывает весь пул проблем внутри себя и дообучаете на данных заказчика?
Ответ: Даже если брать одинаковые типы серверов, но с разной пользовательской нагрузкой, в итоге получаем сильно разные профили загрузки. И там, где мы ориентируемся на метрики, к сожалению, нельзя дать заказчику пред-обученную модель и сказать, мол, вот эта модель предсказывает поведение сервера 1С, так как сервера ведут себя по-разному даже внутри одного кластера.
Мы рассчитываем на то, что модель обучается на данных заказчика, и чем дольше она наблюдает за сервером, тем качественнее дает прогнозы. По большому счету, модель сама следит за ошибками своего предсказания и, при необходимости, запускает собственное переобучение. Мы показывали это в вебинаре – посмотрите!
Вопрос: Как выглядит решение для сбора метрик с оборудования, где нет возможности поставить агента?
Ответ: Можно использовать стандартный способ мониторинга – SNMP, как в Zabbix и других решениях.
---
Вопрос: Логи хранятся в Postgresql?
Ответ: Да, логи хранятся в PostgreSQL. При этом важно понимать – мы используем Timescale, а не чистый Postgres. Все хранится в гипер-таблицах. Можно управлять Retention policy, можно управлять колоночным типом хранения. В целом, это сильно помогает давать хорошую компрессию по логам и, особенно, по размеченным логам.
---
Вопрос: Как развертывается ваша система? Можно ли своими силами раскатать приложение на своих серверах или требуется внедрение?
Ответ: Систему УМ можно развернуть самостоятельно, у нас есть хорошая инструкция. Если кратко: нужно поставить сервер УМ, поставить Postgres и поставить агента на систему, которую следует мониторить.
---
Вопрос: Правильно понял, что сбор метрик с оборудования с API интерфейса не реализована сейчас?
Ответ: Свяжитесь с нами пожалуйста – мы на вебинаре попросили отдельно обсудить этот вопрос и связанные с ним задачи.
---
Вопрос: Что устанавливается в клиентскую инфраструктуру? Только агенты или ещё есть какие-то требования к развёртываемым компонентам в исследуемом контуре?
Ответ: Устанавливается только агент. Из требований – разве что открыть порт, по которому будут общаться агент и сервер УМ. Еще нужна java: подойдет любая, включая сертифицированные российские сборки.
---
Вопрос: Есть ли мониторинг контейнерных решений Docker/CRI и систем оркестрации контейнеров (кластеров Kubernetes)?
Ответ: Технически мы их можем мониторить уже прямо сейчас, исходя из тех наборов мониторов, которые у нас есть. В релизе УМ 1.2 планируем выпустить отдельные преднастроенные мониторы, отвечающие за работу с системами виртуализации.
---
Вопрос: Какая глубина хранения метрик? Для предсказания нужно много данных, и лучше за года 2, чтобы сравнивать разные периоды и учитывать сезонность?
Ответ: Глубина хранения определяется исключительно вашими доступными ресурсами. Мы выбрали в качестве базы данных PostgreSQL Timescale, потому что она на борту умеет управлять такими понятиями, как retention policy и compression policy. То есть, мы можем сами определить, что и с какой детализацией у нас хранится.
Например, метрики хранятся в сыром виде за последний месяц. Далее, если нам так нужно – они группируются до одной минуты и так хранятся еще полгода. Дальше при необходимости они группируются, скажем, до часа и хранятся еще 5 лет. Все это происходит автоматически, так как за это отвечает СУБД. Соответственно, настройку глубины и детализации хранения мы определяем на каждом уровне индивидуально – в зависимости от требований заказчика.
По метрикам – наш опыт эксплуатации говорит о том, что базы на 50-80 Гб более, чем достаточно для работы. Что касается сравнения разных периодов и учета сезонности, наш опыт мониторинга говорит о том, что сезонность из серии декабрь к декабрю – это максимальная глубина, которую надо делать. Существенное влияние в наших системах оказывают другие факторы за период: изменение количества пользователей, изменение инфраструктуры или функциональности. Поэтому сезонность как фактор влияния на прогноз сильно теряет свою значимость.
Сейчас мы развиваем anomaly detection, что позволит не просто оценивать метрику самой к себе, но и делать оценку на основании соседних метрик. То есть, учитывать метрики, влияющие внутри самой конфигурационной единицы и в связанных конфигурационных единицах. Основываясь на прогнозе, созданном на основание не одного фактора, а многих, мы получаем более точные предсказания. Единственное, обучение идет дольше, поэтому сейчас ищем «золотую середину» между количеством данных, которые нужно загрузить в модель, и функциональностью, позволяющей адекватно обучаться на CPU-ресурсах (не все могут позволить себе GPU).
---
Вопрос: Есть ли какая-то инструкция для новичков, где был бы подробно в картинках расписан порядок действий, который нужно совершить, чтобы в итоге получился конкретный результат. Например: «Инструкция как вывести на дашборд УМ топ-10 событий CALL из ТЖ длительностью более 10 сек», либо «Инструкция как вывести на график/дашборд кол-во событий "Конфликт блокировок при выполнении транзакции»
Ответ: Такой инструкции пока нет. Есть документация по настройке дашбордов. Пока используется Grafana – можно изучить возможности по ее настройке. Планируем задеплоить наш кастомный датасорс для нее, чтобы пользователям УМ было полегче. Следите за новостями!
---
Вопрос: Есть ли возможность для скриптов использовать внешнее хранилище в системе контроля версий?
Ответ: Планируем реализовать в ближайших версиях. Если не успеем в УМ 1.2 – в УМ 1.3 точно сделаем. При настройке можно будет выбрать место хранения скриптов – либо «внутри» УМ, либо во внешнем репозитории.
---
Вопрос: Связи между КЕ для дашборда ландшафта определяются автоматически при автодискавери или как-то вручную настраиваются?
Ответ: Оба варианта – те решения, которые установлены на самом сервере или связаны с конфигурационной единицей, устанавливаются автоматически при автодискаверинге. В случае, если какие-то связи не нашлись, их можно указать вручную. В УМ версии 1.2 попробуем реализовать AI-анализатор, который будет смотреть на корреляции между метриками и событиям по конфигурационным единицам и предлагать достроить отсутствующие связи.
---
Вопрос: Вы концептуально скажите, УМ сам это все разберет (включая блокировки ресурсов и т.д.) или надо самому по TLOCK'ам в UI ходить? Или условный TDEADLOCK
Ответ: Вообще, мы не создавали УМ как помощника «1С:Эксперта», который помогает глубоко расследовать проблемы производительности прикладных решений на платформе «1С:Предприятие 8». Тем не менее, УМ позволяет саккумулировать и комплексно изучить много информации, связанной с функционированием систем 1С. Поэтому УМ может реально ускорить и упростить расследования, проводимые «1С:Экспертом». Если нужно детальнее обсудить этот момент – напишите нам!
Вопрос: Можно немного коснуться вопроса ценообразования? С каким минимальным количеством денег можно войти в проект, чтобы пощупать?
Ответ: Войти в проект, чтобы пощупать, можно в режиме «пилота». Сейчас мы активно набираем участников пилотирования и примерно 5-6 пилотов готовы сделать без оплаты.
Ответ: Войти в проект, чтобы пощупать, можно в режиме «пилота». Сейчас мы активно набираем участников пилотирования и примерно 5-6 пилотов готовы сделать без оплаты.
План такой: Примерно за 3 месяца у вас все это развернуть, дать вам пощупать и собрать обратную связь, и дальше либо реализовать эту обратную связь в рамках покупки, или завершить проект. Присылайте нам запрос в сообщении укажите «Участие в пилоте УМ» – что-нибудь придумаем. Кроме этого, в вебинаре рассказывали о планах выхода разных редакций УМ, среди которых будет бесплатная – с ограничением на количество агентов. Следите за новостями! Прайс на платные версии высылаем по запросу.
Вопрос: Можно настроить корреляцию между событиями из разных журналов по тайм-лайн? Например, ТЖ 1С, журнал веб-сервера и т.д.?
Ответ: Да, конечно, потому что все данные лежат в одной базе.
Вопрос: В рамках продукта есть какие-то готовые решения по мониторингу СУБД? Может ли инструмент показать, куда смотреть в случае проблем с производительностью Postgres, например?
Ответ: У УМ есть отдельные мониторы класса DBMS, которые собирают большое количество технических метрик из Postgres. Их все можно мониторить и визуализировать.
Вопрос: Как руководитель службы эксплуатации, имеющий 300+ различных информационных систем в эксплуатации, может одним взглядом (без кучи скроллов, переходов и т.д.) увидеть – все ли хорошо у него в инфраструктуре или нет? Т.е., верхнеуровнево хочется видеть состояние ИТ ландшафта, а потом дрилл дауном вниз идти
Ответ: На главной странице УМ есть укрупненный обзор ситуации. В вебинаре показали, как и где это смотреть.
Вопрос: Если баз много, то APDEX, ТЖ можно будет отфильтровать по базе, серверу?
Ответ: Да, конечно; каждая база – отдельная конфигурационная единица, ТЖ привязывается к КЕ.
Вопрос: Оповещения по инцидентам уже реализованы? Или пока только grafana incall? Хотелось бы иметь возможность получения вебхуков для телеграм-чатов и почты.
Ответ: Сейчас алертинг только из Grafana. В УМ версии 1.2 будут реализованы триггеры и алерты для почты, вебхука и телеграм. С кастомизацией темплейтов. (май 2025)
Вопрос: Кто настраивает связи КЕ?
Ответ: Это настраивается автоматически при дискаверинге, либо вручную при необходимости.
Вопрос: Автосвязь возможна только из снифинга траффика?
Ответ: Нет. При дискаверинге – чтение конфигов и физическое расположение. В УМ 1.2 есть AI-элемент, который анализирует взаимозависимость метрик (корреляции) и предлагает достроить отсутствующие связи. Трафик не снифим.
Вопрос: RBAC есть (ролевая модель доступа)? Просто была речь про возможность отправки команд из системы и это как вектор атаки, так и точка человеческого фактора.
Ответ: Сейчас упрощенная. В мае в релизе УМ 1.2 будет полноценная. Ограничения по контурам/системам и порядка 20 видов атомарных ролей.
Вопрос: Правильно ли я понимаю, что вы применяете методику APDEX не только к 1С?
Ответ: В целом, методика универсальна – можно применять к чему угодно, если есть замеры и их целевое время.
Ответ: Да, конечно, потому что все данные лежат в одной базе.
Вопрос: В рамках продукта есть какие-то готовые решения по мониторингу СУБД? Может ли инструмент показать, куда смотреть в случае проблем с производительностью Postgres, например?
Ответ: У УМ есть отдельные мониторы класса DBMS, которые собирают большое количество технических метрик из Postgres. Их все можно мониторить и визуализировать.
Вопрос: Как руководитель службы эксплуатации, имеющий 300+ различных информационных систем в эксплуатации, может одним взглядом (без кучи скроллов, переходов и т.д.) увидеть – все ли хорошо у него в инфраструктуре или нет? Т.е., верхнеуровнево хочется видеть состояние ИТ ландшафта, а потом дрилл дауном вниз идти
Ответ: На главной странице УМ есть укрупненный обзор ситуации. В вебинаре показали, как и где это смотреть.
Вопрос: Если баз много, то APDEX, ТЖ можно будет отфильтровать по базе, серверу?
Ответ: Да, конечно; каждая база – отдельная конфигурационная единица, ТЖ привязывается к КЕ.
Вопрос: Оповещения по инцидентам уже реализованы? Или пока только grafana incall? Хотелось бы иметь возможность получения вебхуков для телеграм-чатов и почты.
Ответ: Сейчас алертинг только из Grafana. В УМ версии 1.2 будут реализованы триггеры и алерты для почты, вебхука и телеграм. С кастомизацией темплейтов. (май 2025)
Вопрос: Кто настраивает связи КЕ?
Ответ: Это настраивается автоматически при дискаверинге, либо вручную при необходимости.
Вопрос: Автосвязь возможна только из снифинга траффика?
Ответ: Нет. При дискаверинге – чтение конфигов и физическое расположение. В УМ 1.2 есть AI-элемент, который анализирует взаимозависимость метрик (корреляции) и предлагает достроить отсутствующие связи. Трафик не снифим.
Вопрос: RBAC есть (ролевая модель доступа)? Просто была речь про возможность отправки команд из системы и это как вектор атаки, так и точка человеческого фактора.
Ответ: Сейчас упрощенная. В мае в релизе УМ 1.2 будет полноценная. Ограничения по контурам/системам и порядка 20 видов атомарных ролей.
Вопрос: Правильно ли я понимаю, что вы применяете методику APDEX не только к 1С?
Ответ: В целом, методика универсальна – можно применять к чему угодно, если есть замеры и их целевое время.
