Не обновляется ip активного агента при авторегистрации

[Griboed0ff]

Коллеги, приветствую! Имею Zabbix 5.0.2 и кучу активных агентов, которые автоматически регистрируются. Проблема в том, что при смене ip активного агента, добавляется еще один интерфейс, а не меняется. Таких интерфейсов может добавляться очень много и непонятно какой из них актуальный. Я понимаю, что для активного агента не важен ip, который прописан в профиле узла, так как агент сам шлет данные серверу. Дело в том, что на эту информацию в нашей компании опираются некоторые отделы и потом эта информация нужна мне в базе для некоторых отчетов. Ранее я предполагал, что информация об ip будет обновляться, но это не так. К тому же у нас в компании кривой dns и информация, которая записывается в поле dns, совсем не соответствует действительности и сбивает с толку коллег.
В чем проблема, подумал я и наваял скрипт на пайтоне, который при регистрации агента или точнее при каждой такой попытке, через апи удаляет все интерфейсы и прописывает один верный. Все было бы неплохо, но тайминг запроса активного агента у нас в конфиге по умолчанию (120 секунд), а агентов у меня на этой проксе пока ~5000 и мой заббикс прокси просто лег из-за количества обращений к скрипту. Я могу конечно повысить лимит открытия файлов на машине,но запуск скрипта не нужен так часто и вообще это напрасное использование ресурсов прокси.
Далее возникла идея использовать скрипт только тогда, когда это требуется, то есть при смене ip на машине. Начал думать как возможно использовать встроенный макрос {HOST.IP} в триггере, аля если предпоследнее и последнее значение различаются запускается скрипт. Но никак не могу прикрутить {HOST.IP} в триггер. Может кто-либо сталкивался с такой проблемой или имеет идеи как можно решить мою проблему?

[Kos]

Начал думать как возможно использовать встроенный макрос {HOST.IP} в триггере, аля если предпоследнее и последнее значение различаются запускается скрипт.

Хотел бы сразу предостеречь от этого. Макрос {HOST.IP} в триггере всегда раскрывается в IP-адрес, привязанный к первому упомянутому в триггере элементу данных. При появлении (в результате авторегистрации) новых интерфейсов у хоста появится возможность при конфигурировании этих элементов данных выбирать - к какому из интерфейсов они относятся, но это сугубо ручной процесс и автоматически тут ничего не поменяется.

Мне кажется, более реальный путь - это настроить запуск скрипта в качестве действия не на срабатывание триггера, а на событие авторегистрации. И уже там пытаться использовать тот же макрос {HOST.IP} (только убедиться, что он возвратит - старый адрес или новый), а заодно {HOST.NAME} и прочие необходимые для того, чтобы скрипту можно было пнуть Zabbix API и проделать нужную ему работу. А работа, вероятнее всего, сведётся к тому, что нужно будет удалить новый интерфейс (только что прописанный в результате работы авторегистрации), а прежнему интерфейсу прописать новый IP. Кстати, если к (прежнему) интерфейсу будет приписан хоть один использующий его элемент данных, то такой интерфейс нельзя будет удалить, но можно отредактировать.

[Griboed0ff]

настроить запуск скрипта в качестве действия не на срабатывание триггера, а на событие авторегистрации.

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

[Kos]

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

Тогда нужно навешивать триггер на событие "смена количества интерфейсов". Использовать можно, например, внутреннюю проверку zabbix[host,discovery,interfaces] (возвращает JSON, от которого можно брать, например, количество элементов в массиве через JSONPath-выражение в препроцессинге). Только неясно, как вычислять в скрипте, который из них актуальный; но думаю, что это решаемая проблема.

[Griboed0ff]

внутреннюю проверку zabbix[host,discovery,interfaces].

Из замеченного, что актуальный адрес добавляется в конец списка, т.е. предположительно крайний всегда актуальный. А далее по триггеру запускать скрипт, который и заменит все интерфейсы на последний из списка, а днс имя возьмет из макроса типа system.uname. Жаль заббикс не умеет одновременно делать и активные проверки и пассивные для одного хоста, во всяком случае у меня работает либо одно, либо другое, либо вообще не работают оба типа проверок.

[Kos]

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

Понятие "конец списка" может зависеть от того, по какому критерию этот список сортировать.
Подозреваю, что хронологически более поздний объект получит ID с бОльшим номером.

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

