Привязка порогов

BUSINESSENTERPRISE

Описание и сценарии актуальны для Monq версии не ниже 9.2.0

Рассматриваемый вариант не является единственно верным и представлен в демонстрационных целях

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

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

Сценарий привязки КЕ к порогам метрик

В статье приводится два варианта сценария привязки. Назовем их: простой (simple) и расширенный (advanced).

Оба сценария предназначены для привязки конфигурационных единиц (КЕ) к порогам метрик, и отличаются только лишь способами поиска нужной КЕ в базе данных РСМ.
В простом сценарии поиск КЕ производится в цикличном вызове функций фильтрации FilterConfigItemsExtended для каждого порога, что накладывает дополнительные расходы при обработке множества порогов, сгенерированных одним правилом.
В расширенной версии сценария используются специальные функции хеширования результатов фильтрации сразу по нескольким порогам одновременно, за счет чего фильтрация проходит быстрее. Заметить данный прирост в скорости можно только на правилах порогов, которые генерируют более 100 порогов за раз.

Главным требованием для связывания любых объектов в Monq является наличие общего признака у этих объектов

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

Предварительные условия

Предполагается, что до применения данной статьи выполнены следующие условия:

1. Cоздан поток данных и настроен сбор метрик (1, 2) из источника

2. В настройках CMDB для необходимых типов КЕ настроены атрибуты, например:
   

3. Созданы КЕ соответствующего типа и в каждой из них в атрибутах содержится уникальное идентифицирующее ее значение. Например:

4. Настроены правила порогов

Импорт сценария

Выбрать можно любой сценарий из приведенных ниже:

• Bind CIs to Thresholds-Simple.txt (простой)
  Тип сценария: ThresholdsToCmdbBinder

• Bind CIs to Thresholds-Advanced.txt (расширенный)
  Тип сценария: ThresholdsToCmdbBinder

Сценарий необходимо импортировать, скомпилировать и активировать.

Донастройка правил порогов

Основным условием запуска сценариев привязки с типом ThresholdsToCmdbBinder является выбор нужного сценария в блоке Связь с CDMB, правила порога:

В целевых правилах порогов добавьте следующие аннотации (в самом низу настроек):

1. • Ключ: bindci_attr_key
   • Значение: скопируйте название атрибута типа КЕ используя кнопку копирования в параметрах КЕ:
     
2. • Ключ: bindci_attr_value
   • Значение: {{ Metric.Labels.название_метки }}
     Вместо название_метки впишите название одной из меток собираемых метрик, в которой содержится уникальное значение, которое совпадает с аналогичным в атрибуте КЕ.
     Например, на скриншоте ниже такая метка имеет название "instance". Возможно в ваших метриках это будет другая метка. Ее название и нужно добавить:
     

Компоненты и слоты

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

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

1. В настройках CMDB выбрать тип КЕ, в рамках которого планируется привязывать пороги с указанием слотов компонентов
2. Выбрать (или создать новый) компонент, в котором будут указаны слоты
3. Добавить слоты
4. В правилах порогов добавить еще 2 аннотации
   • Ключ: component
     Значение: название компонента, настроенного в типе КЕ
   • Ключ: slot
     Значение: название слота компонента, настроенного в типе КЕ

важно

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

Сценарий создания сигналов по порогам

Этот сценарий обрабатывает изменяющиеся пороговые значения метрик, создавая и закрывая сигналы.
Уровни критичности сигналов соответствуют уровням, установленным в блоке условий детектора аномалий.

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

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

Импорт сценария

Signal Processor for Thresholds.txt (github)
Тип сценария: SignalProcessor

Сценарий необходимо импортировать, скомпилировать и активировать.

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