Гайд с видео: метрики в Monq от сбора данных до алертинга

Как получить от мониторинга уверенность, что ИТ-инфраструктура работает как надо? В этой статье разберемся, как устроена работа с метриками в Monq: от их сбора и автоматической привязки к контекстным элементам до создания кастомных метрик и контроля качества покрытия. Поговорим о том, как быть уверенным, что система действительно «зеленая» — а не делает вид, что у вас все в порядке. А в конце статьи вас ждет видео с конкретным примером работы с метриками от А до Я.

Попробуйте нашу бесплатную комьюнити OnPrem-версию — в ней доступен весь функционал, о котором мы пишем в блоге.

Что такое метрики и зачем они нужны?

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

Вот последовательность работы с метриками, про которую подробно расскажем ниже:

• Шаг 1. Сбор метрик: как данные попадают в Monq

• Шаг 2. Настройка конфигурационной единицы (КЕ)

• Шаг 3. Создание правил порогов: научите вашу систему

• Шаг 4. Автоматизация: сценарии, которые все связывают

• Шаг 5. Настройка алертов: как и кому сообщать о проблеме

• Шаг 6. Кастомные метрики: как извлечь дополнительную ценность из событий и логов

• Видео-урок Monq Monitoring: как построить систему метрик, которая действительно работает

• Заключение и дополнительные ссылки

Шаг 1. Сбор метрик: как данные попадают в Monq

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

Начать работу с метриками в Monq проще всего через экран «Сбор данных», где создаются потоки. Нажимаете «Создать поток», — задаете рабочую группу, имя и (по желанию) описание. Если есть готовая конфигурация в виде кода — можно сразу загрузить.

После создания откроется интерфейс потока, где вы добавляете задания и обработчики — они будут собирать и направлять данные туда, где им место. Все в целм несложно, у вас должно получиться.

Агенты Monq — как система узнает, что и откуда собирать

Monq поддерживает два основных метода интеграции с внешними системами для сбора данных:

1. Push-метод: В этом подходе внешние системы самостоятельно отправляют данные в Monq через REST HTTP API потоков данных. Примеры таких интеграций включают Prometheus (Alertmanager), Ntopng, FluentBit и Nagios Core.

2. Pull-метод: Здесь Monq с помощью собственных агентов подключается к внешним системам и извлекает из них данные. Для этого используются готовые шаблоны конфигурации и плагины, а также возможна разработка пользовательских конфигураций заданий и обработчиков. Примеры систем для таких интеграций: Zabbix, SCOM, Nagios XI и vCenter.

Если вы собираетесь использовать pull-метод, когда Monq сам «сходит» за данными во внешние системы, придется подключить Агентов Monq. Это небольшие приложения, которые устанавливаются на серверы или в инфраструктуру, откуда нужно стянуть метрики и события. Агенты передают их в заранее настроенные Потоки данных Monq.

Агенты умеют предварительно обрабатывать информацию: фильтровать инфошум, нормализовывать формат. Все это важно, чтобы данные были готовы к использованию. Конфигурация агентов — это, по сути, сценарии, в которых описано, что, как часто и откуда нужно собирать.

Как работать с метриками после сбора

Когда Потоки данных созданы, а агенты работают, метрики начинают поступать в систему. Но просто собирать значения — недостаточно. Мониторинг должен не только видеть данные, но и уметь на них реагировать. Для этого в Monq настраиваются правила порогов — те самые условия, при которых система определяет, что «что‑то пошло не так». Например, если загрузка CPU больше 90% дольше пяти минут — это уже сигнал.

Следом за этим метрики и их пороги можно привязать к Конфигурационным единицам (КЕ) — объектам инфраструктуры, которые мониторятся. Это позволяет связать данные с конкретным сервером, микросервисом или базой данных, и построить дерево зависимостей, которое даст полную картину происходящего.

Финальный шаг — настройка уведомлений и алертов. Тут все зависит от вашей политики: кто и когда должен получить сообщение, в каком канале (Telegram, SMS, почта и т.д.), и какие действия должны быть предприняты.

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

Шаг 2. Настройка конфигурационной единицы (КЕ)

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

КЕ нужна не только для структурирования данных, но и для автоматизации мониторинга. Она объединяет метрики, пороги, события и алерты вокруг конкретного объекта, помогает отслеживать его «здоровье» на разных уровнях и связывает все это с остальной инфраструктурой. Чтобы КЕ работала правильно, ее нужно корректно настроить.

Что нужно настроить:

• Тип КЕ, который соотносится к определенному типу — «Сервер», «Сеть», «Сервис» и т.д.. Тип определяет набор атрибутов, описывающих эту единицу — серийный номер, IP-адрес, ID в CMDB, название хоста или имя сервиса. Один из атрибутов всегда используется как уникальный идентификатор, чтобы система могла точно сопоставлять метрики и события с нужной КЕ при автоматической привязке данных.

