Discovery rule как Dependent Item? Для чего?

[Wadim_Sch]

Добрый день!
Собственно предыстория:
У нас мониторится большое количество коммутаторов ArubaOC-CX. Все шаблоны для них я когда-то делал сам, основываясь на шаблонах для других вендоров и выискивая в интернете довольно скудную информацию о MIB/OID для устройств HP-Aruba. Как известно нет предела совершенству и я переодически обновляю шаблоны при появлении новой информации. Не так давно на сайте Zabbix был опубликован шаблон для коммутаторов Aruba CX серии 8300 https://www.zabbix.com/integrations/aruba. Шаблон доступен для версии Zabbix 7.4 и 7.0. Я решил его посмотреть на предмет каких-нибудь "полезностей" которые я могу в свои шаблоны взять. Я смотрел версию 7.0 так как версия нашего Zabbix-a 7.2. Действительно нашлись некоторые полезные вещи. Но возник вопрос по-поводу конструкции самого шаблона, вернее конфигурации правил обнаружения.
Есть Item:


К этому Item-у в "правилах обнаружения" привязано правило как "Dependent Item"

Собственно вопрос для чего это сделано и даёт ли это какие-то преимущества по-сравнению с "обычными" правилами обнаружения? Синтаксис правила обнаружения walk[1.3.6....] я знаю и пользуюсь. Интересует именно привязка Discovery rule -- Dependent Item. Я такого раньше не вcтречал. Может быть это какой-то новый синтаксис доступный с какой-нибудь версии?
Вдруг это очень полезная вешь, а я ей не пользуюсь.

[ysus]

https://blog.zabbix.com/improving-sn...lection/27231/

[Kos]

Собственно вопрос для чего это сделано и даёт ли это какие-то преимущества по-сравнению с "обычными" правилами обнаружения? Синтаксис правила обнаружения walk[1.3.6....] я знаю и пользуюсь. Интересует именно привязка Discovery rule -- Dependent Item. Я такого раньше не вcтречал. Может быть это какой-то новый синтаксис доступный с какой-нибудь версии?
Вдруг это очень полезная вешь, а я ей не пользуюсь.

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

[ahauras]

Т.е. получается эффективнее (меньше нагружается сеть и само устройство).

Поправьте меня, если я ошибаюсь, но этот способ менее стабилен.
Например, устройство по walk отдает много (до пары тысяч) oid (пример - d-link des3200-xx, eltex mes2124/2324 с большим количеством vlan - каждый vlan отображается как "физический" интерфейс), переполняя поле text в БД (которое судя по всему ограничено 65kb). Таким образом в поле БД получается некорректная информация и парсер зависимого правила о нее спотыкается.
Учитывая, что нет никакого способа задать range или остановить встроенный walk после какого-то количества значений, то тут требуется доработка.
Например мне пришлось написать bulk get скрипт с диапазоном значений, имитирующий bulk walk, чтобы зависимые items работали корректно.

[Kos]

Поправьте меня, если я ошибаюсь, но этот способ менее стабилен.
Например, устройство по walk отдает много (до пары тысяч) oid (пример - d-link des3200-xx, eltex mes2124/2324 с большим количеством vlan - каждый vlan отображается как "физический" интерфейс), переполняя поле text в БД (которое судя по всему ограничено 65kb). Таким образом в поле БД получается некорректная информация и парсер зависимого правила о нее спотыкается.
Учитывая, что нет никакого способа задать range или остановить встроенный walk после какого-то количества значений, то тут требуется доработка.
Например мне пришлось написать bulk get скрипт с диапазоном значений, имитирующий bulk walk, чтобы зависимые items работали корректно.

Теоретически - Вы правы.
На практике - сервер разбирает принятую "простыню" данных на зависимые элементы данных ещё до того, как записывает эту "простыню" в базу данных. Более того, её и сохранять-то в базе данных нет необходимости, разве что на этапе отладки своего шаблона (чтобы видеть, что туда попадает); поэтому для таких элементов данных, как правило, указывается опция без сохранения истории.
Исключение - это работа через Zabbix прокси (64 kB либо 65536 символов в зависимости от базы данных, ссылка).

