все обнаруженные хосты попадают в один существующий в Zabbix узел

[butalov.a]

Ага, спасибо за идею. Была подобная мысль.
Ранее при тестировании с помощью snmpwalk с некоторых МФУ когда собирал значения, кол-во OIDов приходило сильно урезанное вместо нескольких тысяч сотня например, такое ощущение что хост обрывал соединение.

[Ed.M]

А еще такое наблюдение: если в ходе экспериментов изменять существующее правило discovery, то в нем как-то кешируются результаты предыдущих поисков. У меня оно продолжало находить хосты по адресам, которых там уже не было, например. А вот если правило удалить и создать новое - то все эти призраки пропадают и оно работает именно так, как прописано. Я еще продолжаю эксперименты, как будут результаты - отпишусь.

[butalov.a]

Ага lld правило создавал заново, на счёт кэширования не знал, но так как изначально discovery правило создавалось ещё на zabbix 3.2.8, подумал что могли какие то параметры правила криво перенестись тем более через несколько версий вверх.

[butalov.a]

Не давала мне покоя эта ситуация, и вот что я накопал:
1. В случае с виртуальными машинами Linux OID 1.3.6.1.2.1.2.2.1.6.1 возвращает пустую строку. Если использовать его (именно .1), то все адрес найденных хостов попадают в первый найденный хост. То есть создается 1 хост с 3 интерфейсами разных машин.
2. Если использовать OID 1.3.6.1.2.1.2.2.1.6.2, который возвращает МАС 1-го физического сетевого интерфейса, то поведение именно такое, как и нужно: при смене ip адреса машины она снова определяется, но не создается новый хост, а добавляется интерфейс к существующему. Тут просто в критерии уникальности поставлен 1.3.6.1.2.1.2.2.1.6.2, ничего больше не нужно.
3. Проверте, пожалуйста, что же возвращает OID 1.3.6.1.2.1.2.2.1.6.1 от принтеров. Реальный МАС, который совпадает с ARP записью, или пустую строку? Возможно, проблема в неправильном OID.

Добрый день! Да вы были правы!
Наконец то проверил с помощью snmpwalk значения oid ов от устройств интерфейсы которых добавляются к одному из узлов. И да все устройства интерфейсы которых попадают в имеющийся узел видимо имеют несколько сетевых интерфейсов, и у них oid 1.3.6.1.2.1.2.2.1.6.1 пустая строка, а oid 1.3.6.1.2.1.2.2.1.6.2 имеет реальный MAC.


Поменять как вы советуете критерий уникальности на 1.3.6.1.2.1.2.2.1.6.2, будет некорректно в нашем случае потому как остальные МФУ (подавляющее большинство) которые определяются в Zabbix имеют один сетевой интерфейс и MAC у них находится в oid 1.3.6.1.2.1.2.2.1.6.1.
Поэтому думаю:
1) сделать проверку получаемого значения на пустую строку
2) и видимо нужно сделать дополнительное правило обнаружения для OID 1.3.6.1.2.1.2.2.1.6.2, так как думаю добавление в текущее правило обнаружения ещё одной проверки - oid 1.3.6.1.2.1.2.2.1.6.2, перестанет находить в сети МФУ с одним сетевым интерфейсом и соответственно oid 1.3.6.1.2.1.2.2.1.6.1.

Вообще мне всё равно не понятна логика по которой все эти интерфейсы попадают именно в определенный узел заббикс. Допустим у вас в тестовой среде 3 сервера Linux и попадает в первый, возможно по номеру id в zabbix.
Но у нас этих узлов в zabbix 350, сначала все интерфейсы сыпались в узел U-0004, после удаления этих лишних интерфейсов из узла U-0004, они добавились в U-0007, после такой же процедуры с U-0007 стали попадать в U-0035.
Возможно логика добавления именно по внутреннему id, но между этими U-0007 и U-0035 есть много устройств.

После добавления правила понаблюдаю ещё и позже по результатам отпишусь.

[Ed.M]

Приветствую!
Процесс discovery хранит данные ( в кеше) 1 день. Это можно увидеть в настройках houskeeper-а. Сначала процесс нашел хост 0004 с пустым МАС адресом, и, пока тот был в кеше, добавлял хосты к нему. Потом houskeeper провел зачистку, а discovery нашел хост 0007. Как-то так.
Вам стоит в вашем случае создать 2 правила discovery, с обоими OID. И разбирать результаты в actions, проверяя на пустые значения. Критерий уникальности ставьте МАС, тогда должны создаваться уникальные хосты.
Другая проблема, о которую мы с коллегой споткнулись - после изменения ip у устройства, новый адрес добавляется корректно, как snmp интерфейс, но вот данные по snmp с него не снимаются почему-то. Почему - понять пока не удалось. А вообще в вашем случеа я бы порекомендовал опрашивать устройства по DNS именам, если они изменяются динамически, вместе с ip. Тогда нет нужды обновлять хосты в Zabbix, и мониторинг просто продолжает работать.