• Компоненты — разбиваем КЕ на логические части (например, диск, память, CPU). У сервиса — backend, frontend, API. Такая структура позволяет отслеживать метрики по конкретным узлам и быстро локализовать проблему, если она возникла., отслеживать здоровье каждой части КЕ отдельно.

• Слоты — специальные места, куда автоматически привязываются метрики определенного типа. Например, слот disk_free_space будет ожидать метрику свободного места на диске. Каждый слот может содержать только один тип метрик, а правила сопоставления задаются через шаблоны имен и атрибутов.  Благодаря слотам выстраивается единая модель мониторинга, которая масштабируется и адаптируется к изменениям инфраструктуры.

Как настраивать:

1. На верхнем уровне находится сама КЕ — например, сервер или сервис, за которым мы следим.

2. По умолчанию каждая КЕ содержит компонент Common. Все сигналы, пороги и метрики без дополнительной настройки будут привязываться именно к нему. Это удобно для базового мониторинга, но не позволяет гибко управлять «здоровьем» отдельных частей объекта.

3. Чтобы настроить более точную модель мониторинга, добавьте собственные компоненты. Например, если вы хотите следить отдельно за дисками, памятью и CPU, создайте для каждого из них свой компонент.

4. Создаются слоты для каждого компонента  — как «порты приема» метрик. Один слот — один тип метрик. Например, disk_used_percent, cpu_load, memory_free.

5. Пороги и сигналы автоматически привязываются к слотам, если входящая метрика подходит по шаблону. 

Сухой остаток: на вкладке «Метрики» у любой КЕ можно увидеть всю ее структуру: компоненты, слоты, метрики и, что важно — наличие или отсутствие порогов. Это удобная точка контроля: вы сразу видите, какие показатели действительно находятся «под наблюдением», а какие просто собираются, но не анализируются. Такая вкладка экрана позволяет регулярно просматривать аудит покрытия мониторингом и настраивать его там, где пока «слепая зона».

Шаг 3. Создание правил порогов: научите систему понимать, где «ОК» и где «Critical»

Когда метрики уже поступают в систему, самое время начать распознавать ситуации сбоев. Для этого в системе настраиваются правила порогов — они определяют, какие значения считаются нормальными, а какие сигнализируют о проблемах.

Каждое правило представляет собой условие, написанное на языке MetricsQL, Если вы знакомы с Prometheus, проблем разобраться я языке не будет. Например, можно задать правило: если в течение 10 минут средняя загрузка CPU превышает 90%, — пора слать алерт. Или выставить другой порог — если свободного места на диске осталось меньше определенного размера.

У каждого правила может быть несколько уровней срабатывания: от OK (все нормально) до Critical (нужна немедленная реакция). Система проверяет их по порядку: если совпало с критическим условием — остальные игнорируются. Уровень OK обязателен всегда — он говорит о том, что все в порядке. Другие уровни можно настраивать гибко: например, указать, что температура считается проблемной как при понижении, так и при перегреве. 

Когда правило срабатывает, возможны три сценария:

1. Открытие или переключение уровня — если текущее значение метрики попадает под новое условие (неважно, улучшение или ухудшение), предыдущий порог закрывается, и открывается новый.

2. Подтверждение — если условие остается прежним, система просто обновляет дату подтверждения срабатывания.

3. Отсутствие данных — если данные перестали поступать, порог не подтверждается, а дата остается прежней.

Зачем нужно подтверждение? Оно помогает отследить, что данные вообще продолжают поступать. В настройках порога можно включить автозакрытие — например, если подтверждение не приходило в течение 30 минут, порог автоматически закрывается. Это позволяет выявлять участки системы, где сбор метрик внезапно прекратился.

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

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

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

На этом этапе можно заранее проверить, как правило работает: создать пороги и убедиться, что они появляются. Если все отображается корректно, правило сохраняется и активируется — и система начинает полноценно следить за метриками.

Также важно понимать, как система работает с уже сработавшими порогами. Если значение метрики продолжает соответствовать текущему уровню тревоги, Monq просто подтверждает порог — обновляет дату последнего срабатывания. А если данные перестают приходить, и порог не подтверждается в течение, например, 30 минут, — он автоматически закрывается. Это важно, потому что такие закрытия сигнализируют о том, что мы, возможно, больше не получаем данные — и это уже повод проверить, все ли в порядке со сбором.

Шаг 4. Автоматизация: сценарии, которые все связывают

После настройки сбора метрик, определения конфигурационных единиц (КЕ) и установки пороговых значений, следующий шаг — внедрение автоматизации. Это позволяет Monq не только собирать и анализировать данные, но и автоматически реагировать на определенные события, обеспечивая оперативность в управлении инфраструктурой. Смысл автоматизации ясен — в сколь нибудь сложной  ИТ-среде ручное управление процессами мониторинга неэффективно. 

