Как создать проблему с zabbix, когда интерфейс коммутатора cisco использует более 80 мбит / с (80% его пропускной способности)

Вы правы, вы хотите использовать низкоуровневое обнаружение для этого, а также для обнаружения всех ваших интерфейсов. Открытие низкого уровня на высоком уровне состоит из двух вещей. 1) вы должны указать zabbix, как открыть кучу динамических вещей и назначить им макрос LLD, что выполняется на высоком уровне правила обнаружения. 2) вы должны указать zabbix, какие прототипы элементов, прототипы триггеров и т.д. динамически создавать как фактические элементы и триггеры при каждом запуске правила обнаружения.

Взгляните на шаблон Arista SNMPv2, включенный в zabbix, в качестве примера. В этот шаблон включен ряд правил обнаружения, одним из которых является правило обнаружения сетевых интерфейсов. В правиле обнаружения сетевых интерфейсов zabbix в основном выполняет snmp-обход и получает список всех интерфейсов и назначает LLD (макросы низкоуровневого обнаружения) для каждого интерфейса, такого как #IFINDEX, #IFSTATUS и т. Д. Правило обнаружения, как и все LLD rules, берет выходные данные правила обнаружения «Сетевые интерфейсы» и использует их для динамического создания фактических элементов на каждом хосте, к которому применяется шаблон.

Следующая часть, которую нужно понять, - это прототипы. Как только zabbbix найдет все сетевые интерфейсы, у вас должен возникнуть вопрос, как мне заставить его создавать новые элементы на моем хосте для каждого найденного интерфейса и как заставить его создавать триггеры для каждого интерфейса, который он находит динамически, автоматически и без вмешательство пользователя. Ответ - протоиптес. Прототипы - это дочерние элементы низкоуровневого обнаружения. Они - то, что на самом деле создает новые предметы и триггеры для всего, что было обнаружено.

Здесь вы найдете несколько примеров и документацию по правилам низкоуровневого обнаружения. https://www.zabbix.com/documentation/4.2/manual/discovery/low_level_discovery#trigger_prototypes

Zabbix может создавать правила LLD с помощью множества методов обнаружения, включая SNMPv #, который можно настроить в пользовательском интерфейсе или API, а также другие правила обнаружения клиентов, не включенные посредством использования парматеров пользователей, внешних проверок и т. Д.

Если ваша марка и модель коммутатора уже известны zabbix, шаблон в «Шаблоны / Сетевые устройства», по крайней мере, я думаю, что это путь, будет существовать точно так же, как и arista и juniper.

Вы также можете создавать собственные правила низкоуровневого обнаружения для материалов, не относящихся к snmp. в основном вы пишете скрипт, который будет искать то, что вы хотите динамически добавлять в zabbix, и ваш скрипт должен возвращать действительный вывод json с #macronames и значениями, которые вы хотите добавить. Например, настраиваемые правила обнаружения файловой системы, которые не нужны, потому что они уже включены, если вы используете агент, будут создавать строки, подобные тем, которые показаны в этом примере в официальной документации. https://www.zabbix.com/documentation/4.2/manual/discovery/low_level_discovery#creating_custom_lld_rules

Короче говоря, проверьте, существует ли уже шаблон для вашего коммутатора и правило обнаружения с прототипами элементов, чтобы обнаруживать вещи так, как вы их уже хотите. LLD в основном позволяет zabbix перемещаться по динамической структуре данных любого источника, если эта структура данных имеет определение, известное zabbix, и вы сообщаете ему, какие ключи и значения в JSON вы хотите создать как элементы, триггеры и т. Д.

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

После стандартной настройки у вас должен быть «Шаблонный модуль интерфейсов SNMPv2», который используется некоторыми другими шаблонами в качестве стандарта для обнаружения интерфейсов.

В шаблоне вы найдете правило обнаружения «Обнаружение сетевых интерфейсов», которое запускается каждый час, чтобы:

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

Параметр скорости - это согласованная скорость интерфейса (например: 1000 для порта гигабитного коммутатора), что является вашим 100% -ным пределом.

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

• Создайте прототип элемента рассчитанного и задайте для его формулы значение 100*(currentOutputBits/speed)

• Создайте макрос шаблона для определения порога оповещения, например {$INTERFACE_OUTPUT_THRESHOLD}, и установите его на 80.

• Создайте прототип триггера, который соответствует, когда вычисляемый элемент больше {$INTERFACE_OUTPUT_THRESHOLD} в течение N минут.

• При желании сделайте то же самое для элемента currentInputBits

Эта настройка создаст 1 дополнительный элемент и 1 дополнительный триггер для каждого физического или логического интерфейса, обнаруженного на целевом устройстве: имеет смысл снять отметку с опции «create enable» в прототипе триггера и включить ее только на определенных портах определенных устройств.

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

Спасибо за ваши ответы, я еще раз проверил интерфейсы модулей шаблонов SNMPv2 и увидел, что существует триггер-прототип, который решает мой вопрос.

для всех, кто хочет сделать то же самое с переключателем:

1. Добавьте к своему коммутатору (хосту) шаблон «Шаблон интерфейса модуля SNMPv2».

2. Измените макрос IF_UTIL_MAX на любое значение, которое вы хотите, по умолчанию - 90 (это макрос, который отвечает за процент полосы пропускания, который вызовет проблему, например, если вы измените его на 60, когда хост загрузка полосы пропускания в среднем превышает 60% в любом интерфейсе в течение 15 минут, проблема будет добавлена ​​на вкладку проблем или на панель управления).

3. Если время 15 минут вам не подходит, вы можете изменить его, перейдя в: конфигурация -> шаблоны -> Интерфейсы модуля шаблона SNMPv2 -> Правила обнаружения -> Обнаружение сетевых интерфейсов -> Прототипы триггеров -> поиск триггера имя, которое содержит использование высокой пропускной способности -> в выражении проблемы и выражении восстановления найдите функцию .avg () и измените значение внутри нее на любое значение, подходящее для вас, например: 15 мин. = 15 минут, 1 с = 1 секунда и т.д...

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

3. Нажмите «Добавить» в нижнем левом углу экрана, и, если вы последовали моему совету, вам также необходимо щелкнуть зеленую ссылку «Да» встроенного триггера в таблице прототипов триггеров, чтобы его отключить.

Вы также можете попробовать другие ответы в этой теме, я очень благодарен за них, но у меня нет времени, чтобы проверить, работают ли они, поскольку я уже понял это, прочитав ответы Симоне Забберони и helllordkb и проверив встроено в низкоуровневое обнаружение в шаблоне "Template Module Interfaces SNMPv2".