Поиск по WMI. Сопоставление сетевых интерфейсов (дублирование)

[Diesel315]

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

Суть (Zabbix 5.4.9):
Осуществляется задача поиска сетевых интерфейсов стандартным методом через wmi. Основа взята из встроенного шаблона, но переписана в собственный (стараюсь сам полностью разобраться, поэтому всегда переписываю шаблоны под себя, а не "накидываю" встроенные).
Шаги опять же стандартные:
1. Создаем item поиска по WMI - wmi.getall[root\cimv2,"select * from win32_networkadapter where NetConnectionStatus=2"] Отличие от встроенного, что сразу фильтрую те, что в UP (хотя можно еще добавить условие и по отбору физических только адаптеров, но пока не было нужды)
2. В правиле dicrovery создаем item интерфейс через net.if.discovery + зависимость от WMI

Собственно тут и начинаются метаморфозы. Через WMI возвращаются одинаковые имена (Name) интерфейсов, это можно также увидеть на сервере через WmiExplorer_2.0.0.2 (на сервере включено 2 интерфейса и они объединены в teaming)



Хотя на самом деле это:


То есть через WMI ни в каком из полей не возвращается #2 или #3



И вроде бы можно было бы задействовать NetConnectionID оно как раз дает некую фильтрацию и возможность отличать интерфейсы друг от друга, но тут засада, что net.if.discovery ничего не знает про это:

{"{#IFNAME}":"Broadcom NetXtreme Gigabit Ethernet #3-WFP Native MAC Layer LightWeight Filter-0000"},
{"{#IFNAME}":"Broadcom NetXtreme Gigabit Ethernet #2-WFP Native MAC Layer LightWeight Filter-0000"},
{"{#IFNAME}":"Microsoft Network Adapter Multiplexor Driver-WFP Native MAC Layer LightWeight Filter-0000"},
{"{#IFNAME}":"Microsoft Network Adapter Multiplexor Driver-Microsoft Load Balancing/Failover Provider-0000"},
{"{#IFNAME}":"Microsoft Network Adapter Multiplexor Driver-QoS Packet Scheduler-0000"},
{"{#IFNAME}":"Microsoft Network Adapter Multiplexor Driver-WFP 802.3 MAC Layer LightWeight Filter-0000"},
{"{#IFNAME}":"WAN Miniport (IP)-WFP Native MAC Layer LightWeight Filter-0000"},
{"{#IFNAME}":"WAN Miniport (IP)-QoS Packet Scheduler-0000"},
{"{#IFNAME}":"WAN Miniport (IPv6)-WFP Native MAC Layer LightWeight Filter-0000"},
{"{#IFNAME}":"WAN Miniport (IPv6)-QoS Packet Scheduler-0000"},
{"{#IFNAME}":"WAN Miniport (Network Monitor)-WFP Native MAC Layer LightWeight Filter-0000"},
{"{#IFNAME}":"WAN Miniport (Network Monitor)-QoS Packet Scheduler-0000"},
{"{#IFNAME}":"Microsoft Kernel Debug Network Adapter"},
{"{#IFNAME}":"Broadcom NetXtreme Gigabit Ethernet"},
{"{#IFNAME}":"Broadcom NetXtreme Gigabit Ethernet #2"},
{"{#IFNAME}":"IBM USB Remote NDIS Network Device"},
{"{#IFNAME}":"Broadcom NetXtreme Gigabit Ethernet #3"},
{"{#IFNAME}":"Broadcom NetXtreme Gigabit Ethernet #4"},
{"{#IFNAME}":"Teaming_BAL-BACKUP-01"},
{"{#IFNAME}":"Microsoft Network Adapter Multiplexor Driver"},
{"{#IFNAME}":"WAN Miniport (IP)"},
{"{#IFNAME}":"WAN Miniport (IPv6)"},
{"{#IFNAME}":"WAN Miniport (Network Monitor)"},
{"{#IFNAME}":"WAN Miniport (PPPOE)"},
{"{#IFNAME}":"Software Loopback Interface 1"},
{"{#IFNAME}":"Microsoft Teredo Tunneling Adapter"},
{"{#IFNAME}":"Microsoft IP-HTTPS Platform Adapter"},
{"{#IFNAME}":"Microsoft 6to4 Adapter"},
{"{#IFNAME}":"WAN Miniport (SSTP)"},
{"{#IFNAME}":"WAN Miniport (IKEv2)"},
{"{#IFNAME}":"WAN Miniport (L2TP)"},
{"{#IFNAME}":"WAN Miniport (PPTP)"},
{"{#IFNAME}":"WAN Miniport (GRE)"}]

Может кто решал эту проблему?

[Semiadmin]

