What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Custom Lookup Values Issue

Votes:

0

We have recently installed a new SAN (Infortrend), and as such are looking for a way to monitor the drive status through SNMP, so we know when there's a fault disk. Now, we have the mib file, and according to the 'Disk State' OID, it returns the following Values; 

Hard disk drive status 
0 : New Drive 
1 : On-Line Drive
2 : Used Drive 
3 : Spare Drive 
4 : Drive Initialization in Progress 
5 : Drive Rebuild in Progress
6 : Add Drive to Logical Drive in Progress 
9 : Global Spare Drive 


0x11 : Drive is in process of Cloning another Drive 
0x12 : Drive is a valid Clone of another Drive 
0x13 : Drive is in process of Copying from another Drive (for Copy/Replace LD Expansion function) 
0x3f : Drive Absent 0x8x: SCSI Device (Type x) 
0xfc : Missing Global Spare Drive 
0xfd : Missing Spare Drive
0xfe : Missing Drive 
0xff : Failed Drive

Because of the way the return values are formatted with the errors (0x##), i have created a custom lookup, the report values 1-9 as their respective status, but left the rest as 'undefined', and to create an error on receiving an undefined value: 

<?xml version="1.0" encoding="UTF-8"?>
<ValueLookup id="prtg.customlookups.ifhdd.status" desiredValue="1" undefinedState="Error" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PaeValueLookup.xsd">
	<Lookups>
		<SingleInt state="Ok" value="0"> New Drive Inserted </SingleInt>
		<SingleInt state="Ok" value="1"> Drive Online</SingleInt>
		<SingleInt state="Ok" value="2"> Used Online</SingleInt>
		<SingleInt state="Ok" value="3"> Spare Drive</SingleInt>
		<SingleInt state="Ok" value="4"> Drive Initialization In Progress</SingleInt>
		<SingleInt state="Ok" value="5"> Rebuild In Progress</SingleInt>
		<SingleInt state="Ok" value="6"> Adding Drive to Logical Drive</SingleInt>
		<SingleInt state="Ok" value="9"> Global Spare Drive</SingleInt>
	</Lookups>
</ValueLookup>

However i have 2 problems;

  1. : The undefined statuses dont return an error, they just list as ok and undefined
  2. : The custom lookup i set only lasts for a single poll of the sensors. Once they poll, they remove the lookup value settings and continue returning the values again?

Can anyone help with this? Or know of an easier way of accomplishing this?

custom-lookup prtg snmp

Created on Jun 22, 2018 3:47:08 PM

Last change on Jun 25, 2018 5:25:48 AM by Luciano Lingnau [Paessler]



4 Replies

Accepted Answer

Votes:

0

Hello Tom-Neale,
thank you for your inquiry.

I have addressed your questions below. However, first allow me to point out that I find it extremely unusual that the vendor implemented a MIB that returns both numerical/integer values and hexadecimal-encoded values (strings) in the same OID. Maybe it's just an issue with the MIB documentation. This would make more sense.

Regarding the reported issues:

1.: The undefined statuses dont return an error, they just list as ok and undefined

I wasn't able to reproduce this with PRTG Version 18.2.41.1652 using your lookup file. Please make sure that you're running this version and that the issue persists. As soon as a value outside the lookup range arrives, I get the expected error.

Error

2.: The custom lookup i set only lasts for a single poll of the sensors. Once they poll, they remove the lookup value settings and continue returning the values again?

Please note that when working with Advanced (SNMP Custom Table, SNMP Custom Advanced, SQL V2, ...) sensors you need to configure the lookup in the Sensor Settings and not in the channel settings. Otherwise it gets overwriten on every interval.

Please refer to the hint here:

Edit:: I've tested this out with a "0x11" response within an ASN_OCTET_STR, and PRTG was able to decode it as 17. This is a new feature, and may not work in older versions. But this means that you could enter the corresponding decimal values in the lookup and PRTG will able to display the hexadecimal-encoded values (and corresponding statuses) as well.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jun 25, 2018 8:03:51 AM by Luciano Lingnau [Paessler]



Votes:

0

Hi Luciano,

Yes, it is strange i know, which is why im having to go about the monitoring of the drives this way. Haven't had the need for the custom lookups until now!

Thanks for that! Okay so, i was configuring the Value Lookup in the channel settings not in the sensor! Ive configured the lookup in the sensor and everything works.

In regards to the edit, can i ask how you tested this? I can see the strings are returning values to prtg (0xfe - Missing Drive is returning value 63) and i would prefer to configure a lookup for each value. However im not sure how to test which error codes return which values, without somehow triggering an event of each?

Thanks again for the help!

Tom

Created on Jun 25, 2018 8:23:50 AM



Votes:

0

Hello Tom,
thank you for the swift reply.

In regards to the edit, can i ask how you tested this? I can see the strings are returning values to prtg (0xFE - Missing Drive is returning value 63) and i would prefer to configure a lookup for each value. However im not sure how to test which error codes return which values, without somehow triggering an event of each?

I've tested this with our internal device emulator. If you can confirm that this is working for you as well, simply add the missing lookups in your lookup-file. For instance, for 0xfe find the corresponding decimal value (for example, here).

Then, add the corresponding lookup entry:

[...]
<SingleInt state="Error" value="254">Missing Drive</SingleInt>
[...]

And that's all there is to it. After a "Load Lookups and File Lists", (Setup > Administrative Tools) the lookup should be able to translate the new stati as well.

But indeed, you won't be able to test this unless the device indeed reports the status in question. But if it works for one, it should work for all. And worst case scenario, if the value can't be decoded (or gets decoded incorrectly) is that the sensor will go down because of the undefineState in the lookup.

Ps.: I've checked with the responsible developer, and this unannounced feature (this hasn't been officially released yet) of decoding the incoming hex value is still being tweaked, so caution is advised when using this (for now). But since you have the undefineState in the lookup, you should be fine if something goes wrong. But should you observe any unexpected behavior, please let us know.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jun 25, 2018 9:02:14 AM by Luciano Lingnau [Paessler]



Votes:

0

Hi Luciano,

Thanks for the help. I think i may have to wait until each state has occurred to create custom look-ups for them all. The hex converter i had already tried with 0xfe - which translates to 254 as you mention. However, PRTG translates sees this value as 63, so not sure how its translating.

No worries! My original Question has been answered so, thanks for the help :)

Regards,

Tom

Created on Jun 25, 2018 9:09:31 AM




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.