Currently I'm seeing an issue with UnDP wherein the Label function of an otherwise successfully imported OID is not applying the label I've set it up for.
Here's a known good:
OID 1.3.6.1.4.1.674.10892.5.4.600.12.1.5 -- PowerSupplyStatus for a Dell server.
I'm able to import the OID without issue, get values, and apply them to the web GUI for the server I'm working on. When I go to Label, I utilize the "Use labels from a table column" option, browse for the system I'm polling and test. The columns have the names listed at the top (powersupplyFQDD in this case is what I'm after) and I'm able to apply it just fine to the OID. Image attached as "PSU Labelling", with company-specific info redacted:
PowersupplyFQDD of course is also being imported (MIB Value of Raw, Text format, GET TABLE, and Node Polling -- PowerSupplyStatus runs almost the same settings, save the error codes have been enumerated). No problems, works great; and when I start making complex JOINS in SQL I can associate the label to the device, no problem.
Problems start in with a few other devices, though. A big one is 1.3.6.1.4.1.674.10892.5.5.1.20.130.4.1.31, otherwise known as, "physicalDiskSMARTAlertIndication" -- and in fact most of the status-based disk OIDs I've imported for Dell are having this issue. We're trying to label against any of the three viable OID imports (typically 1.3.6.1.4.1.674.10892.5.5.1.20.130.4.1.2 or PhysicalDevices), but as you can see all of the columns are just enumerated and fail to provide MIB names. (example attached as "Disk Labelling", again with company-specific info redacted). We've tried to approach this from a few different angles -- by Vendor, by Group, SysObjectID, etc. -- and all to the same effect. We can select the enumerated column showing the label data we want, but it never loads in correctly into CustomPollerLabels, and thus is that much more difficult to organize via SQL queries made for the Alert emails.
I've been poking around on Thwack and elsewhere and so far I haven't quite seen this problem mentioned. The fact it works for at least one OID pairing but not for others suggests a problem with the way the OIDs are handled, or perhaps I somehow found a bug related to OID import order. Orion Platform version of 2015.1.3, with a SQL 2012 backend and Windows 2012R2 hosts for both webserver and SQL server.
Anyone have any thoughts on this one? It's a bit of a stumper, admittedly.