В Monq для автоматизации есть удобный low-code редактор сценариев. Он позволяет связать все, что вы настроили ранее, и задать логику реакции системы на события: от построения модели до отправки уведомлений.

Например, если вы хотите автоматически собирать ресурсно-сервисную модель, сценарий сможет отслеживать поступающие события от систем мониторинга (таких как Zabbix), создавать КЕ, наполнять их компонентами и слотовыми метками, а также устанавливать связи между объектами. Это избавляет от рутинной ручной работы и снижает вероятность ошибок.

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

• обработка события (например, порога);

• фильтрация по условиям (тип, уровень, текст события);

• генерация сигнала с нужным приоритетом;

• автосоздание КЕ и привязка порога к нужному объекту;

• отправка уведомления или запуск внешнего процесса.

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

Это особенно полезно для создания кастомных метрик (например, расчетных показателей на основе нескольких исходных метрик) — см. Шаг 6 ниже про кастомные метрики.

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

Шаг 5. Настройка алертов: как и кому сообщать о проблеме

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

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

Настройка алертов начинается с определения каналов: Telegram, почта, Microsoft Teams или VK Teams, Webhook или внутренняя панель в Monq. Каждый канал можно связать с нужной группой получателей и задать правила, когда и при каких условиях туда будет уходить уведомление. Например, дежурной смене можно направлять сообщения круглосуточно, а разработчику — только в рабочее время, если уровень сигнала выше определенного порога.

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

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

Алертинг в Monq можно выстроить по-разному:

• По появлению сигналов;

• По изменению здоровья КЕ;

• Непосредственно по метрикам (появится в версиях Monq, начиная с “9”).

Чтобы не утонуть в сообщениях можно сделать какой-то синтетический сигнал или получать данные по качеству мониторинга в виде отчета. 

При этом, чтобы избежать ложного ощущения стабильности, важно отслеживать качество покрытия мониторингом — то есть, действительно ли мы получаем данные, по которым строятся графики ирассчитываются пороги. Если метрики перестали поступать, КЕ может оставаться «зелёной» просто потому, что система ничего не видит.

В таких случаях полезно настраивать отдельные оповещения: например, запускать проверку покрытия по расписанию (допустим, ночью) и формировать отчет. С утра дежурный инженер получает его по почте или в Telegram и уже принимает решение: все ли в порядке, или где-то данные перестали приходить. Это — не аварийный алерт, а регулярный контроль фундамента мониторинга.

В итоге получаем полноценный пайплайн, начиная со сбора метрик и до расчета здоровья КЕ и оповещений, контролируя при этом качество мониторинга. 

Шаг 6. Кастомные метрики: как извлечь дополнительную ценность из событий и логов

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

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

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

Таким образом, даже если нужные показатели не поступают в систему напрямую, вы можете обогатить мониторинг собственной логикой. Это инструментарий для ситуаций, когда стандартных метрик недостаточно, а данные доступны — просто в другом формате.

Видео-урок Monq Monitoring: как построить систему метрик, которая действительно работает

Суха теория, не правда ли? В учебном видео пошагово разберем, как в Monq настроить полноценную систему мониторинга на основе метрик — от создания конфигурационных единиц до настройки алертов и кастомных метрик. Смотрите ролик где удобно: 

YouTube
VK Видео

Из видео узнаете, как добиться прозрачности: какие показатели в норме, а где наблюдаются проблемы. Отдельно разберемся с метрикой качества покрытия мониторингом — критически важным параметром, который позволяет убедиться, что система действительно «смотрит» на объект и своевременно отреагирует в случае сбоя, а не останется в зеленой зоне, пока не станет слишком поздно.

Все 6 разделов о работе с метриками, разобранные выше, в видео-уроке показаны наглядно и всего за 11 минут:

• Что такое КЕ и как с их помощью логично организовать мониторинг объектов;

• Как грамотно настроить компоненты и слоты, чтобы сразу увидеть, где недостаточно настроены метрики и пороги;

• Как создавать правила, по которым Monq сам определит: все ли в порядке или нужно реагировать;

• Как автоматизация в Monq позволяет соединить метрики, пороги и события в единую управляемую систему;

• Как настраиваются алерты ичто учесть, чтобы не «утонуть» в уведомлениях;

• И наконец — как из событий и логов собирать собственные метрики прямо внутри платформы, без внешних систем.

Заключение и дополнительные ссылки

• Мониторинг высоконагруженных систем: ускоряем обработку тысяч событий с обработчиками автоматизации в мониторинге Monq.

• Мониторинг высоконагруженных систем: поддержка SLA и масштабируемость.

• Зонтичный мониторинг в X5 Group, или как построить цифровую карту здоровья бизнеса с миллионом объектов.

• Автоматизация мониторинга с Monq: Управление сигналами и интеграция с Zabbix.

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

Также приглашаем присоединиться к программе раннего доступа и протестировать наш бесплатный облачный сервис Monq On-Call, зарегистрировавшись на ранний доступ.