Enhanced SNMP Low Level Discovery

[jhgrc]

Thank you for this usefull, but also disappointing information. I have not time yet to take a look about Zabbix 3.0. May you give a reference to your project here? Maybe we can merge it into the current V2.3.1 .

It depends a lot based on your monitorings if basic Zabbix 3 LLD enough for you.

I need to monitor OIDs like this:

x.x.x.[ascii string].[ascii string].[index]

for item prototype I need to be able to map ascii strings to user macros and for item names.

[ascii string] is encoded like this: [lenght of string].[char1].[char2]..[char n]

example:

[FONT="Courier New"]tsicsnmp.discovery [oid] a a a (return 3 ascii strings)
x.x.x.[COLOR="red"]6.122.97.98.98.105.120[/COLOR].[COLOR="blue"]3.76.76.68[/COLOR].[COLOR="green"]5.115.117.99.107.115[/COLOR]
      [COLOR="red"]{#STR1}[/COLOR]                [COLOR="blue"]{#STR2}[/COLOR]   [COLOR="green"]{#STR3}[/COLOR]

would return JSON objects in clear text and OID-encoded:
{#STR1} = "zabbix"
{#STR1OID} = 6.122.97.98.98.105.120
{#STR2} = "LLD"
{#STR2OID} = 3.76.76.68
{#STR3} = "sucks"
{#STR3OID} = 5.115.117.99.107.115
[/FONT]

This is what tsicsnmp.discovery addresses. It would be great if such features (ascii decoding, ip deciding, single oid-byte or rest of oid) would be implemented in this topics php-discovery script.

[gjaekel]

It depends a lot based on your monitorings if basic Zabbix 3 LLD enough for you.

I need to monitor OIDs like this:

x.x.x.[ascii string].[ascii string].[index]


This is what tsicadvsnmp.discovery addresses. It would be great if such features (ascii decoding, ip deciding, single oid-byte or rest of oid) would be implemented in this topics php-discovery script.

I a bit famililar with this ASCII-String to OID representation, i'm using it in conjuction with net-snmpd's logmatch feature. I wonder if it's possible to reverse it without referring to the MIB -- which would blow up the scope of the script.

Again, because Google seems to have no knowledge about the term "tsicadvsnmp.discovery": May you give me a reference to your script? Then I might take a look on your concrete feature.

[jhgrc]

Again, because Google seems to have no knowledge about the term "tsicadvsnmp.discovery": May you give me a reference to your script? Then I might take a look on your concrete feature.

Sorry, remove "adv" from the middle. tsicsnmp.discovery

https://github.com/joriws/tsicsnmp.discovery

[gjaekel]

I wonder if it's possible to reverse it without referring to the MIB -- which would blow up the scope of the script.

This was complete nonsense: Because it's a length-prefixed sting, if's trivial to reverse-decode.

But where you start? Or does the syntax of your call say "expect 3 strings after the OID"?

[gjaekel]

Sorry, remove "adv" from the middle. tsicsnmp.discovery

https://github.com/joriws/tsicsnmp.discovery

Because here it's allowed, I recommend to edit your posts concerning it. By the way - I dislike most forums, because in many cases one have to carefully "consume" long threads -- and may mistakes on that -- to get the "head of knowledge".

[jhgrc]

This was complete nonsense: Because it's a length-prefixed sting, if's trivial to reverse-decode.

But where you start? Or does the syntax of your call say "expect 3 strings after the OID"?

If you run the script command it returns "manual"

s$ ./tsicsnmp.discovery
Turbo-simple-commanded SNMP Discovery for Zabbix v2->

Usage: ./tsicsnmp.discovery [host] [SNMP options] [base oid] [analyze commands]*
        host = host dns or ip
        SNMP options = snmpwalk commandline options ie "-v2c -cpublic"
        base oid = SNMP oid to be queried and analyzed
        analyze commands = commands to splice OID
                a = ASCII analyze, 1st byte string lenght and read string
                e = return to end of oid
                i = analyze IP address, alias for 4 digit matching, does not have sanity check
                t = analyze as ASCII text until first non-printable character, "1 t" is quite close to "a"
                [number] = copy [number] OID digits
                -[option] = Start OID analyzing from the right for the command
                        Previous advanced snmp discovery script had functionality like this

Return value via STDOUT is JSON array of objects
        {#TSICSNMPOID} = all OID index which are analyzed by commands
        {#TSICSNMPFULLOID} = full OID containing full address of MIB object
        {#TSICSNMPOIDNOTCAPTURED} = contains left over OID if anything is left over from analyzing commands
        {#TSICSNMPOIDNOTCAPTUREDTEXT} = above as 7-bit printable characters converted to text
        {#TSICSNMPVALUE} = SNMP value returned by full OID query
        {#TSICSNMPINDEX[1-]}* = Indexes analyzed by commands, starts from 1 and ends at number of analyzing commands
        {#TSICSNMPINDEXTEXT[1-]}* = Above analyzed converted to 7-bit printable characters

On Zabbix low level discovery you use it like this (xxx,a,a,1) to return two ascii strings and one oid byte

tsicsnmp.discovery[{HOST.CONN},"-v2c -c{$SNMP_COMMUNITY}",.1.3.6.1.4.1.9.9.336.1.6.1.1.3,a,a,1]

[gjaekel]

Thank you.

Now, some may start or help to merge. Because I don't want to "rate" it, i just mention the fact that's implemented in a different script language. Therefore, your "idea" have to be merged in.

I would recommend to stay to use PHP for the implementation because it's an requirement for Zabbix itself.

[jhgrc]

Thank you.

Now, some may start or help to merge. Because I don't want to "rate" it, i just mention the fact that's implemented in a different script language. Therefore, your "idea" have to be merged in.

I would recommend to stay to use PHP for the implementation because it's an requirement for Zabbix itself.

That's what I also had on my mind. I think the spec would be for "--index" to splice the discovered OID from index like

"--index" = ".1.3.6.1.4.1.9.9.336.1.6.1.1.3,a,a,1" or
"--index" = "CISCO-ITP-GSP-MIB::cgspLinkState,a,a,1"

[gjaekel]

Maybe the syntax is a small bit asymmetric: You choose different letters to symbolize a kind (ASCII, IP) for one item, but you choose an integer value to pass n OID digits. And because the whole term represents an OID, I would suggest to continue to use '.' as the separator and introduce the character '#' for OID digits. To ease parsing and avoid conflicts, the well-introduced '%' may be used as a signal. Then, one may even resing to choose an character for the OID kind and use a plain '%' instead of '%#'. Maybe '@' can be at leas as an alias for 'a', too.

"--index" = ".1.3.6.1.4.1.9.9.336.1.6.1.1.3.%a.%a.%" or
"--index" = "CISCO-ITP-GSP-MIB::cgspLinkState.%a.%a.%"

[jhgrc]

Fair enough and I agree - what ever makes it foolproof syntax.

About another "zabbix LLD sucks" topic - because Cisco/MIBs suck.

Could this php discovery script have simple if-then-else approach.

- I want to create single item for interface bytes in (due to triggering, actions and grafana dashboards)
- I have two potential counters ifInOctets and ifHCInOctets
- I would like to have filter ifHCInOctets <> 0 (found and increasing) - return OID/MIB ifHCInOctets
- if ifHCInOctets non-existent or zero - return OID/MIB ifInOctets
- With Zabbix item prototype I could SNMP OID map to this returned value and have single item polled instead of two items, potential two triggers, two graph prototypes etc

So as a pseudo-code

if (ifInOctets <>0 && ifHCInOctets <> 0) return ifHCInOctets
else if (ifInOctets <>0 && ifHCInOctets ==0) return ifInOctets
else skip_discovery

The problem with Zabbix 3 LLD is that I need to have multiple discoveries for same thing with different out come by LLD filter. But the problem is that if ifHCInOctets is not returned by routers LLD filter will fail so you cannot capture that "ifHCInOctets==0".

[gjaekel]

@others: Yes, this is going to be out-of-topic

I worked around this by using a "macro variable" for all items like

SNMP-OID: {$IFPREFIX}InOctets.{#SNMPINDEX}

at item level in the discovery part of my Zabbix basic template for NICs. I'm heavy using inheritance features. If I "instantiate" to a host, it's linked to serveral top level templates representing the kind or the device (in terms of hardware or techical aspects), the stage and/or the monitored services.

Speaking with your case, some concrete router would refer (among others) to a "Cisco type device" which will (amoung others templates) refer to a "64bit-NIC" template which will define this $IFPREFIX to 'ifHC'. And there is another with the "32bit-NIC" with a Value of 'if'. If you wonder, why take in the prefix 'if': Yes, there actually was a device with require another prefix

[jhgrc]

@others: Yes, this is going to be out-of-topic

Not OT at all - we are specifying killer low level discovery to overcome Zabbix/MIB-OID limitations to have simple to maintain templates to Zabbix..

I worked around this by using a "macro variable" for all items like

SNMP-OID: {$IFPREFIX}InOctets.{#SNMPINDEX}

at item level in the discovery part of my Zabbix basic template for NICs. I'm heavy using inheritance features. If I "instantiate" to a host, it's linked to serveral top level templates representing the kind or the device (in terms of hardware or techical aspects), the stage and/or the monitored services.

Speaking with your case, some concrete router would refer (among others) to a "Cisco type device" which will (amoung others templates) refer to a "64bit-NIC" template which will define this $IFPREFIX to 'ifHC'. And there is another with the "32bit-NIC" with a Value of 'if'. If you wonder, why take in the prefix 'if': Yes, there actually was a device with require another prefix

I think this does not work as heriting 64bit-NIC or 32-bit-NIC is host level action. The actual problem is that host supports 64bit-counters but some interfaces do not report 64-bit, only 32-bit. So a host can have mixture of 64/32-bit counters.

For example we have Cisco ADSL-modem, it has FE/GE switch which return 64-bit counters. ATM-AAL -layer returns only 32-bit counters. SNMPWALK is like:

ifInOctet.0 = xxx
ifInOctet.1 = xxx
ifInOctet.2 = 0

ifHCInOctet.0 = xxx
ifHCInOctet.2 = 0

so router does not return ifHCInOctet.1. These are what I want to filter

Interface 0 = use HC
Interface 1 = use non-HC
Interface 2 = don't poll (ifOperStatus might be UP but no traffic)


Also for if-then-else I've another application:

if (ifSpeed == 2*32-1) return ifHighSpeed, multiplier=1000000
else return ifSpeed, multiplier=1

Why - I want single speed polled from router. If >4Gbps interface I need to use ifHighSpeed OID and somehow have item prototype custom multiplier to million. IfSpeed return bps, ifHighSpeed return Mbps.

These are what I am looking elegant solution and your script is good start. Modifying my own script for multi-table-discovery and filtering would be big task but doable. And it would also need if-then-else -approach.

** update - Zabbix does not seem to support macro at item "Use custom multiplier"

[gjaekel]

Ouch, this is a realy annoying feature: You would have to split the NIC discovery into separate ones filtered by something heuristic like the name, speed or type.

But to me your usecase is "some magic patching" at another level of abstraction and that's not the scope of the script.

It might look attractive because it seems to be easy to implement it here. But in my opinion it should not mixed in for the reasons i stated. In the Unix-spirit, it might be "piped" after it's output: Let pull the descriptive data and the runtime data you need for the decision by using "this" scipt. Then, pipe the (JSON) output to an "auto-Highspeed" script and let modify it there.

Of course, this might even be an "+1 level" implementation: A general JSON-in/JSON-out processor for this kind of data using some external rule-set written in it's own DSL. If it would be XML, this might be done using an XSLT-Processor. I don't know if there is some similar for JSON or if one have surround such thoughts with JSON/XSL-Converters ...

Update: The jq tool (https://stedolan.github.io/jq/) might be useful for this or even may be used to perform this kind of job.