"Плавающая" проблема с snmp, прошу помощи.

[Tenchi Masaki]

Приветствую!
Установлен Zabbix 2.2.3, настроен мониториг по SNMP машин с линуксом, виндой и микротиком. Периодически на микротик оно ругается:

[test_mikrot_snmp:.1.3.6.1.2.1.2.2.1.7.["2"]] became not supported: SNMP error: (noSuchName) There is no such variable name in this MIB.

Затем через рандомное время получает значение нормально, в логах соответственно

[test_mikrot_snmp:.1.3.6.1.2.1.2.2.1.7.["2"]] became supported

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

[romale]

1вариант. Для верности попробуй по крону сделать опрос через snmpget по тому же интервалу опроса что в заббиксе и посмотри результат.
2вариант. в заббиксе увеличить интервал опроса items.

[Egor4ik]

Zabbix 2.2.4 SNMP + Mikrotik

Подтверждается проблема именно с Mikrotik-ами. В мониторинге заведено около 70 Mikrotik различных версий, и столько же Windows + Linux которые мониторятся по SNMP.

Проблема с потерей (UNSUPPORTED) элементов проявляется только на девайсах Mikrotik:

....
 26725:20140715:093606.221 error reason for "____ MKT HQ:ifAlias["ether4-to-ARGO(4)"]" changed: "SNMP error: (noSuchName) There is no such variable name in this MIB."
......
......
 26725:20140715:094554.218 item "____ MKT HQ:ifAlias["ether4-to-ARGO(4)"]" became supported
...

Данные собираются успешно тогда, когда элемент поддерживается (SUPPORTED).

Анализируя пакеты от Proxy-Zabbix получается что проблема не в самом сервере Zabbix, а в том что приходит от Mikrotik. Учитывая изменившуюся технику сбора данных в версии Zabbix 2.2+, следует полагать что проблема в том что RouterOS так не умеет работать с SNMP.

Посему вопрос в том, как изменить мониторинг Mikrotik, чтобы не слетали элементы.

Например, такой метод сбора пробовал кто нибудь: Dynamic Indexes ?

[aklim007]

Например, такой метод сбора пробовал кто нибудь: dynamic indexes ?

да на цисках интерфейсы таким образом мониторим, никаких проблем.

[Egor4ik]

да на цисках интерфейсы таким образом мониторим, никаких проблем.

Судя по багтрекеру-2301 циски должны быть подвержены багу:

2. Cisco device is sometimes returning "noSuchInstance" for variables that are thought to exist (ZBX-8096);

Мои наблюдения за сегодняшний день:

• Патч из багтреккера не проверял
• Никакие галочки в интерфейсах устройств до сих пор не внедрены для отключения Bulk SNMP (v2.2.2, v2.2.4)
• Во время опроса тестового Mikrotik загрузка его процессора упирается в "потолок" на 1 сек, при том, что девайс вообще не используется в работе.

Что же, чёрт-побери, делать!!!??? Варианты решения проблемы остаются только "костыльные"....

[aib]

Как вариант можно предложить поставить разный интервал опроса для каждого элемента.
вручную
чтобы не получалось так, что Zabbix сможет собрать два SNMP Запроса в один и послать, как один.

да, костыль...а кому сейчас легко?

[Egor4ik]

Как вариант можно предложить поставить разный интервал опроса для каждого элемента.
вручную
чтобы не получалось так, что Zabbix сможет собрать два SNMP Запроса в один и послать, как один.

да, костыль...а кому сейчас легко?

На самых простых Mikrotik это ещё подойдёт, но на больших бортах, где по 40-80 интерфейсов + их статусы + их алиасы + дескрипшены....

[Egor4ik]

Как вариант можно предложить поставить разный интервал опроса для каждого элемента.
вручную
чтобы не получалось так, что Zabbix сможет собрать два SNMP Запроса в один и послать, как один.

да, костыль...а кому сейчас легко?

Хотя, чёрт с ним, это только выглядит как костыль, но если используется шаблон, то это всего то изменить 1 раз...

Отсюда возникает вопрос - есть ли разница в интервалах 55 сек, 57сек, 58 сек, 59 сек - какая скважность отправки запросов на самом деле у Zabbix?
Есть ли смысл использовать такие значения?

