LLD discovery через zabbix trapper не создает новые элементы

[sersad]

Входные данные, инсталляция с 13 прокси
Версия Zabbix 4.2.8 (revision cb5d5b10f4)
БД Postgres
OS Debian GNU/Linux 8.11

Количество узлов сети (активированных/деактивированных/шаблонов) 18000 15804 / 2066 / 130
Количество элементов данных (активированных/деактивированных/неподдерживаемых) 5463472 5022367 / 423797 / 17308
Количество триггеров (активированных/деактивированных [проблема/ок]) 2921132 2679023 / 242109 [5612 / 2673411]
Требуемое быстродействие сервера, новые значения в секунду 3234.86

Для большинства хостов используется кастомный скрипт для LLD интефейсов. Этот скрипт через команду

zabbix_sender -z 127.0.0.1 -o <ВАЛИДНЫЙ JSON>

по нажатию кнопочки в отдельном самописном интерфейсе запускает скрипт который дискаверит интерфейсы и отправляет их на сервер (+ два раза в сутки по крону дергается для всех железок)

Полный пример того что отсылает скрипт и это же можно выполнить в консоли.

zabbix_sender -z 127.0.0.1 -o '{"data": [{"{#SNMPINDEX}": "49", "{#IFDESCR_UTL}": "gi1/0/1", "{#IFHIGHSPEED}": "1000000000"},{"{#SNMPINDEX}": "72","{#IFDESCR_UTL}": "gi1/0/24","{#IFHIGHSPEED}": "1000000000"},{"{#SNMPINDEX}": "108","{#IFDESCR_UTL}":"te1/0/4","{#IFHIGHSPEED}": "1000000000"}]}' -k zom.interface.lld -s shtk-psnv-dsw1
Response from "127.0.0.1:10051": "processed: 1; failed: 0; total: 1; seconds spent: 0.000120"
sent: 1; skipped: 0; total: 1

Ответ говорит что все принято, но по факту интерфейсы не добавляются. Но можно так выполнить много много раз и может быть они добавятся. Закономерности найти не могу.
Обычные правила LLD работают без каких либо проблем.
Ранее все работало более менее стабильно. Ничего глобального с конфигами не делали

В логах чисто, никаких аномалий по хостам куда шлет zabbix_sender информацию нет.

Что делать и куда копать?

И вопрос какой процесс отвечает за прием сообщений от zabbix_sender в дискавери? Что и на чем (сервер или прокси) нужно дебажить отдельно?




conf сервера

LogFile=/var/log/zabbix/zabbix_server.log
LogFileSize=100
DebugLevel=3
PidFile=/var/run/zabbix/zabbix_server.pid
SocketDir=/var/run/zabbix
DBHost=10.xx.xx.xx
DBName=zabbix
DBUser=xxxxx
DBPassword=xxxxx
DBPort=6432
StartPollers=100
StartIPMIPollers=1
StartPreprocessors=7
StartPollersUnreachable=50
StartTrappers=50
StartPingers=15
StartDiscoverers=10
StartHTTPPollers=2
StartTimers=10
StartEscalators=10
StartAlerters=4
SNMPTrapperFile=/tmp/zabbix_traps.tmp
StartSNMPTrapper=1
HousekeepingFrequency=1
MaxHousekeeperDelete=0
CacheSize=8G
CacheUpdateFrequency=180
StartDBSyncers=12
HistoryCacheSize=1024M
HistoryIndexCacheSize=512M
TrendCacheSize=512M
ValueCacheSize=4G
Timeout=30
UnreachablePeriod=60
AlertScriptsPath=/etc/zabbix/alertscripts
ExternalScripts=/etc/zabbix/externalscripts
FpingLocation=/opt/fping/bin/fping
Fping6Location=/usr/bin/fping6
LogSlowQueries=120000
StartLLDProcessors=5
StatsAllowedIP=127.0.0.1

[Kos]

И вопрос какой процесс отвечает за прием сообщений от zabbix_sender в дискавери? Что и на чем (сервер или прокси) нужно дебажить отдельно?

Данные, отсылаемые утилитой zabbix_sender, на стороне сервера или прокси принимаются процессом trapper.
Низкоуровневым обнаружением, начиная с версии Zabbix 4.2, занимаются процессы отдельного вида (lld manager и lld worker, см. тут).

Где запускается скрипт, т.е. куда именно он отсылает данные - непосредственно на сервер Zabbix или же на Zabbix proxy? В случае Zabbix прокси может быть некоторая задержка:

• во-первых, данные с прокси на сервер Zabbix попадают не мгновенно (хотя и довольно оперативно);
• во-вторых, если меняется конфигурация хоста (например, добавляются новые интерфейсы, обнаруженные механизмом LLD), и при этом хост мониторится через прокси, то реально мониторинг этих новых интерфейсов начнётся с ещё бОльшей задержкой, т.к. для этого нужно, чтобы Zabbix-proxy обновил свою конфигурацию (а это делается по умолчанию раз в час).

Ну и пара замечаний, которые не относятся напрямую к заданному вопросу:

• если речь идёт об устройствах, которые мониторятся по SNMP (судя по именам передаваемых макросов), то Zabbix сам умеет делать LLD и без внешних скриптов;
• версия Zabbix 4.2.x давно уже не поддерживается. Текущие версии - 5.0 (LTS), 5.2 (не LTS, поэтому её поддержка тоже закончится через пару месяцев, поскольку уже вышла следующая версия) и 5.4 (тоже не LTS, вышла две недели назад).