Прекрасно умеет, у меня практически все агенты так и мониторятся (как в активном, так и в пассивном режимах).
Другое дело, что для этого нужно соблюдение ряда условий: как минимум, доступность коммуникаций в обе стороны на сетевом уровне (т.е. маршрутизация, отсутствие динамического NAT, пропускание нужных портов на фаерволах) и корректная конфигурация (как на стороне агентов, так и на стороне сервера Zabbix через его веб-интерфейс - я об этом писал, например, здесь или здесь). Т.е. если у агентов время от времени меняются их IP-адреса, то могут возникать перебои при выполнении пассивных проверкок - до тех пор, пока не будет обновлена конфигурация на сервере и эти изменения не будут перечитаны в кэш сервера.

[Griboed0ff]

Прекрасно умеет, у меня практически все агенты так и мониторятся (как в активном, так и в пассивном режимах).

Кажется я понял в чем проблема, у меня в конфигах агента не прописано техническое имя, оно не требуется для авторегистрации. Требуется изменить ~20k+ конфигов, чтобы прописать имя, желательно как-то общим параметром типа system.name, а то нет возможности прописать в каждый конфиг свое имя. И получается при моей ситуации, когда добавляю элементы данных, которые должны собираться через агент т.е. пассивная проверка при уже имеющихся активных проверках(агенты пришли через авторегистрацию), все ломается.

[Kos]

Кажется я понял в чем проблема, у меня в конфигах агента не прописано техническое имя, оно не требуется для авторегистрации. Требуется изменить ~20k+ конфигов, чтобы прописать имя, желательно как-то общим параметром типа system.name

Если в настройках конфиг-файла параметры Hostname и HostnameItem не заданы, то используется как раз именно значение метрики system.hostname.
Техническое имя нужно для корректной работы агентов в активном режиме. Если у вас агент в активном режиме работает - то нет необходимости суетиться и менять ~20k+ конифигов.

А когда добавляю элементы данных, которые должны собираться через агент т.е. пассивная проверка при уже имеющихся активных проверках(агенты пришли через авторегистрацию), все ломается.

Вот с этим нужно бы разобраться, только более системно. По симптомам "всё ломается" - не поможет никто. Опишите вашу проблему (что именно делаете, что именно ломается) - попробуем помочь. Только, наверное, лучше это делать в отдельной ветке обсуждения, чтобы не мешать с обсуждением вопроса, который задан в теме данной ветки.

[Griboed0ff]

Использовать можно, например, внутреннюю проверку zabbix[host,discovery,interfaces]

По вашему совету организовал такую схему: через внутреннюю проверку получил json, его обработал так, чтобы на выходе был последний в списке чистый ip, так же включил троттлинг по времени 1d, чтобы не хранить много не нужной текстовой информации в базе, далее триггер по типу предпоследнее значение не равно последнему, далее на триггер действие, запуск скрипта, скрипту как раз передается тот самый ip из внутренней проверки и имя хоста, оно всегда корректное (script.py {HOST.HOST} {{HOST.HOST}:zabbix[host,discovery,interfaces].last()}). Работает корректно, но есть еще проблема: агент может получить ip, который он уже получал и интерфейс с таким адресом уже есть. В таком случае, количество интерфейсов не меняется. Пока думаю возможно сбросить всей группе агентов интерфейс на 0.0.0.0, а далее по логике все должно быть корректно.

[Kos]

Я бы чуть добавил к вашей схеме.

• Теоретически, у хоста могут быть дополнительные интерфейсы других типов (например, IPMI или SNMP). Т.е. в обоих случаях (и обнаружение изменений, и редактирование скриптом через API) нужно это учитывать и менять только интерфейсы с типом "Zabbix agent". Скажем, в настройках самой проверки можно добавить шаг препроцессинга с типом JSONPath и таким шаблоном, чтобы игнорировать интерфейсы других типов:

$.[?(@["{#IF.TYPE}"]=="AGENT")].["{#IF.IP}"]

• Можно добавить ещё один шаг препроцессинга с типом JSONPath и выражением "$.[-1]" (без кавычек) - тогда будет возвращаться единственный IP-адрес, "последний". Ну и да, тротлинг лишним не будет.
• Если вы точно знаете заранее, что у вас все хосты должны иметь только один интерфейс с типом "Zabbix agent", то в скрипте нужно опрашивать текущий список интерфейсов с типом "Zabbix agent" у хоста (например, методом hostinterface.get), после чего в первом из них (т.е. с наименьшим ID) менять его IP-адрес на актуальный (метод hostinterface.update), а затем удалять все остальные интерфейсы с этим типом (метод hostinterface.delete). Тогда не нужно будет трогать айтемы - они по-прежнему будут ссылаться на тот же интерфейс по его ID.
• Скрипту можно сразу передавать не имя хоста, а его ID - макрос {HOST.ID} в этом плане очень полезен. На последнее значение элемента данных проще сослаться при помощи макроса {ITEM.LASTVALUE}.

