Cannot use oidname in snmp config

[agross]

Bug report summary

I try to use the documented oidname setting of snmp.conf to monitor a number of SATA disk temperatures of a Synology DiskStation, but the names show up as NaN.

OS / Environment

Fedora 28

Component Name

node.d (?) snmp

Steps To Reproduce

1. Set up SNMP server
2. Define SNMP config with oidname: snmp.conf
3. Run /usr/libexec/netdata/plugins.d/node.d.plugin 1 snmp My output:

$ /usr/libexec/netdata/plugins.d/node.d.plugin 1 snmp
2018-10-28 22:45:56: node.d.plugin: ERROR: Cannot read user-configuration file /etc/netdata/node.d.conf: ENOENT: no such file or directory, open '/etc/netdata/node.d.conf'.
CHART "NAS.disk-temperatures" "NAS.disk-temperatures" "Disk temperatures" "celsius" "temperature" "" "line" 50001 10
DIMENSION "disk1" "NaN" "absolute" 1 1
DIMENSION "disk2" "NaN" "absolute" 1 1
DIMENSION "disk3" "NaN" "absolute" 1 1
DIMENSION "disk4" "NaN" "absolute" 1 1
DIMENSION "disk5" "NaN" "absolute" 1 1
DIMENSION "disk6" "NaN" "absolute" 1 1
DIMENSION "disk7" "NaN" "absolute" 1 1
DIMENSION "disk8" "NaN" "absolute" 1 1
DIMENSION "disk9" "NaN" "absolute" 1 1
DIMENSION "disk10" "NaN" "absolute" 1 1
DIMENSION "disk11" "NaN" "absolute" 1 1
DIMENSION "disk12" "NaN" "absolute" 1 1
BEGIN NAS.disk-temperatures
SET disk1 = 33
SET disk2 = 31
SET disk3 = 36
SET disk4 = 32
SET disk5 = 33
SET disk6 = 32
SET disk7 = 36
SET disk8 = 35
SET disk9 = 36
SET disk10 = 34
SET disk11 = 35
SET disk12 = 31
END

Expected behavior

Dimensions show up as disk names, not NaN.

[agross]

I created a debug log. It seems like this if statement doesn't branch correctly, see lines such as this (I highlighted the important parts with **:

found snmp value of OIDs 1.3.6.1.4.1.6574.2.1.1.3.4, ObjectType **OctetString **(4), typeof(object), in JSON: <Buffer 53 54 31 30 30 30 30 56 4e 30 30 30 34 2d 31 5a 44 31 30 31 20 20 20 20>, value = NaN (**parsed as float in string**)

[agross]

Yep, the if checks for equality totitle, but it should also check for equality to name.

[agross]

Also it seems that the chart don't get drawn correctly when dimensions share a name (e.g. when you have multiple disks of the same model like I have:

DIMENSION "disk1" "ST10000VN0004-1ZD101    " "absolute" 1 1
DIMENSION "disk2" "ST10000VN0004-1ZD101    " "absolute" 1 1
DIMENSION "disk3" "ST12000VN0007-2GS116    " "absolute" 1 1
DIMENSION "disk4" "ST10000VN0004-1ZD101    " "absolute" 1 1
DIMENSION "disk5" "ST10000VN0004-1ZD101    " "absolute" 1 1
DIMENSION "disk6" "ST10000VN0004-1ZD101    " "absolute" 1 1
DIMENSION "disk7" "ST12000VN0007-2GS116    " "absolute" 1 1
DIMENSION "disk8" "ST12000VN0007-2GS116    " "absolute" 1 1
DIMENSION "disk9" "ST12000VN0007-2GS116    " "absolute" 1 1
DIMENSION "disk10" "ST12000VN0007-2GS116    " "absolute" 1 1
DIMENSION "disk11" "ST12000VN0007-2GS116    " "absolute" 1 1
DIMENSION "disk12" "ST10000VN0004-1ZD101    " "absolute" 1 1

I have 12 disks comprised of two models. Only two temperatures where shown on the web UI.

[ktsaou]

fixed with PR #4498

[agross]

@ktsaou I'd say it's partly fixed. When dimension names are repeated (e.g. in my case disk models) you'll get only one graph/value per model. Not sure this is even supported, but I was under the impression that is is because the dimension names from my config show up:

DIMENSION "disk1" "ST10000VN0004-1ZD101    " "absolute" 1 1
DIMENSION "disk2" "ST10000VN0004-1ZD101    " "absolute" 1 1

Here's a live example: https://netdata.home.therightstuff.de/#menu_Sensors;theme=slate;help=true;update_always=true

[ktsaou]

hm... this seems a dashboard bug. The dashboard uses the name as the key, but multiple dimensions have the same name...

hm... names should be unique though. So, the second dimension with the same name should fail to get that name... So, this could be a netdata daemon bug that allowed the same name more than once.

You have assigned these names to the disks manually or do they come from the SNMP server?

This needs some more testing. Could you please open a new bug report with a screenshot of the chart? I can't check it now, but this is nasty and has to be fixed...

[agross]

4520