[Jimson]

На сколько я понимаю при запуске сервер ставит все элементы данных в очередь с рандомным таймером от 1с до интервала обновления. Так что все это натуральные танцы с бубном, рано или поздно часть элементов данных все равно "сольется в экстазе", разный интервал будет их разводить опять, а затем другие элементы опять сойдутся и так оно и будет туда-сюда.

[Egor4ik]

Как вариант можно предложить поставить разный интервал опроса для каждого элемента.
вручную
чтобы не получалось так, что Zabbix сможет собрать два SNMP Запроса в один и послать, как один.

да, костыль...а кому сейчас легко?

Такой спосом помог решить проблему с мониторингом Mikrotik.
Количество UNSUPPORTED элементов колебалось от 1800 до 2100, но после того как для девайсов Mikrotik был отделён шаблон, а Interval опроса элементов был изменён для каждого элемента какой то уникальный, то UNSUPPORTED элементы пропали (естественно кроме тех которые на самом деле не поддерживаются).

Резюме:

• Использование SNMPv1 положительного результата не дало
• Метод Динамических Индексов так же не дал положительного результата
• На больших бортах Mikrotik, где куча интерфейсов, бриджей и прочего, периодически появляется проблема (RB1100).

Решение:
Использование максимально не совпадающих Interval параметров для мониторинга Mikrotik.

[Egor4ik]

На сколько я понимаю при запуске сервер ставит все элементы данных в очередь с рандомным таймером от 1с до интервала обновления. Так что все это натуральные танцы с бубном, рано или поздно часть элементов данных все равно "сольется в экстазе", разный интервал будет их разводить опять, а затем другие элементы опять сойдутся и так оно и будет туда-сюда.

Может быть мне везёт... но уже 12 часов практиески ни одного потерянного элемента.

Возможно, стоит добавить, что кроме этих "танцев с interval" я оставил Zabbix-proxy v.2.2.2.

[Zentarim]

Насколько я помню в версии 2.2.2 bulk_get еще не используется, так что все логично

[Egor4ik]

Насколько я помню в версии 2.2.2 bulk_get еще не используется, так что все логично

Не соглашусь с этой логичностью...
Обосную это следующим образом: даунгрейд до v.2.2.2 я выполнил в 15.июля 13:23. Однако, результата это не дало. Чтобы не быть голословным вот пожалуйста:

root@zabbix:/var/log/zabbix# grep "SNMP error: (noSuchName) There is no such variable name in this MIB." zabbix_server.log|grep -E "20140715:1[34567]"|wc -l
1235

И за сегодня:

grep "SNMP error: (noSuchName) There is no such variable name in this MIB." zabbix_server.log|grep -E "20140716:"|wc -l
0

Возврат к прежней версии я не сделал, оставив 2.2.2. И после совета раскидать interval по времени, я это и сделал. И последнее упоминание в логах о проблеме (после этого до сих пор не появляется):

 48121:20140715:170413.690 error reason for "______ MKT:ifAlias["ether5(5)"]" changed: "SNMP error: (noSuchName) There is no such variable name in this MIB."
 48121:20140715:170413.690 error reason for "______ MKT:ifAlias["bridge1(7)"]" changed: "SNMP error: (noSuchName) There is no such variable name in this MIB."
 48121:20140715:170413.690 error reason for "______ MKT:ifAlias["pptp-in1(27)"]" changed: "SNMP error: (noSuchName) There is no such variable name in this MIB."

[Egor4ik]

Насколько я помню в версии 2.2.2 bulk_get еще не используется, так что все логично

Беру назад свои слова про нелогичность ))

Таки проблема решилась именно даунгрейдом Zabbix-Proxy до 2.2.2, при этом сервер работает на 2.2.4

Короче говоря, я позволил себе запутатся в собственной сети Zabbix, которая состоит из 10 Proxy и 1 сервера.

[Zentarim]

Беру назад свои слова про нелогичность ))

Таки проблема решилась именно даунгрейдом zabbix-proxy до 2.2.2, при этом сервер работает на 2.2.4

Короче говоря, я позволил себе запутатся в собственной сети zabbix, которая состоит из 10 proxy и 1 сервера.

Как очередной раз выяснилось - чудес не бывает Хорошо, что все заработало.