-
Problem report
-
Resolution: Fixed
-
Trivial
-
None
-
Team A
-
Sprint 5, Sprint 6, Sprint 7, Sprint 9, Sprint 10, Sprint 11, Sprint 12, Sprint 13, Sprint 14, Sprint 15, Sprint 16, Sprint 17, Sprint 18, Sprint 19
-
5
I met the following problem.
First, I create a LLD discovery with the following OID:
discovery[{#SNMPVALUE},ifOperStatus,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFNAME},1.3.6.1.2.1.31.1.1.1.1,{#IFDESCR},.1.3.6.1.2.1.2.2.1.2,{#IFTYPE},ifType]
And at first it works just fine
Hovewer, If the following filter is applied:
Then there is a problem rises: It means that if devices dont' have 1.3.6.1.2.1.31.1.1.1(ifXtable) then they don't have any values for macroses {#IFNAME},{#IFALIAS} neither.
And such devices could not be discovered! Reason: Filter {#IFNAME} matches @IFNAME BLACKLIST cannot be evaluated despite the fact that
EXPRESSION TYPE of 'Result is False' was used.
There are two problems I see here
- Filter for empty(undefined) value cannot be evaluated despite its type of 'Result is False'
- There is no discovery error (red cross with the comment) which could dramatically assist in debugging such issue. Error or warning stating that not all oids stated in discovery key can be found on the the host could help dramatically
I want you to consider two things here:
1) Make discovery filters more soft.
So in case of 'Result is FALSE' type of expression undefinied can pass as OK. Please consider this just because that template can possibly be applied to broad range of devices where OIDs availability may vary.
2) And/OR
Please also make a warning appear in INFO column of discovery page of the host that would assist in debugging problems that might rise during such discovery
Thank you!
P.S. here are some console output tests for the device that doesn't have ifXtable
administrator@zabbix:~$ snmpwalk -c virton -v 1 10.40.0.30 .1.3.6.1.2.1.31.1.1.1 administrator@zabbix:~$
same with debug on:
administrator@zabbix:~$ snmpwalk -c virton -v 1 10.40.0.30 .1.3.6.1.2.1.31.1.1.1 -d Sending 44 bytes to UDP: [10.40.0.30]:161->[0.0.0.0] 0000: 30 2A 02 01 00 04 06 76 69 72 74 6F 6E A1 1D 02 0*.....virton... 0016: 04 24 58 66 7F 02 01 00 02 01 00 30 0F 30 0D 06 .$Xf.......0.0.. 0032: 09 2B 06 01 02 01 1F 01 01 01 05 00 .+.......... Received 50 bytes from UDP: [10.40.0.30]:161->[0.0.0.0] 0000: 30 30 02 01 00 04 06 76 69 72 74 6F 6E A2 23 02 00.....virton.#. 0016: 04 24 58 66 7F 02 01 00 02 01 00 30 15 30 13 06 .$Xf.......0.0.. 0032: 0D 2B 06 01 04 01 CE 12 01 01 01 01 01 00 42 02 .+............B. 0048: 73 54 sT Sending 44 bytes to UDP: [10.40.0.30]:161->[0.0.0.0] 0000: 30 2A 02 01 00 04 06 76 69 72 74 6F 6E A0 1D 02 0*.....virton... 0016: 04 24 58 66 80 02 01 00 02 01 00 30 0F 30 0D 06 .$Xf.......0.0.. 0032: 09 2B 06 01 02 01 1F 01 01 01 05 00 .+.......... Received 44 bytes from UDP: [10.40.0.30]:161->[0.0.0.0] 0000: 30 2A 02 01 00 04 06 76 69 72 74 6F 6E A2 1D 02 0*.....virton... 0016: 04 24 58 66 80 02 01 02 02 01 01 30 0F 30 0D 06 .$Xf.......0.0.. 0032: 09 2B 06 01 02 01 1F 01 01 01 05 00 .+..........
However, it's all fine you poll IF-MIB counters:
administrator@zabbix:~$ snmpwalk -c virton -v 1 10.40.0.30 IF-MIB::ifDescr IF-MIB::ifDescr.1 = STRING: lo IF-MIB::ifDescr.2 = STRING: eth0 IF-MIB::ifDescr.3 = STRING: eth1 IF-MIB::ifDescr.4 = STRING: wifi0 IF-MIB::ifDescr.5 = STRING: ath0 IF-MIB::ifDescr.6 = STRING: eth0.40 IF-MIB::ifDescr.7 = STRING: ath0.40 IF-MIB::ifDescr.8 = STRING: br0 IF-MIB::ifDescr.9 = STRING: br1
