snmp input plugin handling opaque type

[sarphram]

Feature Request

I'm currently pulling a lot of snmp data from a Synology NAS with telegraf v 1.2.1 and the new snmp plugin. Several points of data are returned as an opaque float:

snmpwalk -v 2c -c public nas .1.3.6.1.4.1.6574.4
<...>
SYNOLOGY-UPS-MIB::upsInfoLoadValue.0 = Opaque: Float: 9.000000 percentage 
<...>

Relevant sections from their MIB:

IMPORTS
  <...>
	Float 
		FROM NET-SNMP-TC
    MODULE-COMPLIANCE, OBJECT-GROUP
        FROM SNMPv2-CONF;
  <...>
upsInfoLoadValue OBJECT-TYPE
    SYNTAX     Float
	UNITS      "percentage"
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "Load on UPS (percent)"
    ::= { upsInfoLoad 1 }        
  <...>

Proposal:

Process the value returned and add it to the data output. I haven't found a way to handle it currently, hopefully I didn't miss something.

Current behavior:

The value seems to be dropped. Using the conversion option for the field doesn't seem to do anything.

Using a basic inputs.snmp config with this specific entry (is_tag is set to true to force output; if it's just a field nothing is output for this point)

  [[inputs.snmp.field]]
    name = "upsInfoLoadValue"
    oid = "SYNOLOGY-UPS-MIB::upsInfoLoadValue.0"
    is_tag = true

Produces this output
synology_ups,agent_hostname=nas,upsInfoLoadValue=<nil>,agent_host=nas,host=telegraf upsBatteryRuntimeValueSec=3270i 1490788434000000000

upsBatteryRuntimeValueSec is another OID I query for, but it returns as an INTEGER type.

Desired behavior:

Produce this output
synology_ups,agent_hostname=nas,agent_host=nas,host=telegraf upsInfoLoadValue=9.0000000 1490788434000000000

Use case:

Monitoring snmp data output in this format, though I'm not sure how common this is.

[phemmer]

Does it work if you do:

  [[inputs.snmp.field]]
    name = "upsInfoLoadValue"
    oid = "SYNOLOGY-UPS-MIB::upsInfoLoadValue.0"
    conversion = "float" # <-- this is the line to add
    is_tag = true

We can make this automatic if it does work. If it doesn't work, I'll try to duplicate the issue and see about adding a fix.

[sarphram]

No luck with the conversion line addition.

[sarphram]

I noticed the Need More Info label addition; I'd love to provide whatever info is needed. Do you need anything specific?

[phemmer]

Not sure why it has that label. I should be able to reproduce this locally (just haven't gotten to it yet). I don't think I need any additional info.

[GainfulShrimp]

I'm having this same problem, with the same Synology UPS OIDs, in fact.

[ryjogo]

Also having the same problems with this, is there any work around for now ?

[danielnelson]

If someone experiencing this issue can collect a packet capture then I will try to fix.

sudo tcpdump -s 0 -i eth0 -w 2590.pcap host 203.50.251.17 and port 161

[GainfulShrimp]

Having finally found the time for this, I have just tried to reproduce this again in order to grab a pcap file for @danielnelson ... but when I uncommented the parts of telegraf.conf that I'd had to get via script (because Telegraf wouldn't report them), when I restarted Telegraf service, I found the figures were getting populated in my InfluxDB!

> select hostname,upsBatteryCharge,upsBatteryRuntime,upsBatteryVoltage,upsInputVoltage,upsLoad from nas
name: nas
time                hostname    upsBatteryCharge upsBatteryRuntime upsBatteryVoltage  upsInputVoltage upsLoad
----                --------    ---------------- ----------------- -----------------  --------------- -------
1547206190000000000 DiskStation 100              3050              27.100000381469727 245             21
1547206200000000000 DiskStation 100              3050              27.100000381469727 245             21
1547206210000000000 DiskStation 100              3050              27.100000381469727 245             21
1547206220000000000 DiskStation 100              3050              27.100000381469727 245             21
1547206230000000000 DiskStation 100              3050              27.100000381469727 245             21
1547206240000000000 DiskStation 100              3050              27.100000381469727 245             21
1547206250000000000 DiskStation 100              3050              27.100000381469727 245             21
1547206260000000000 DiskStation 100              3050              27.100000381469727 245             21
1547206270000000000 DiskStation 100              3170              27.100000381469727 245             21
1547206280000000000 DiskStation 100              3170              27.100000381469727 245             21
1547206290000000000 DiskStation 100              3170              27.100000381469727 245             21
1547206300000000000 DiskStation 100              3170              27.100000381469727 245             21

I'm afraid I don't know whether this is due to a change at Synology's side, or an update to Telegraf since this issue was posted, but it looks like I can decommission my 'sellotape and string' snmpget+curl solution and get all my SNMP figures via Telegraf now, after all... nice. :)

I'm using Telegraf 1.9.2 and DSM 6.2.1-23824 Update 4, in case it helps anyone.

[phemmer]

Well one thing I just noticed in the original issue report is that the configured OID is incorrect.

The MIB file has ::= { upsInfoLoad 1 }, which synonymous with SYNOLOGY-UPS-MIB::upsInfoLoad.1. But the provided config has SYNOLOGY-UPS-MIB::upsInfoLoadValue.0.

The config should be: oid = "SYNOLOGY-UPS-MIB::upsInfoLoadValue"

[GainfulShrimp]

I don't think it was a config problem, as I ran into this puzzling issue quite independently from the OP and I tried both the numerical or name formats for the objects.

Older versions of Telegraf (or perhaps Synology DSM), would work OK for some of the SNMP stats provided by Synology NASes, but not all of them.

The ones that I had problems with - and thus used a script with snmpget+curl to push the values to InfluxDB - included the following (this is a snippet from my workaround script):

#UPS Load (percent) - SYNOLOGY-UPS-MIB::upsInfoLoadValue.0
syno_upsload=$(snmpget -v 2c -c $snmp_community $snmp_ip .1.3.6.1.4.1.6574.4.2.12.1.0 -OUqv)
#UPS Battery Charge (percent) - SYNOLOGY-UPS-MIB::upsBatteryChargeValue.0
syno_battcharge=$(snmpget -v 2c -c $snmp_community $snmp_ip .1.3.6.1.4.1.6574.4.3.1.1.0 -OUqv)
#UPS Battery Charge Low (percent) - SYNOLOGY-UPS-MIB::upsBatteryChargeLow.0
syno_battchargelow=$(snmpget -v 2c -c $snmp_community $snmp_ip .1.3.6.1.4.1.6574.4.3.1.2.0 -OUqv)
#UPS Battery Charge Warning (percent) - SYNOLOGY-UPS-MIB::upsBatteryChargeWarning.0
syno_battchargewarn=$(snmpget -v 2c -c $snmp_community $snmp_ip .1.3.6.1.4.1.6574.4.3.1.4.0 -OUqv)
#UPS Battery Voltage (Volt DC) - SYNOLOGY-UPS-MIB::upsBatteryVoltageValue.0
syno_battvoltage=$(snmpget -v 2c -c $snmp_community $snmp_ip .1.3.6.1.4.1.6574.4.3.2.1.0 -OUqv)
#UPS Input Voltage (Volts) - SYNOLOGY-UPS-MIB::upsInputVoltageValue.0
syno_inputvoltage=$(snmpget -v 2c -c $snmp_community $snmp_ip .1.3.6.1.4.1.6574.4.4.1.1.0 -OUqv)
#UPS Input Voltage Nominal (Volts) - SYNOLOGY-UPS-MIB::upsInputVoltageNominal.0
syno_inputvoltagenominal=$(snmpget -v 2c -c $snmp_community $snmp_ip .1.3.6.1.4.1.6574.4.4.1.4.0 -OUqv)
#UPS Input Transfer High (Volts) - SYNOLOGY-UPS-MIB::upsInputTransferHigh.0
syno_inputtransferhigh=$(snmpget -v 2c -c $snmp_community $snmp_ip .1.3.6.1.4.1.6574.4.4.2.3.0 -OUqv)
#UPS Input Transfer Low (Volts) - SYNOLOGY-UPS-MIB::upsInputTransferLow.0
syno_inputtransferlow=$(snmpget -v 2c -c $snmp_community $snmp_ip .1.3.6.1.4.1.6574.4.4.2.2.0 -OUqv)

[sarphram]

Some of the mibs Synology had on their site at the time were broken, so it's possible what I posted at the time was correct for the changes I made to the mib locally; it's also possible I had that line incorrectly configured. In my initial post, I trimmed down my config to show one specific example, but had multiple values at the time that weren't loading. I don't have access to the setup that originally prompted me to create the ticket so I can't verify that it's fixed for me, but it sounds like it is per @GainfulShrimp's update.