YAML Discovery

Help
1

I recently made a PR to add PSU sensor state support for Aruba switches. The PR can be found here:

PipoCaninja has stated that he’d like to add this support using YAML instead of PHP. I tried, but can’t get it to work. My YAML is as following:

sensors:
    sensors:
        pre-cache:
            data:
                -
                    oid:
                        - entPhysicalVendorType
                        - entPhySensorOperStatus
                        - entPhysicalName
    state:
        data:
            -
                oid: entPhysicalName
                value: entPhySensorOperStatus
                num_oid: '1.3.6.1.2.1.99.1.1.1.5.{{ $index }}'
                descr: entPhysicalName
                states:
                    - { descr: In Operation, graph: 0, value: 1, generic: 0 }
                    - { descr: Failed,       graph: 0, value: 3, generic: 2 }
#                skip_values:
#                    -
#                        oid: entPhysicalVendorType
#                        op: '!='
#                        value: iso.3.6.1.4.1.47196.4.1.1.2.1.3

However, when running discovery nothing is found. Debug output doesn’t give me any clues.
Can someone help me converting my PHP code to YAML?

2

Hi @Tozz
You could try this :

sensors:
    sensors:
        pre-cache:
#            data:
#                -
#                    oid:
#                        - entPhysicalVendorType
#                        - entPhySensorOperStatus
#                        - entPhysicalName
state:
        data:
            -
                oid: entPhySensorTable
                value: entPhySensorOperStatus
                num_oid: '1.3.6.1.2.1.99.1.1.1.5.{{ $index }}'
                index: 'operStatus.{{ $index }}'
                descr: '{{ $entPhysicalName }} status'
                states:
                    - { descr: In Operation, graph: 0, value: 1, generic: 0 }
                    - { descr: Failed,       graph: 0, value: 3, generic: 2 }
#                skip_values:
#                    -
#                        oid: entPhysicalVendorType
#                        op: '!='
#                        value: iso.3.6.1.4.1.47196.4.1.1.2.1.3

And let us know how it goes.

The OID in the data structure is the table that contains the value, and the value is the exact data you want to gather.

You can try without the precache (cause if I remember well, any OID in the table is already precached, that is the advantage of doing that).

1 Like
3

I’ve tried the code below, but without any luck. Discovery finds nothing.
Also… I worry this might not work because of an IF-clause in the discovery code:

In includes/discovery/sensors/entity-sensor.inc.php there is a line:

            // Check for valid sensors
            if (isset($entry['entPhySensorOperStatus']) && ($entry['entPhySensorOperStatus'] === 'unavailable' || $entry['entPhySensorOperStatus'] === 'nonoperational')) {
                $valid_sensor = false;
            }

Unless I’m mistaken, this code would remove my PSU sensor when I pull the plug and thus remove any active alerts.

sensors:
    state:
        data:
            -
                oid: entPhysicalTable
                value: entPhySensorOperStatus
                num_oid: '1.3.6.1.2.1.99.1.1.1.5.{{ $index }}'
                descr: entPhysicalName
                group: 'Power supplies'
                index: 'entPhySensorOperStatus.{{ $index }}'
                states:
                    - { descr: 'ok',             graph: 0, value: 1, generic: 0 }
                    - { descr: 'unavailable',    graph: 0, value: 2, generic: 3 }
                    - { descr: 'nonoperational', graph: 0, value: 3, generic: 2 }

If you agree with me that the line in entity-sensor.inc.php would remove any PSUs with the cable pulled that were added using YAML discovery, perhaps it’s best that we go ahead with my PR that uses PHP code?

4

Hi @Tozz
This sensors tells you if the PowerSupply “sensor” can be obtained successfully. It does not give you the actual status of the power supply. So the code looks correct.

An object using this data type represents the operational status of a physical sensor. The value 'ok(1)' indicates that the agent can obtain the sensor value. The value 'unavailable(2)' indicates that the agent presently cannot obtain the sensor value. The value 'nonoperational(3)' indicates that the agent believes the sensor is broken. The sensor could have a hard failure (disconnected wire), or a soft failure such as out- of-range, jittery, or wildly fluctuating readings.

May be you are not trying to read correctly the sensor value here. PHP or YAML does not make a difference here.

5

Unfortunately that information seems to be incorrect for this specific switch. Here is a diff from the 2 snmpwalks. One with all PSUs okay and the other with the cord pulled on one of the PSUs:

> RFC1271-MIB::logDescription.301.4 = STRING: "|301|LOG_INFO|CDTR|1|PSU 1/2 changed state to Output Fault"
13073a13081
> RFC1271-MIB::logDescription.304.2 = STRING: "|304|LOG_ERR|CDTR|1|PSU 1/2 faulted. Total fault count: 1"
15947c15960
< ENTITY-SENSOR-MIB::entPhySensorOperStatus.107401 = INTEGER: ok(1)
---
> ENTITY-SENSOR-MIB::entPhySensorOperStatus.107401 = INTEGER: nonoperational(3)
16057c16070
< ENTITY-STATE-MIB::entStateOper.113002 = INTEGER: enabled(3)
---
> ENTITY-STATE-MIB::entStateOper.113002 = INTEGER: disabled(2)

The PSU was still physically in the device. So I did not remove the PSU itself. I only pulled the power cord.

6

Regardless, I’d prefer to stay with my PR Add PSU state sensor support for ArubaOS-CX & add serial and firmware by rudybroersma · Pull Request #15687 · librenms/librenms · GitHub as it is now with PHP code

If you could approve that PR I’d be grateful, I’ll start to work on the next one :slight_smile:

7

All right, so this device is not implementing correctly the MIB. I’ll review the PHP variant in github.
Bye

8

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