[Wadim_Sch]

В случае с "Discovery rule" как "Dependent Item" не удается установить интервал опроса для каждого прототипа Item. Если конечно я всё правильно понял.
На примере вентиляторов коммутатора Aruba (Всего их 12 но я сократил для удобочитаемости):

1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.4.1.1.1 = STRING: "Tray-1/1/1" -- Имя
1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.4.1.6.2 = STRING: "Tray-1/6/2"

1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.5.1.1.1 = STRING: "ok" -- Статус (текст)
1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.5.1.6.2 = STRING: "ok"

1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.6.1.1.1 = STRING: "JL630A" -- Номер модели
1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.6.1.6.2 = STRING: "JL630A"

1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.8.1.1.1 = INTEGER: 11700 -- Speed (RPM)
1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.8.1.6.2 = INTEGER: 10000

1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.9.1.1.1 = STRING: "f2b" -- Направление воздуха (Front-to-Back)
1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.9.1.6.2 = STRING: "f2b"

1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.10.1.1.1 = INTEGER: 4 -- Статус (код.) 4 - OK
1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.10.1.6.2 = INTEGER: 4

Как у меня настроено.
Один раз в час Zabbix делает Discovery и ищет новые вентиляторы (имена и #SNMPINDEX-ы) здесь: 1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.4 , формируя на основе полученных данных прототипы Item-ов для каждого блоко OID кроме "Статус (текст)".
Далее важные параметры Speed (RPM) и Статус (код) считывались Zabbix-oм 1 раз в 5 минут. A неважные параметры (инвентарные) "Номер модели", "Направление воздуха" считывались 1 раз в 12 часов.
Для новой Discovery (walk[...]) мне придется считывать весь блок относящийся к вентиляторам: 1.3.6.1.4.1.47196.4.1.1.3.11.5.1.1.
Можно конечно создать два элемента. Один для "важных данных" c часторой опроса в Discovery walk[...] 1 раз в 5 минут и второй дла "инвентарных данных" 1 раз в 12 часов.
А можно считывать все данные 1 раз в 5 минут, данных не так уж и много и считывать надо не так часто.Далее в предобработке каждого Item-a можно применить функцию "Discard unchanged with heartbeat" (о которой я раньше не знал) чтобы сократить количество записей в базе данных Zabbix:


Но вот как быть с интерфейсами? Некоторые коммутаторы имеют порядка 250 портов. Точно также раз в 1 час Zabbix делает Discovery и ищет новые (при этом активные порты). Но сейчас Zabbix в Discovery опрашивает только
{#IFNAME} - 1.3.6.1.2.1.2.2.1.2
{#IFALIAS} - 1.3.6.1.2.1.31.1.1.1.18
{#IFOPERSTATUS} - 1.3.6.1.2.1.2.2.1.8
{#IFADMINSTATUS} - 1.3.6.1.2.1.2.2.1.7
Получаются Item-ы с такими интервалами опроса:



Также у меня настроены такие триггеры (зависящие от частоты опроса):
В случае с "Discovery rule" как "Dependent Item", логику для триггеров можно придумать и другую, с другими функциями. Но теперь в Discovery в команде walk[...] мне нужно будет опрашивать каждую минуту следующие OIDs:

1.3.6.1.2.1.2.2.1.8 ifOperStatus
1.3.6.1.2.1.2.2.1.7 ifAdminStatus
1.3.6.1.2.1.31.1.1.1.18 ifAlias
1.3.6.1.2.1.2.2.1.2 ifDescr
1.3.6.1.2.1.2.2.1.10 ifInOctets
1.3.6.1.2.1.2.2.1.16 ifOutOctets
1.3.6.1.2.1.2.2.1.14 ifInErrors
1.3.6.1.2.1.2.2.1.20 ifOutErrors
1.3.6.1.2.1.2.2.1.19 ifOutDiscards
1.3.6.1.2.1.2.2.1.13 ifInDiscards
1.3.6.1.2.1.2.2.1.5 ifSpeed

A это 2500-3500 тысячи строк (некоторые свитчи имеют дополнительные "внутренние" интерфейсы, которые нужно отфильтровать). Выглядет как-то устрашающе .
Особенно для старого виртуального шасси Juniper (порядка 300 портов) состоящее из нескольких старых коммутаторов, которое даже с нынешними настройками Discovery не с первого раза создает Items для всех портов и бывает (редко) что теряет (не отдает) некоторое данные. Как я почитал, что для новой формы записи Discovery (walk[...]) Zabbix использует snmpwalkbulk вместо snmpwalk и вроде бы это эффективнее. Но что-то гложат смутные сомнения...

[ahauras]

A это 2500-3500 тысячи строк (некоторые свитчи имеют дополнительные "внутренние" интерфейсы, которые нужно отфильтровать). Выглядет как-то устрашающе .
Особенно для старого виртуального шасси Juniper (порядка 300 портов) состоящее из нескольких старых коммутаторов, которое даже с нынешними настройками Discovery не с первого раза создает Items для всех портов и бывает (редко) что теряет (не отдает) некоторое данные. Как я почитал, что для новой формы записи Discovery (walk[...]) Zabbix использует snmpwalkbulk вместо snmpwalk и вроде бы это эффективнее. Но что-то гложат смутные сомнения...

snmpbulkwalk напряжнее для свича в N раз (N=bulk size) ведь ему надо у себя внутри одновременно 30 пакетов с данными подготовить (гораздо сильнее на CPU).
в случае со старым walk следующий item мы запросим только когда придет ответ, и соответственно, ответы приходят позже, если CPU у устройства плохее, тем самым нагрузку размазывая.
Это еще ничего.
Меня пугает принципиальная невозможность ограничить общий walk size (это кстати и в оригинальном net-snmp нет). То есть если нам выдадут 10к OID, то надо их будет всех читать и в базы класть, хотя нас например изначально интересуют только *.1-100 и *.500-600.
Но нет, это возможно только с get, но не с walk. Жаль, что штатной возможности в zabbix такой нет (get можно сделать только для одного oid, а у walk нет ограничителя итераций).
feature request на bulk get с range и ограничение общего размера walk были бы кстати. Работы не сильно много казалось-бы, get множественных OID это как-бы стандартная фича snmpv2.

[Kos]

Wadim_Sch , всё верно.

• новый механизм вполне нормально подойдёт для мониторинга, скажем, ваших 12 вентиляторов. Опросить их все раз в 5 минут, убедиться, что для некоторых параметров (вроде модели, направления воздуха и статуса) ничего не поменялось - и выкинуть собранные значения, а остальные записать в базу - это нормально. Один snmpwalk-запрос, возвращающий по 12 значений из 6 таблиц, будет эффективнее, чем 72 раза запрашивать по одному значению плюс один раз опросить несколько таблиц для дискаверинга. Да, в случае номера модели будет некоторая избыточность (их необязательно опрашивать так часто); но, скажем в случае статуса сочетание относительно частого опроса с троттлингом вполне оправдывает себя (если состояние не меняется, то в базу лишнего не пишем, зато если изменилось - то замечаем сразу).
• это не означает, однако, что этот механизм нужно бездумно применять вообще везде. Я понимаю, что человеку, имеющему в руках молоток, всё вокруг кажется гвоздями, но нужно искать разумный компромисс. Скажем, у нас тоже есть свитчи с большим количеством сетевых интерфейсов (несколько сотен), из которых мониторить реально нужно совсем немного (пару десятков - аплинки, агрегаты, супер-важные серверы и т.п.). Тут нет смысла использовать эту технологию - вполне достаточно старого традиционного механизма с обнаружением раз в час на основе нескольких таблиц и обычного SNMP опроса. Но даже в этом случае мы перешли на использование ключевого слова "get[...]" в поле OID, а не просто голого OID'а (подкорректировали все прототипы в шаблоне) - тогда (начиная с Zabbix v7.0.x) используется асинхронный SNMP-поллер.

[ahauras]

Но даже в этом случае мы перешли на использование ключевого слова "get[...]" в поле OID, а не просто голого OID'а (подкорректировали все прототипы в шаблоне) - тогда (начиная с Zabbix v7.0.x) используется асинхронный SNMP-поллер.

Если вы его используете, можете ли рассказать, как добились от него агрегации нескольких запросов get в один? Я создавал соседнюю тему (https://www.zabbix.com/forum/in-russ...80%D0%BE%D1%81), но никто не ответил.
До zabbix пользовался другим мониторингом с getbulk и как-то не могу понять, что мне нужно сделать, чтобы работало также? Т.е. чтобы все эти get в рамках одного хоста (или хотя бы одного шаблона) запрашивались одним пакетом из нескольких OID вместо отдельного пакета на каждый OID (как описано в руководстве). Poll interval у них одинаковый, но чуда не происходит и с get[] и со старым способом. Может прокси не поддерживает это? Хотя не нашел об этом упоминаний в инструкциях.

[Kos]

Если вы его используете, можете ли рассказать, как добились от него агрегации нескольких запросов get в один?

Я про агрегацию ничего не говорил, я писал про то, что опрос делается другим процессом - асинхронным поллером, что само по себе эффективнее: один асинхронный поллер по умолчанию выполняет до 1000 запросов параллельно - фактически, в одиночку выполняя работу, которая раньше выполнялась десятками синхронных поллеров.
Параллельную тему гляну, проверю у себя.

[Wadim_Sch]

Kos
Ну собственно я так и решил. Новым инструментом пользоваться для маленьких таблиц. А вот для портов оставлю "стырый" механизм. Нужно попробовать ещё "get[...]" добавить. Просто в преведенной выше статье https://blog.zabbix.com/improving-sn...lection/27231/ описан новый инструмент на примене как раз таки портов коммутатора. Поэтому у меня и возникли вопросы. Просто не всё, что хорошо для сервера Zabbix, также хорошо для отслежываемых им устройств. Некоторые механизмы могут сильно загрузить опрашиваемое устройство.
Для меня важно отслеживать на коммутаторах все активные порты, так как в датацентре за каждым портом коммутатора находится сервер, firewall или другое сетевое оборудование (всё это может быть свое и клиентское).

Для "офисных" коммутаторов, за портами которых находятся компьютеры пользователей и принтеры, шаблон для отслеживания портов попроще. Там выключен триггер реагирующий на ifOperStatus для физических портов (для агрегированных, а это Uplink-и, триггер есть), но ifOperStatus всё же отслеживается. Не отслеживаются ifOutDiscards, ifInDiscards. Но отслеживаются физические ошибки на интерфейсах: ifInErrors, ifOutErrors . Так же отслеживается сетевой трафик ifInOctets, ifOutOctets, но не так часто как для датацентра. Всё это помогает вовремя увидеть проблемы в сети: то пользователи кабель передавят или надорвут и возникает куча ошибок ifInErrors, ifOutErrors либо бывает устройство пользователя соединяется с коммутатором на 10Mbit/s тогда срабатывает триггер что долгое время высокий трафик на порте (больше 90% от ifSpeed).

[Kos]

Wadim_Sch, полностью присоединяюсь к вашему мнению - у нас настроено подобным же образом.
Могу только добавить, что полезен триггер на уменьшение скорости работы интерфейса (например, устройство работало на гигабите, а потом переключилось на сотку - повод насторожиться). Кстати, этот же триггер эффективно отлавливает и ситуации, когда отключается один из портов агрегата - сам агрегированный интерфейс при этом остаётся поднят, но его скорость падает вдвое.
Да, в качестве параметра ключа в прототипе элемента данных лучше использовать не индекс (LLD-макрос {#SNMPINDEX}), а, например, имя интерфейса ({#IFALIAS}, {#IFNAME} или что-то подобное). Потому как при изменении конфигурации (аппаратной - воткнули другой модуль, или программной - настроили ещё один агрегат или VLAN) нумерация индексов может поменяться, и потом может потеряться история по каким-то портам и/или "поехать" ссылки на конкретные порты в виджетах (например, на картах сети).

Ну, ещё у нас на этажных свитчах используется POE (например, для запитывания IP-телефонов), поэтому в шаблон для этажных свитчей добавлен ещё мониторинг состояния POE (ругаемся, если adminStatus активный, а текущий статус поменялся с "deliveringPower" на что-то другое). Там, правда, не так удобно, потому что используется другой набор таблиц со своими индексами, которые никак не связаны с привычными именами интерфейсов.

[Wadim_Sch]

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

Хм... А это не плохая идея, я о таком не догадался.
На коммутаторах-Juniper есть возможность отслеживать LACP-Status физических портов входящих в агрегированный инрерфейс. А вот у Aruba LACP-Status можно только в cli посмотреть, а через SNMP этот параметр получить нельзя. Ваш способ для локальной сети (когда коммутаторы соединены напрямую кабелями) очень даже подойдет.
Но если между коммутаторами стоит оборудование провайдера или скажем глупые медиаконверторы то такой способ может не сработь. То есть в сети провайдера что-то произошло (или порвался кабель между медиаконверторами) , то не всегда провайдерское оборудование посылает клиентские порты в DOWN. Фактически на наших коммутаторах порты в UP, а связи нет. Почему нет, можно понять только через LACP-Status, ну ещё по LLDP, CDP.
Не уверен, что в этом случае меняется параметр ifSpeed, надо протестить.

Я кстати хотел везде для опроса интерфейсов поставить get[...]. Но не тут-то было. Лучше в новой теме спрошу.

[Wadim_Sch]

Возвращаюсь к теме.
Я сделал новые шаблоны для коммутаторов Aruba. Они построены на таком же принципе как описано в самом первом сообщении этой темы. То есть есть Item с walk[...], правило обнаружения привязано к этому Item-у как Dependent Item, и в правиле уже настроены прототипы Item-ов и триггеров. При тестировании было все хорошо (тут конечно может быть я не заметил). При введении этих новых шаблонов в эксплуатацию заметил большое количество ошибок в Discovery Rules хостов. Ошибки не постоянные, они могут появиться и при следующем опросе уйти. Возникают на коммутаторах как удаленных, так и находящихся в одной серверной с сервером Zabbix. Ошибки возникают в разных правилах обнаружения, то есть таблици которые опрашивают эти правила абсолютно разные, но все не большие, несколько десятков строк.
Ошибки виглядят так:


Probe successful, only partial data received, cannot retrieve OID: '.1.3.6.1.2.1.31.1.1.1.18.268435456' from [[IP-Address]:161]: timed out
Probe successful, only partial data received, cannot retrieve OID: '.1.3.6.1.2.1.2.2.1.7.40' from [[IP-Address]:161]: timed out
Probe successful, only partial data received, cannot retrieve OID: '.1.3.6.1.2.1.2.2.1.8.10' from [[IP-Address]:161]: timed out
Probe successful, only partial data received, cannot retrieve OID: '.1.3.6.1.2.1.2.2.1.7.30' from [[IP-Address]:161]: timed out
Probe successful, only partial data received, cannot retrieve OID: '.1.3.6.1.4.1.47196.4.1.1.3.11.6.1.1.11.10.4.10' from [[IP-Address]:161]: timed out
Probe successful, only partial data received, cannot retrieve OID: '.1.3.6.1.4.1.47196.4.1.1.3.11.3.1.1.8.1.5.1.8' from [[IP-Address]:161]: timed out

Как я понимаю коммутаторы по запросу walk[...] не каждый раз успевают отдать все данные.
Что делать? Увеличить time-out для правил или перейти на "классические" правила обнаружения? Может быть ещё что-то...

[Kos]

Как я понимаю коммутаторы по запросу walk[...] не каждый раз успевают отдать все данные.
Что делать? Увеличить time-out для правил или перейти на "классические" правила обнаружения? Может быть ещё что-то...

Ну, увеличение тайм-аутов для правил обнаружения - это первое, что напрашивается (я бы с этого и начал). Тем более, что, начиная с версии Zabbix 7.0.x, теперь можно задавать тайм-ауты для различных параметров независимо друг от друга (т.е. больше нет необходимости крутить глобальные тайм-ауты на уровне целого сервера или прокси).
Немного увеличить тайм-аут прямо в шаблоне для правила обнаружения - и посмотреть, как поменяется ситуация.