[Griboed0ff]

Я бы чуть добавил к вашей схеме.

1. Точно знаю, что интерфейс один и это агент, дополнительно ничего тут делать не требуется.
2. Так и было реализовано.
3. Так как знаю, что интерфейс один и это агент, то использую метод апи: hostinterface.replacehostinterfaces, одним действием сразу все заменяется. Пока проблем со сменой id интерфейса не испытал, возможно мои айтемы не используют id интерфейса, или я проглядел возможно что-либо, углублюсь в этот момент.
4. Буду пробовать, так как ID вычислялся в скрипте по имени хоста. Это позволит уменьшить количество обращений к апи. Ну и макрос {ITEM.LASTVALUE} буду пробовать, хотя и мой работает.
Думаю над решением случаев когда, количество интерфейсов не меняется и триггер не срабатывает. Пока не нашел в документации, но скорее всего есть метод апи, чтобы поменять или удалить интерфейсы всем хостам в группе? Если нет, то будем снова питонить. Можно было бы с плеча рубануть и удалить все хосты, они все равно через пару минут придут в авторегистрацию, но некоторым отделам нужна статистика и история, а при удалении hostid сменится, на нем строятся отчеты..

[Kos]

Понятно, спасибо.

Так как знаю, что интерфейс один и это агент, то использую метод апи: hostinterface.replacehostinterfaces, одним действием сразу все заменяется.

Тут два подводных камня, о которых я упоминал:

• могут быть интерфейсы других типов - они будут удалены, если их явно не перечислить в новом списке. Допустим, сейчас их нет, а вдруг в дальнейшем понадобятся?
• могут поменяться ID всех интерфейсов. Возможно, я перестраховываюсь, но мне кажется, что у элементов данных с привязкой к интерфейсам (скажем, типов "Zabbix agent") эта привязка идёт по ссылке на ID интерфейса. Лучше это перепроверить.

Думаю над решением случаев когда, количество интерфейсов не меняется и триггер не срабатывает

Так если элемент данных возвращает конкретный IP-адрес, то какая разница в количестве? Всё равно вы своим скриптом замените их все, независимо от их числа.

скорее всего есть метод апи, чтобы поменять или удалить интерфейсы всем хостам в группе?

Есть метод hostinterface.massremove, но ему надо указывать конкретные свойства удаляемых интерфейсов. Но ввиду предыдущего пункта - не вижу в этом необходимости.

[Griboed0ff]

Так если элемент данных возвращает конкретный IP-адрес, то какая разница в количестве? Всё равно вы своим скриптом замените их все, независимо от их числа.

Не совсем правильно выразился, да возвращается последний в списке ip, но тут это действительно не имеет значения. Так как даже если бы возвращался весь json, то триггер не сработал бы, так как конфигурация интерфейсов не меняется, так как ip интерфейса уже есть в списке. Так же и не срабатывает когда возвращается только один последний ip, все по той же причине - не меняется конфигурация интерфейсов, в нашем случае актуальный не становится последним в списке. То есть адрес агента меняется, а триггер не срабатывает, соответственно скрипт не запускается. Попробую придумать еще какой-либо триггер, чтобы задеть эту часть агентов, которые накопили в себе кучу интерфейсов и теперь прыгают с одного на другой, а триггер не понимает этого в силу своих условий.

[Kos]

Я, кажется, наконец, понял, что Вы имеете в виду.
В случае, когда в конфигурации хоста накопилось некоторое количество интерфейсов и при последующих изменениях IP-адреса он будет лишь прыгать между ними, то не будет отрабатывать процедура авторегистрации, т.к. для неё нет повода (новый IP-адрес уже есть в списке зарегистрированных интерфейсов, а прочая информация не меняется). Как следствие, не поменяется и JSON, возвращаемый метрикой zabbix[host,discovery,interfaces].

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

[Griboed0ff]

Как следствие, не поменяется и JSON, возвращаемый метрикой zabbix[host,discovery,interfaces].

Придумал! Надо предобработать zabbix[host,discovery,interfaces так, чтобы он вернул количество интерфейсов с типом агент ($.[?(@["{#IF.TYPE}"]=="AGENT")].["{#IF.IP}"].length()). Далее триггер, если количество больше одного, то уже скрипт. Таким образом заденем все агенты и не надо отдельно по скрипту прогонять. Пойду пробовать!