...
draw.io Diagram border true viewerToolbar true fitWindow false diagramName Диаграмма создания событий с устройств simpleViewer false diagramWidth 11011102 revision 14
Генерация событий в СУ происходит в несколько этапов:
- Получение данных (метрик/SNMP trap/Syslog-сообщений/результатов задач/событий обнаружения сущностей мониторинга) от устройств;
- Анализ Syslog-сообщений WLC для создания wireless-событий;
- Анализ данных и регистрация системных событий;
- Сохранение системного события в базу данных.
...
- Syslog-cообщения, которые отсылает устройство и которые регистрируются системой управления;
- SNMP trap, которые отсылает устройство и которые регистрируются системой управления;
- SNMP-метрики (SNMP poll), которые система управления собирает с устройств;
- Задачи, которые запускаются в системе;
- Wireless-события, которые создаются на основе Syslog-cообщений, полученных с устройства WLC;
- События обнаружения, которые создаются на основе данных сущностей мониторинга, собираемых с устройства по протоколу SNMP или NETCONF (только для устройств ME).
| Примечание |
|---|
| Для корректного сбора данных параметры доступа к устройствам должны быть актуальными, статус доступности устройств по SNMP — положительным. |
...
В качестве опросчика SNMP-метрик выступает сервис monitoring-service, который опрашивает добавленные в систему устройства по протоколу SNMP по метрикам нагрузки CPU/RAM/ROM, трафику и ошибкам на интерфейсах (состав метрик различается в зависимости от типа устройства и его конфигурации). Также monitoring-service сканирует устройства и собирает данные о сущностях (интерфейсах, лицензиях, кластерах) и их свойствах (статус работы, время до истечения лицензии, роли), формируя событие обнаружения.
В качестве планировщика задач выступает сервис cron-manager, который позволяет управлять задачами взаимодействия с В качестве планировщика задач выступает сервис cron-manager, который позволяет управлять задачами взаимодействия с устройствами.
Полученные данные сохраняются в базу данных. SNMP trap отображаются в разделе "SNMP trap", Syslog-сообщения — в разделе "Syslog", задачи — в разделе "Задачи", wireless-события — в разделе "События" → "Wireless", а собранные метрики доступны для просмотра на странице устройства в разделе "Мониторинг устройства" → "Метрики".
...
Полученные метрики, Syslog-cообщения, SNMP trap, задачи, события обнаружения и wireless-события анализируются сервисом problem-manager. Сервис сравнивает значения метрик или параметров SNMP trap/Syslog-cообщений/задач/событий обнаружения/wireless-событий с условиями правил генерации событий (см. раздел "Настройки" → "Мониторинг" → "Правила генерации событий") и, если данные устройств удовлетворяют условиям правила, то система генерирует новое системное событие. Зарегистрированные системные события сохраняются в базу данных. Системные события отображаются в разделе "События" → "Системные".
...
Для создания правила генерации событий перейдите на страницу "Настройки" → "Мониторинг" → "Правила генерации событий" и нажмите кнопку "Создать": откроется диалоговое окно создания правила. Заполните поля в соответствии со скриншотом ниже.
Пояснение по шагам:
...
Задача: создать правило генерации события для случая, когда SNMP-Ping от сервера ECCM до устройства типа ESR превышает значение в 300 мс. При срабатывании такого правила будет создано системное событие "High SNMP-Ping for ESR".
Для создания правила генерации событий перейдите на страницу "Настройки" → "Мониторинг" → "Правила генерации событий" и нажмите кнопку "Создать": откроется диалоговое окно создания правила. Заполните поля в соответствии со скриншотом ниже.
Пояснение по шагам:
- "Название правила" и его "Важность" — выбираются в зависимости от критичности события на вашей сети;
- "Включить правило" — активировано. Обеспечивает активацию правила генерации события сразу после его создания;
- "Шаблон события" — текстовый шаблон, согласно которому будет создаваться описание соответствующего события;
- Тип данных:
- "Тип устройства" — ESR. Выбирается тип устройств, для которых может применяться данное правило;
- "Тип данных" — Метрика. SNMP-Ping производится сервисом ECCM в сторону устройства, данные сохраняются в систему в качестве метрики;
- "Элемент данных" — Device availability by SNMP. Это название метрики SNMP внутри системы;
- Область применения:
- "Область применения" — группа "eccm". Обеспечивает работу правила по всем группам в системе (т. к. группа eccm — корневая группа);
- Описание элемента данных — содержит описание выбранного элемента данных и такую информацию, как SNMP-метрика, тип данных, которые в ней ожидаются, и единицы ее измерения;
- Условия генерации событий:
- "Элемент данных" в условиях генерации событий — Metric: availability.ping.time[snmp]. Некоторые метрики могут содержать несколько значений в списке элемента данных, для настройки условия выбирается одно из них;
- "Функция сравнения" — Больше или равно. В примере задано условие создания события при значении метрики availability.ping.time[snmp] большем, чем пороговое значение;
- "Пороговое значение" — Указать константу. Статическое значение, с которым будет сравниваться полученное.
- "Константа" — 300 мс.
После заполнения полей нажмите кнопку "Создать". Созданное правило будет отображено в таблице правил. Таким образом, как только для какого-либо устройства типа ESR значение SNMP-метрики "availability.ping.time[snmp]" в СУ превысит 300 мс, то система обработает его в соответствии с созданными правилами генерации событий и создаст соответствующее системное событие.
...
Для создания правила генерации событий перейдите на страницу "Настройки" → "Мониторинг" → "Правила генерации событий" и нажмите кнопку "Создать": откроется диалоговое окно создания правила. Заполните поля в соответствии со скриншотами ниже.
Пояснение по шагам:
- "Название правила" и его "Важность" — выбираются в зависимости от критичности события на вашей сети;
- "Включить правило" — активировано. Обеспечивает активацию правила генерации события сразу после его создания;
- "Шаблон события" — текстовый шаблон, согласно которому будет создаваться описание соответствующего события;
- Тип данных:
- "Тип устройства" — ESR. Выбирается тип устройств, для которых может применяться данное правило;
- "Тип данных" — Метрика. Опрос счетчиков ошибок на интерфейсах устройства производится сервисом ECCM и сохраняется в систему в качестве метрики;
- "Элемент данных" — Interface traffic metrics. Это название метрики внутри системы;
- Область применения:
- "Область применения" — обеспечивает работу правила только для выбранного устройства. Добавлены устройства, выбрано устройство с IP-адресом 100.110.1.122;
- Описание элементов данных — содержит описание выбранного элемента данных и такую информацию, как SNMP-метрика, тип данных, которые в ней ожидаются, и единицы ее измерения;
- Условия генерации событий:
- "Групповое условие" — "И". Логическая операция, применяемая к условиям в группе условий. Устанавливает правило создания события только при достижении обоих условий.
- Первое условие — задано ограничение по имени интерфейса для анализа метрик:
- "Элемент данных" — Property: interface.object.property.ifName. Задается для ограничения анализа метрик только по одному интерфейсу устройства;
- "Функция сравнения" —для первого условия — Равно. Задано условие, при котором системное событие создается при совпадении имени интерфейса;
- "Пороговое значение" — Указать константу;
- "Константа" для первого условия — gigabitethernet 1/0/1. Задано условие создания события при "Property: interface.object.property.ifName" с интерфейсом gigabitethernet 1/0/1 (имя интерфейса указано из конфигурации устройства);
- Второе условие — указано ожидаемое значение ошибок на интерфейсе:
- "Элемент данных" — Metric: interface.traffic.errors.in. Необходимо выбрать поле элемента данных, в котором указывается счетчик ошибок на интерфейсе в секунду;
- "Функция сравнения" для второго условия — Больше. Задано условие, при котором системное событие создается при значении "Metric: interface.traffic.errors.in" большем, чем пороговое значение;
- "Пороговое значение" — Указать константу;
- "Константа" для второго для второго условия — 50. Задано условие создания события при превышении "Metric: interface.traffic.errors.in" порогового значения в 50 ошибок в секунду.
...
Для создания правила генерации событий перейдите на страницу "Настройки" → "Мониторинг" → "Правила генерации событий" и нажмите кнопку "Создать": откроется диалоговое окно создания правила. Заполните поля в соответствии со скриншотами ниже.
Пояснение по шагам:
- "Название правила" и его "Важность" — выбираются в зависимости от критичности события на вашей сети;
- "Включить правило" — активировано. Обеспечивает активацию правила генерации события сразу после его создания;
- "Шаблон события" — текстовый шаблон, согласно которому будет создаваться описание соответствующего события;
- Тип данных:
- "Тип устройства" — MES23xx/33xx/35xx/36xx/53xx/5400. Выбирается тип устройств, для которых может применяться данное правило;
- "Тип данных" — Syslog;
- "Элемент данных" — syslogMessage. Устройство сообщает сервису ECCM о неудачной попытке аутентификации при помощи Syslog-сообщения, данные сохраняются в систему в качестве Syslog-сообщения;
- Область применения:
- "Область применения" — группа "eccm". Обеспечивает работу правила по всем группам в системе (т. к. группа eccm — корневая группа);
- Описание элемента данных — содержит описание параметров Syslog-сообщения;
- Условия генерации событий:
- "Групповое условие" — "И". Логическая операция, применяемая к условиям в группе условий. Устанавливает правило создания события только при достижении обоих условий;
- Первое условие — задано ключевое слово, которое должен содержать тег Syslog-сообщения, указывающее, что была зафиксирована попытка аутентификации на устройстве:
- "Элемент данных" — tag. Задается поле Syslog-сообщения, которое будет анализироваться системой;
- "Функция сравнения" для первого условия — "Содержит". Задана функция сравнения для анализа тега;
- "Пороговое значение" — Указать константу. Значение, которое должно содержаться в сообщении;
- "Константа" для первого условия — "AAA". Задано ключевое слово "AAA", которое необходимо обнаружить в теге полученного Syslog-сообщения;
- Второе условие — задано ключевое слово, которое должен содержать тег Syslog-сообщения, указывающее, что была зафиксирована попытка аутентификации на устройстве была неудачной:
- "Элемент данных" — tag. Задается поле Syslog-сообщения, которое будет анализироваться системой;
- "Функция сравнения" для второго условия — "Содержит". Задана функция сравнения для анализа тега;
- "Пороговое значение" для второго условия — Указать константу. Значение, которое должно содержаться в сообщении;
- "Константа" для второго условия — "REJECT". Задано ключевое слово "REJECT", которое необходимо обнаружить в REJECT. Задано ключевое слово "REJECT", которое необходимо обнаружить в теге полученного Syslog-сообщения.
...
Создание правила генерации событий на основе задачи
Событие при
...
незавершении задачи для устройства
Задача: создать правило генерации события для случая, когда для устройств модели ESR-200 в подсети 100.110.1.0/24 задача "Обновить информацию об интерфейсах" не была завершена. При срабатывании такого правила будет создано системное событие "Интерфейсы устройств ESR-200 в сети 100.110.1.0/24 не обновлены".
Для создания правила генерации событий перейдите на страницу "Настройки" → "Мониторинг" → "Правила генерации событий" и нажмите кнопку "Создать": откроется диалоговое окно создания правила. Заполните поля в соответствии со скриншотами ниже.
Пояснение по шагам:
- "Название правила" и его "Важность" — выбираются в зависимости от критичности события на вашей сети;
- "Включить правило" — активировано. Обеспечивает активацию правила генерации события сразу после его создания;
- "Шаблон события" — текстовый шаблон, согласно которому будет создаваться описание соответствующего события;
Тип данных:
"Тип устройства" — ESR. Выбирается тип устройств, для которых может применяться данное правило;
"Тип данных" — Задача;
"Элемент данных" — "Обновить информацию об интерфейсах". Задачи обрабатываются сервисом ECCM, данные сохраняются в систему в качестве задачи;
Область применения:
"Область применения" — группа "eccm". Обеспечивает работу правила по всем группам в системе (т. к. группа eccm — корневая группа);
Описание элемента данных — содержит описание выбранного элемента данных и такую информацию, как статус задачи и информация об устройстве, к которому она применяется;
Условия генерации событий:
"Групповое условие" — "И". Логическая операция, применяемая к условиям в группе условий. Устанавливает правило создания события только при достижении обоих всех условий;
Первое условие — задана модель устройства, указывающая, что задача выполнялась для данной модели устройств:
"Элемент данных" — task.deviceModel. Задается поле модели устройства, которое будет анализироваться системой;
"Функция сравнения" для первого условия — "Содержит". Задана функция сравнения для анализа модели устройства;
"Пороговое значение" — Указать константу. Значение, которое должно содержаться в сообщении;
"Константа" для первого условия — "ESR-200". Задано ключевое слово "ESR-200", которое необходимо обнаружить в модели устройства полученной задачи;
Второе условие — задан IP-адрес устройства, указывающий, что задача выполнялась для устройств в данной подсети:
"Элемент данных" — task.deviceIp. Задается поле IP-адреса устройства, которое будет анализироваться системой;
"Функция сравнения" для второго условия — "Содержит". Задана функция сравнения для анализа IP-адреса устройства;
"Пороговое значение" для второго условия — Указать константу. Значение, которое должно содержаться в сообщении;
"Константа" для второго условия — "100.110. "100.110.1.". Задано ключевое слово "100.110.1.", которое необходимо обнаружить в IPв IP-адрес адресе устройства полученной задачи;
Третье условие — задан статус задачи, указывающий, что задача не была выполнена:
"Элемент данных" — status. Задается поле статуса задачи, которое будет анализироваться системой;
"Функция сравнения" для второго условия — "Не равно". Задана функция сравнения для анализа статуса задачи;
"Пороговое значение" — Указать константу. Значение, которое должно содержаться в сообщении;
"Константа" для второго " для второго условия — "Выполнено". Задано Задано условие создания события при несоответствии статуса задачи значению "Выполнено".
После заполнения полей нажмите кнопку "Создать". Созданное правило будет отображено в таблице правил. Таким образом, как только для какого-либо устройства модели ESR-200 в подсети 100.110.1.0/24 задача "Обновить информацию об интерфейсах" не завершится, система обработает ее в соответствии с созданным правилом генерации событий и создаст соответствующее системное событие.
...
Для создания правила генерации событий перейдите на страницу "Настройки" → "Мониторинг" → "Правила генерации событий" и нажмите кнопку "Создать". Откроется диалоговое окно создания правила. Заполните поля в соответствии со скриншотом ниже.
Пояснение по шагам:
...
После заполнения полей нажмите кнопку "Создать". Созданное правило будет отображено в таблице правил. Таким образом, как только какое-либо устройство типа WLC отправит в СУ Syslog-сообщение с информацией о разрегистрации точки доступа, будет создано wireless событие, которое система обработает в соответствии с созданным правилом генерации событий и создаст соответствующее системное событие.
Создание правила генерации событий на основе событий обнаружения
Событие при извлечении модуля маршрутизации из корзины ME
Задача: создать правило генерации события для случая, когда на устройствах типа ME перестал обнаруживаться модуль маршрутизации. При срабатывании такого правила будет создано системное событие "Утерян модуль маршрутизации".
Для создания правила генерации событий перейдите на страницу "Настройки" → "Мониторинг" → "Правила генерации событий" и нажмите кнопку "Создать". Откроется диалоговое окно создания правила. Заполните поля в соответствии со скриншотом ниже.
Пояснение по шагам:
- "Название правила" и его "Важность" — выбираются в зависимости от критичности события на вашей сети;
- "Включить правило" — активировано. Обеспечивает активацию правила генерации события сразу после его создания;
- "Шаблон события" — текстовый шаблон, согласно которому будет создаваться описание соответствующего события;
- Тип данных:
- "Тип устройства" — ME. Выбирается тип устройств, для которых может применяться данное правило;
- "Тип данных" — Событие обнаружения;
- "Элемент данных" — "Module discovery: Module".
- Область применения:
- "Область применения" — группа "eccm". Обеспечивает работу правила по всем группам в системе (т. к. группа eccm — корневая группа);
- Описание элемента данных — содержит описание выбранного элемента данных и такую информацию, как свойства, возможные принимаемые значения, тип данных, которые в нем ожидаются, и описание;
Условия генерации событий:
"Групповое условие" — "И". Логическая операция, применяемая к условиям в группе условий. Устанавливает правило создания события только при достижении обоих условий;
Первое условие — определяем тип модуля устройства, состояние которого будет анализироваться системой:
"Элемент данных" — "Property: [current]module.object.property.type";
"Функция сравнения" для первого условия — "Равно";
"Пороговое значение" — Указать константу;
"Константа" — "FMC".
Второе условие — задаем состояние обнаружение модуля, которое будет являться триггером для создания события:
"Элемент данных" — "state";
"Функция сравнения" для второго условия — "Равно";
"Пороговое значение" — Указать константу;
"Константа" — "ENTITY LOSS". Состояние, которое обозначает, что при очередном опросе устройства ранее обнаруживаемый модуль, больше не обнаруживается. Такой модуль считается в системе "Утерянным".
После заполнения полей нажмите кнопку "Создать". Созданное правило будет отображено в таблице правил. Таким образом, как только какой-либо модуль маршрутизации устройства типа ME перейдет в состояние "Утерян" (перестанет обнаруживаться), система обработает данное событие обнаружения в соответствии с созданным правилом генерации событий и создаст соответствующее системное событие.