[sersad]

Данные, отсылаемые утилитой zabbix_sender, на стороне сервера или прокси принимаются процессом trapper.

Вот лог с траппера

4304:20210607:111240.141 zbx_setproctitle() title:'trapper #10 [processing data]'
4304:20210607:111240.141 trapper got '{"request":"sender data","data":[{"host":"UFA-N6-DSW6","key":"zom.interface.lld","value":"{\"data\" : [{\n \t\"{#SNMPINDEX}\": \"58\",\n \t\"{#IFDESCR_UTL}\": \"XGigabitEthernet0/0/4\",\n\t\t\"{#IFHIGHSPEED}\": \"10000000000\"\n \t}]}"}]}'
4304:20210607:111240.141 In recv_senderhistory()
4304:20210607:111240.141 In process_client_history_data()
4304:20210607:111240.141 In parse_history_data()
4304:20210607:111240.141 End of parse_history_data():SUCCEED processed:1/1
4304:20210607:111240.141 In process_history_data()
4304:20210607:111240.141 In zbx_preprocess_item_value()
4304:20210607:111240.141 End of zbx_preprocess_item_value()
4304:20210607:111240.141 In zbx_ipc_socket_write()
4304:20210607:111240.141 End of zbx_ipc_socket_write():SUCCEED
4304:20210607:111240.141 End of process_history_data() processed:1
4304:20210607:111240.142 End of process_client_history_data():SUCCEED
4304:20210607:111240.142 In zbx_send_response_ext()
4304:20210607:111240.142 zbx_send_response_ext() '{"response":"success","info":"processed: 1; failed: 0; total: 1; seconds spent: 0.000340"}'
4304:20210607:111240.142 End of zbx_send_response_ext():SUCCEED
4304:20210607:111240.142 End of recv_senderhistory()
4304:20210607:111240.142 zbx_setproctitle() title:'trapper #10 [processed data in 0.000673 sec, waiting for connection]'

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

[Kos]

Ну, я и приведённого фрагмента лога траппера могу видеть лишь то, что траппер данные успешно принимает.
Впрочем, это было очевидно ещё по изначальному сообщению, где приводился ответ сервера утилите zabbix_sender:

Response from "127.0.0.1:10051": "processed: 1; failed: 0; total: 1; seconds spent: 0.000120"
sent: 1; skipped: 0; total: 1

Значит, нужно расследовать дальше: смотреть, что показывают в это время процессы lld manager и lld worker.
По идее, первый должен принять запрос и передать его какому-то воркеру, а второй уже - реально обработать.

Я бы экспериментировал с хостом, который мониторится напрямую Zabbix-сервером, чтобы исключить влияние Zabbix-прокси.

[sersad]

Значит, нужно расследовать дальше: смотреть, что показывают в это время процессы lld manager и lld worker.
По идее, первый должен принять запрос и передать его какому-то воркеру, а второй уже - реально обработать.

Спасибо за совет.
Попробую вечером, пока по крону куча трапперов на всех прокси отрабатывает

[sersad]

Не обнаружил в логах lld manager и lld worker ничего похожего на то что отсылали трапперы.
Но лог там реально прям летит.
Может их не хватает? Не нашел в конфиге 4.2 где их можно добавить.

20706:20210608:002159.401 server #331 started [lld manager #1]
20707:20210608:002159.452 server #332 started [lld worker #1]
20715:20210608:002159.501 server #334 started [lld worker #3]
20716:20210608:002159.529 server #335 started [lld worker #4]
20717:20210608:002159.545 server #336 started [lld worker #5]
20714:20210608:002159.560 server #333 started [lld worker #2

]

[Kos]

Не обнаружил в логах lld manager и lld worker ничего похожего на то что отсылали трапперы.

Честно говоря, я тоже не очень представляю себе, что именно там должно быть. Но хоть что-то ведь должно
Увеличивали уровень логирования на время эксперимента?

До отсылки значений zabbix_sender-ом:

zabbix_server -R log_level_increase="lld manager"
zabbix_server -R log_level_increase="lld worker"

После - вернуть обратно, чтобы лог совсем на заспамило:

zabbix_server -R log_level_decrease="lld worker"
zabbix_server -R log_level_decrease="lld manager"

Может их не хватает? Не нашел в конфиге 4.2 где их можно добавить.

Количество процессов lld worker регулируется параметром конфиг-файла сервера "StartLLDProcessors=" (по умолчанию - 2). У вас их запускается 5, так что явно должны быть где-то в конфиге прописаны явно. Процесс lld manager, по всей видимости, не конфигурируется, поскольку он должен быть один.

[sersad]

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

StartLLDProcessors действительно проглядел этот пункт, добавил и перезапустил, наблюдаю.

[sersad]

Ничего не изменилось...

Есть еще идеи?

[Kos]

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

Неужели у Вас так много LLD-правил отрабатывает? Или Вы повышали уровень логирования не для отдельных процессов, а для всего сервера сразу?

[sersad]

Неужели у Вас так много LLD-правил отрабатывает? Или Вы повышали уровень логирования не для отдельных процессов, а для всего сервера сразу?

Очень много, я выше приводил ТТХ сервера. 15к хостов, больше 5 миллионов элементов, nvps больше 3к
Я повышал уровень логирования для отдельных процессов.