Trying to add new device type, calculate from multiple OIDs?

Help
1

I am trying to add support for FiberStore datacenter switches (N5860 in my specific case). One odd thing I’ve run across is that the SFP optical power levels are split across two integer OIDs, like:

FS-FIBER-MIB::fsFiberRXpowerIntegerpart.1 = INTEGER: -2
FS-FIBER-MIB::fsFiberRXpowerDecimalpart.1 = INTEGER: 7
FS-FIBER-MIB::fsFiberRXpowerSign.1 = INTEGER: -1

for a value of -2.07. Is there a way to turn this into a single value for LibreNMS? I.e. fetch two values, do math (which is harder because the decimal part appears to be absolute), then treat as a single value for storage/graph use?

2

Hi @cmadamsgit
This is possible but not with YAML discovery, only using PHP code. You need to create a discovery and a poller code for your sensors, and impement the math here. Then the result will be saved as a single value in both DB and graphs.

3

Can you point me to any examples?

4

I don’t think we have this exact same situation (or did not find it) but you can start with these files :

// Discovery
~/includes/discovery/sensors/temperature/geist-watchdog.inc.php

// Poller
~/includes/polling/sensors/pre-cache/geist-watchdog.inc.php
~/includes/polling/sensors/temperature/geist-watchdog.inc.php

In the discovery code, you can do all in one file and get the proper value into the discover_sensor function. Of course, you won’t be able to put more than one OID. You will only put the main one, but this should not be a problem, cause you’ll also patch the polling code.

For the polling part:

  • you can pre-cache the 2 missing OIDs (decimal and sign).
  • in the polling file itself, you do the math with the 3 OID values, and put the result in the variable so it will get added automatically to the DB as well as the graphs.
5

Wow, what a terrible solution :smiley:
You’ll need to do it in PHP since it is two different oids.
You might be able to do it with a user_func.

FYI, the normal way to handle this is, specify the value should be divided by 100 and:
FS-FIBER-MIB::fsFiberRXpower.1 = INTEGER: -207

(FS-FIBER-MIB::fsFiberRXpowerSign is completely useless since FS-FIBER-MIB::fsFiberRXpowerIntegerpart is already signed)

6

Thanks to you both for the pointers.

But as it turns out, there are variables returned that aren’t documented in the MIB… but appear to be the whole dBm scaled by 100, so I don’t think I’ll have to do anything special after all (I’ve opened a ticket with FiberStore to see if they have updated MIBs that document this - I think the alarm levels are in there too, and it’d be nice to be sure).

7

Oh, but there’s a problem… seems like discovery (at least from YAML) can’t handle the variables not being in the MIB. I tried:

    sensors:
        dbm:
            data:
                -   
                    oid: fsFiberTable
                    value: fsFiberEntry.76
                    num_oid: '.1.3.6.1.4.1.52642.1.1.10.2.105.1.1.1.76.{{ $index }}'
                    descr: "{{ $fsFiberPortDescr }} RX"
                    divisor: 100
                    low_warn_limit: fsFiberEntry.91
                    warn_limit: fsFiberEntry.92
                    low_limit: fsFiberEntry.93
                    high_limit: fsFiberEntry.94
                    skip_values:
                        -   
                            oid: fsFiberDDMSupportStatus
                            op: '='
                            value: 2
                        -   
                            oid: fsFiberEntry.76
                            op: '='
                            value: -10000

and that did not work. I’ve asked FiberStore for an updated MIB, but is there any relative easy way to handle this, other than just editing the MIB file?

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.