Такое ощущение, что проблему вы создали себе сами, неверно переписав стандартный шаблон.
Дело в том, что net.if.discovery в нем - не встроенный агентский ключ, а зависимый от агентской проверки wmi.getall (и названный точно так же, чтоб уж точно запутаться).
Вот это зависимое LLD получает не только {#IFNAME}, но еще и {#IFDESCR} и {#IFALIAS}.
Кстати, обычный net.if.discovery, начиная с версии агента 5.4.5, тоже малость поумнел и кроме {#IFNAME} получает {#IFGUID}.

[Diesel315]

Спасибо за попытки помочь!
Надеюсь ниже напишу более менее понятно, извиняюсь если запутано, вопрос с описательной точки зрения не простой.

Насчет неверной переписки встроенного шаблона не согласен. Вы не уловили корень проблемы.
Да все верно, во встроенном шаблоне, как и в моем есть item поиска по WMI:
встр.: wmi.getall[root\cimv2,"select * from win32_networkadapter where PhysicalAdapter=True"]
мой.: wmi.getall[root\cimv2,"select * from win32_networkadapter where NetConnectionStatus=2"]

* Через него мы ищем нужные нам интерфейсы с "предфильтрацией".

далее по этапу мы настраиваем зависимый discovery (от запроса выше wmi). На этом этапе у нас включается в работу prerpocessing:

output = JSON.parse(value).map(function(net){
return {
"{#IFNAME}": net.Name,
"{#IFDESCR}": net.Description,
"{#IFPHYSICALADAPTER}": net.PhysicalAdapter,
"{#IFALIAS}" : net.NetConnectionID,
"{#IFNETENABLED}": net.NetEnabled,
"{#IFNETSTATUS}": net.NetConnectionStatus,
"{#IFSPEED}": net.Speed
}})
return JSON.stringify({"data": output})

В котором мы сопоставляем и фильтруем полученные данные от WMI с прописанными макросами в самом шаблоне.

Но собственно возвращаясь к моменту *
Суть проблемы в том, что сам WMI на два разных физических интерфейса возвращает одинаковое имя (почему-то wmi пропускает #)! Скриншот выше это подтверждает.
Отсюда и ломается сопоставление при создании item в результате discovery
То есть ломается часть - "{#IFNAME}": net.Name, интерфейсы разные, а имя одинаковое!

Как итог интерфейс-то создается, но счетчик по нулям. Потому что вместо того, чтобы считать биты включенного (up) интерфейса условно Broadcom NetXtreme Gigabit Ethernet #3 система считает биты выключенного (down) интерфейса Broadcom NetXtreme Gigabit Ethernet #2
А считает он так, потому что как и написал выше имена у них одинаковые с точки зрения WMI - Broadcom NetXtreme Gigabit Ethernet

Вы написали

Вот это зависимое LLD получает не только {#IFNAME}, но еще и {#IFDESCR} и {#IFALIAS}.

да все верно (+ там по факту в prerpocessing можно все настроить/сопоставить, что отдает WMI), только беда в том, что zabbix_get net.if.discovery работает только с {#IFNAME} выше я написал про это...

... но

Кстати, обычный net.if.discovery, начиная с версии агента 5.4.5, тоже малость поумнел и кроме {#IFNAME} получает {#IFGUID}.

вот это уже интереснее, и может быть сможет мне помочь!

[Semiadmin]

Так zabbix_get net.if.discovery обращается не к зависимому от wmi.getall ключу, используемому в шаблоне, а к стандартному агентскому zabbix_get net.if.discovery, независимо от того, есть этот ключ в шаблоне или нет. Отсюда и такой список макросов в выдаче.

[Diesel315]

Получение вывода команды zabbix_get net.if.discovery здесь по факту интересен с точки зрения с какими {#IF... } он может оперировать.
В старой версии он может оперировать только с {#IFNAME}, в новой уже и с {#IFGUID}

Это к тому, что например ключ net.if.in["{#IFNAME}"] будет работать, а вот уже если попробовать взять доступное значение из prerpocessing {#IFALIAS} и написать условно ключ net.if.in["{#IFALIAS}"] уже не работает.
Как я понял, потому что net.if.discovery не знает что такое net.if.discovery {#IFALIAS} aka NetConnectionID.

Сейчас, например, думаю попробовать net.if.in["{#IFGUID}"] , скорее всего будет работать, так как net.if.discovery уже знает про {#IFGUID}
Надо только скорректировать prerpocessing:

output = JSON.parse(value).map(function(net){
return {
"{#IFNAME}": net.Name,
"{#IFDESCR}": net.Description,
"{#IFPHYSICALADAPTER}": net.PhysicalAdapter,
"{#IFALIAS}" : net.NetConnectionID,
"{#IFNETENABLED}": net.NetEnabled,
"{#IFNETSTATUS}": net.NetConnectionStatus,
"{#IFSPEED}": net.Speed
[B]"{#IFGUID}": net.GUID[/B]
}})
return JSON.stringify({"data": output})

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

1. Вся суть проблемы в том, что WMI возвращает одинаковые имена, почему-то стирая #n
То есть в системе есть два интерфейса которые в up:
Broadcom NetXtreme Gigabit Ethernet #2 (SW.2.99_Gi0_11) <--- Так они видны в Windows; Так их видит WMI --> Name:Broadcom NetXtreme Gigabit Ethernet (NetConnectionID:SW.2.99_Gi0_11)
Broadcom NetXtreme Gigabit Ethernet #3 (SW.2.98_Gi0_11) <--- Так они видны в Windows; Так их видит WMI --> Name:Broadcom NetXtreme Gigabit Ethernet (NetConnectionID:SW.2.98_Gi0_11)

2. Когда Zabbix пытается создать через discovery интерфейс, то один (не знаю как точно, может по порядку какому-то) он создает, но на другой он уже кричит -

Cannot update item: item with the same key "net.if.in["Broadcom NetXtreme Gigabit Ethernet"]" already exists.
Cannot update item: item with the same key "net.if.out["Broadcom NetXtreme Gigabit Ethernet"]" already exists.

И оно логично, потому что WMI вернул одинаковые имена. A Zabbix не может создать новый item у которых в качестве ключа net.if.in["{#IFNAME}"] или net.if.out["{#IFNAME}"] будет уже занятое имя
Вопрос бы легко решился, если Zabbix (равно net.if.discovery) мог оперировать в качестве взаимодействия с сет.интерфейсами через другие значения ключа, например - ({#IFALIAS}" : net.NetConnectionID,)
Например через:
net.if.in["{#IFALIAS}"]
net.if.out["{#IFALIAS}"]
Не важно как называется часть #IF... суть в сопоставлении и возможности видеть у Zabbix только Name, ну и теперь GUID. То есть, если бы он мог видеть еще NetConnectionID, то вопрос закрылся, а так получается он может оперировать только двумя параметрами.

Могу ошибаться, но по факту это получается некая недоработка у Zabbix.
По хорошему ему бы научится через net.if.discovery видеть не только как сейчас {#IFNAME} и {#IFGUID}, а все что может вернуть WMI

[Semiadmin]

Ну как бы еще объяснить, что зависимое от WMI-запроса LLD как раз и возвращает {#IFNAME}, {#IFDESCR} и {#IFALIAS}. Только через zabbix_get это увидеть нельзя.
А при желании (поправив JS в препроцессинге) можно добавить макросы и для всего остального, что получает запрос.

[Kos]

На самом деле, совершенно неважно, что именно возвращает штатный net.if.discovery, если вы им всё равно не пользуетесь (т.е. можно его вывод использовать разве что в качестве примера).

Проблема в том, что вам для прототипа элемента данных нужно в ключе указывать макрос, который одновременно:

• уникален для каждого сетевого интерфейса из того списка, для которого нужно создавать свой объект;
• по смыслу подходит для данного ключа.

Среди тех данных, которые возвращает штатный net.if.discovery, оба макроса (и {#IFNAME}, и {#IFGUID}) этим условиям удовлетворяют: для нужных вам ключей net.if.in[...] и net.if.out[...] можно указывать либо "network interface full description", либо (в скобках) "network interface GUID" (ну, можно ещё "IPv4 address", ссылка).

А вот с теми данными, которые возвращает WMI-запрос, несколько сложнее.
Тот "network interface full description", который вы пытаетесь получить, он не возвращает; поскольку, как сами пишете, для него не хватает порядкового номера - а без него получаются дубликаты и нет возможности выбрать из них нужный.
Если же среди возвращаемых данных есть GUID либо IP-адрес, то можно в ключе прототипа элемента данных использовать их (я бы предпочёл GUID, поскольку для всяких team-ингов, транков и т.п. и IP-адрес может дублироваться). При этом в имени элемента данных вполне можно использовать либо возвращаемое через WMI поле Name (оно быть уникальным не обязано), либо NetConnectionID (оно, как раз, уникальное), либо оба сразу.

[Diesel315]

To Semiadmin and to Kos
Ок, я понял, что смотреть на net.if.discovery и с какими значениями он работает/возвращает, обращать внимание необходимости нет.
Да возможно тут я зашел в тупик предполагая, что раз net.if.discovery может видеть только{#IFNAME}, то и в ключах net.if.in/net.if.out можно использовать только {#IFNAME}

Но вы также говорите, что

При этом в имени элемента данных вполне можно использовать либо возвращаемое через WMI поле Name (оно быть уникальным не обязано), либо NetConnectionID (оно, как раз, уникальное), либо оба сразу.

1. возвращаемое через WMI поле Name (оно быть уникальным не обязано) - ну так вот я же выше пример привёл, что как раз оно уникальным должно быть иначе zabbix не может создать item


В такой конструкции (а это по факту стандартный шаблон) я и получаю ошибку: already exists , так как Name не уникально


2. либо NetConnectionID (оно, как раз, уникальное) - как и писал выше в контексте шаблона и json это - {#IFALIAS}" : net.NetConnectionID, то есть, если писать ключи на скриншоте выше:
net.if.in["{#IFALIAS}"]
net.if.out["{#IFALIAS}"]
то не работает!

Не может zabbix найти/обнаружить/опросить интерфейс:
Cannot obtain network interface information

[Kos]

Но вы также говорите, что

1. возвращаемое через WMI поле Name (оно быть уникальным не обязано) - ну так вот я же выше пример привёл, что как раз оно уникальным должно быть иначе zabbix не может создать item


В такой конструкции (а это по факту стандартный шаблон) я и получаю ошибку: already exists , так как Name не уникально

Читаем ещё раз внимательно: уникальным обязано быть поле "ключ", а не поле "имя". Это разные поля.
Ко второму пункту это также относится.

В поле "имя" для прототипа элемента данных вы можете использовать всё, что угодно, лишь бы вам это было удобно.
В поле "ключ" - только то, что реально может потом обрабатываться агентом. Ссылку на документацию я приводил, и даже пересказывал, что именно там может быть. Я бы предложил использовать там GUID в круглых скобках, если поле GUID возвращается в ответ на WMI-запрос.

[Semiadmin]

OK, понял, в чем проблема. Name не уникально, а NetConnectionID, т.е. alias, не принимает агентская проверка net.if.*.
Но она принимает GUID (судя по доке, начиная с версии агента 5.0). Так что нужно всего лишь сделать LLD макрос для него, добавив GUID в wmi-запрос и в JS скрипт препроцессинга.
P.S. Дописав, увидел ответ коллеги Kos. Проверил - GUID в ключе должен быть не в круглых, а в фигурных скобках.

[Diesel315]

To Kos

В поле "ключ" - только то, что реально может потом обрабатываться агентом.

Именно! я про это и писал все время) Про имя в контексте itema я понимаю, что можно написать все что угодно, это просто название не более.
Я изначально и писал всегда про Name в контексте ключа.
item с ключем net.if.in["{#IFNAME}"] для второго адаптера система не может создать, потому что WMI возвращает одинаковое имя для них.

To Semiadmin
Верно! про это я и писал, что имя не уникально, а с NetConnectionID не умеет работать проверка net.if.*
Остается только попробовать GUID


Как итого я же верно все же мыслю, что это "засада" и скажем так ограниченный функционал Zabbix? Никто не сталкивался с такой ситуацией?
Если бы проверка net.if.* могла работать с любым параметром который возвращает WMI:
net.Name,
net.Description,
net.PhysicalAdapter,
net.NetConnectionID,
net.NetEnabled,
net.NetConnectionStatus,
net.Speed
то проблем бы не было, но что имеем, то имеем...

[Kos]

Верно! про это я и писал, что имя не уникально, а с NetConnectionID не умеет работать проверка net.if.*
Остается только попробовать GUID

Ну, так Вам об этом говорим уже сколько
Вот, сейчас сам, наконец, проверил: GUID через WMI вполне себе возвращается.
Да, коллега Semiadmin меня справедливо поправил: GUID должен быть не в круглых, а в фигурных скобках. Но он именно в таком виде и возвращается.
Правда, с GUID-ами умеют работать агенты, начиная с версий 5.0.16, 5.4.5 или 6.0.0. Т.е. агент, скажем, 5.4.4 или 5.2.x такого не поймёт.

[Semiadmin]

Правда, с GUID-ами умеют работать агенты, начиная с версий 5.0.16, 5.4.5 или 6.0.0. Т.е. агент, скажем, 5.4.4 или 5.2.x такого не поймёт.

Kos, спасибо за уточнение.Не нашел этого в доке, просто заметил, что впервые упоминание про {#IFGUID} появилось в доке 5.0.

[Diesel315]

Спасибо за содействие и помощь.
Коллеги, а вы не приближенные к разработчикам?)

Может до них можно донести информацию, что хотелось бы чтобы net.if.* еще и работал как минимум с net.NetConnectionID ака {#IFALIAS}

[Semiadmin]

Для подобных пожеланий есть ресурс https://support.zabbix.com/projects/ZBXNEXT, где можно после регистрации создать issue.
Но я, если честно, не вижу особого смысла в подобном функционале. Просто ставите в параметр ключа прототипа {#IFGUID}, а в имя - понятное {#IFALIAS} или {#IFNAME}.