Приветствую. Подскажите решение с проблемой обнаружения и авторегистрации через snmp. Прописал события обнаружения и авторегистрации , операции прописаны на добавление узлов, но узлов новых так и нет, хотя вручную все добавляются. Может еще что прописать надо ? Если нужно какие-то данные указать, укажите какие. Спасибо
Ad Widget
Collapse
авторегистрация узлов. Snmp
Collapse
X
-
-
Здравствуйте,Приветствую. Подскажите решение с проблемой обнаружения и авторегистрации через snmp. Прописал события обнаружения и авторегистрации , операции прописаны на добавление узлов, но узлов новых так и нет, хотя вручную все добавляются. Может еще что прописать надо ? Если нужно какие-то данные указать, укажите какие. Спасибо
А как Вы настроили? Что прописали? -
Comment
-
Вот так сделал + прикладываю то, что попробовал в действиях прописатьздравствуйте!
проблем с обнаружением по snmp не наблюдается. все четко обнаруживается и добавляется. вопрос: каким образом вы пытаетесь организовывать поиск и по каким критериям добавляете?
далее, по инструкции, что с обнаруженным объектом делать, описывается в действиях.Comment
-
В списке обнаруженных устройств есть что-нибудь? В веб-интерфейсе 'Мониторинг'->'Обнаружение'? Если ничего нет, то стоит проверить доступность перечисленных сетей Zabbix серверу, в том числе, ответ по SNMP. Проверить можно с помощью snmpwalk или nmap.
Comment
-
Хммм. Думаю вопрос будет к переменной {#SNMPINDEX}. Вернее, ее как раз не будет. Этот пробер работает как snmpget по конечному oid. И если snmpget вам на 1.3.6.1.2.1.2.2.1.3 не выдаст ничего конкретного(а он не выдаст, если интерфейсов более чем 1) то и устройство обнаружено не будет.
snmpget 192.168.254.35 1.3.6.1.2.1.2.2.1.3
IF-MIB::ifType = No Such Instance currently exists at this OID
Советую обнаружение делать из ветки system:
Например по SysDescr( 1.3.6.1.2.1.1.1.0 = STRING: SNR-S2965-24T Device, Compiled Sep 08 15:13:38 2016
) или SysName(1.3.6.1.2.1.1.5.0).Comment
-
Один, уже давно добавленный, узел.Comment
-
Правильно я понял что в проверках в OID нужно указать "SysName(1.3.6.1.2.1.1.5.0)" ?Хммм. Думаю вопрос будет к переменной {#SNMPINDEX}. Вернее, ее как раз не будет. Этот пробер работает как snmpget по конечному oid. И если snmpget вам на 1.3.6.1.2.1.2.2.1.3 не выдаст ничего конкретного(а он не выдаст, если интерфейсов более чем 1) то и устройство обнаружено не будет.
snmpget 192.168.254.35 1.3.6.1.2.1.2.2.1.3
IF-MIB::ifType = No Such Instance currently exists at this OID
Советую обнаружение делать из ветки system:
Например по SysDescr( 1.3.6.1.2.1.1.1.0 = STRING: SNR-S2965-24T Device, Compiled Sep 08 15:13:38 2016
) или SysName(1.3.6.1.2.1.1.5.0).Comment
-
Не обязательно. Нужно чтобы запрашиваемый OID существовал и возвращал какое-то значение. То есть необходимо, чтобы операция поиска, использующая в качестве зонда snmpget получала данные от устройства, а не молчание и не ошибку. Что в данном случае вы будете использовать - не имеет значения. Это может быть и первый порт устройства, то есть можем использовать ваш OID, но только с указанием конкретного индекса конкретного порта. Самое лучшее, на мой взгляд, это использовать ту ветвь SNMP, которая присутствует практически в 100 процентах железок, хоть как-то знакомых с SNMP. То есть system.
А вот если вы хотите использовать это значение еще и как критерий уникальности, то тогда берите SysName. Который в свою очередь может быть изменен в большинстве SNMP.
Comment
-
Сделал OID по sysDescr. Проверил snmpget по добавленному уже узлу, значение возвращает. Теперь вопрос как быть с обнаружением принтеров и коммутаторов? Их он не находитНе обязательно. Нужно чтобы запрашиваемый OID существовал и возвращал какое-то значение. То есть необходимо, чтобы операция поиска, использующая в качестве зонда snmpget получала данные от устройства, а не молчание и не ошибку. Что в данном случае вы будете использовать - не имеет значения. Это может быть и первый порт устройства, то есть можем использовать ваш OID, но только с указанием конкретного индекса конкретного порта. Самое лучшее, на мой взгляд, это использовать ту ветвь SNMP, которая присутствует практически в 100 процентах железок, хоть как-то знакомых с SNMP. То есть system.
А вот если вы хотите использовать это значение еще и как критерий уникальности, то тогда берите SysName. Который в свою очередь может быть изменен в большинстве SNMP.Comment
-
snmpget по НЕ добавленным узлам значения возвращает? Если да - то просто ждать какое-то время. Поиск не сильно быстро работает. Время - это период между запусками процессов поиска. И чем больше диапазоны поиска, тем больше должен быть период. Иначе новый процесс обнаружения начнет запускаться ранее чем старый доползет до конца диапазона.Comment
-
Проверил принтер snmpwalk и snmpget, все данные приходят, НО в zabbix уже часа 2 не приходит новых устройств, snmp на устройствах включены, комьюнити прописаны. Не понимаю в чем проблема. прикладываю на всякий случай скриныsnmpget по НЕ добавленным узлам значения возвращает? Если да - то просто ждать какое-то время. Поиск не сильно быстро работает. Время - это период между запусками процессов поиска. И чем больше диапазоны поиска, тем больше должен быть период. Иначе новый процесс обнаружения начнет запускаться ранее чем старый доползет до конца диапазона.Comment
-
Ну, для начала, советую выломать все SNMPv1 агенты. Если какое-то из устройств не ответит по v2 с ним разберетесь отдельно. Увеличьте интервал обновления минимум до часа. Иначе может превысить максимальное кол-во процессов обнаружения.
Порт сервиса из действий тоже можно выковырнуть, поскольку наверняка все устройства на SNMP порту по умолчанию. ip адрес узла сети тоже можно не указывать, если правило обнаружения одно.
Далее, что стоит в zabbix_server.conf в разделе:
### Option: StartDiscoverers
#<----->Number of pre-forked instances of discoverers.
#
# Mandatory: no
# Range: 0-250
# Default:
StartDiscoverers=?
Тоже существенный момент.
И последнее, если здесь не "0" - то посмотрите загрузку discoverer'а в графике zabbix data gathering process busy. Если он уперся в потолок, то и новых обнаружений не будет. Кстати, если поставить слишком короткий период и большой диапазон перебора, то произойдет тоже самое discoverer встанет.
Comment
-
SNMPv1 выпилил. И интервал увеличил. В действиях все равно стоят логические И/ИЛИ, так что думаю не влияет что есть порт, что нет (как и другие условия). В zabbix_server.conf стоит StartDiscoverers=5. В графике стоит единственное найденное устройство (вбитое до этого ручками).Ну, для начала, советую выломать все SNMPv1 агенты. Если какое-то из устройств не ответит по v2 с ним разберетесь отдельно. Увеличьте интервал обновления минимум до часа. Иначе может превысить максимальное кол-во процессов обнаружения.
Порт сервиса из действий тоже можно выковырнуть, поскольку наверняка все устройства на SNMP порту по умолчанию. ip адрес узла сети тоже можно не указывать, если правило обнаружения одно.
Далее, что стоит в zabbix_server.conf в разделе:
### Option: StartDiscoverers
#<----->Number of pre-forked instances of discoverers.
#
# Mandatory: no
# Range: 0-250
# Default:
StartDiscoverers=?
Тоже существенный момент.
И последнее, если здесь не "0" - то посмотрите загрузку discoverer'а в графике zabbix data gathering process busy. Если он уперся в потолок, то и новых обнаружений не будет. Кстати, если поставить слишком короткий период и большой диапазон перебора, то произойдет тоже самое discoverer встанет.
Comment
Comment