Best way to deal with "dynamic" SNMP data
I think this may be a bit of a unique scenario but I also think there might be a better way to deal with this than what I've tried so far.
We're setting up LM to monitor a Crestron control system using their SNMP interface. Crestron supports some of the standard SNMP MIBs for reporting health of the control processors (e.g. Host Resources etc.) and then has a separate "IO" MIB that allows for reporting the status of various devices/systems that the control processors interface with.
The main part of that MIB that I'm working with is essentially a table of status parameters (DataPoints in LM lingo), with each entry having some info about the parameter like the name of the parameter and the associated device, the current status, high/low value descriptions, etc.
Couple simplified examples for purposes of this discussion:
Table Entry 1
- "Audio System" <-- Device name
- "Online Status" <-- Parameter name
- 1 <-- current status
- "Online" <-- "1" description
- "Offline" <-- "0" description
Table Entry 2
- "Projector x" <-- Device name
- "Power Status" <-- Parameter name
- 0 <-- current status
- "On" <-- "1" description
- "Off" <-- "0" description
My initial approach was just based on an SNMP DataSource with ActiveDiscovery. This works okay but then the DataPoint on every instance is just "Status" and I can't set different thresholds depending on the parameter name (afaik). Based on the above examples, I would want different thresholds for Online Status vs. Power Status.
Specific question related to this: is there any way to set a DataPoint name and/or DataPoint thresholds based on data from Active Discovery (i.e. instance properties)?
Any other ideas for the SNMP approach?
The second option I'm trying is using a script-based DataSource where the script returns the proper DataPoint name/values (e.g. "Online Status=1"). In this scenario, I can make different DataPoints with different thresholds depending on the parameter. The issue I run into is that every instance will show all of the possible DataPoints for any instance whether they apply or not. This is slightly better than the previous scenario but we still end up with more noise/confusion than desired.
Specific question related to this: is there any way to enable/disable or show/hide DataPoints on a per-instance level based on data from Active Discovery?
Any other ideas on the script-based approach?
If you've made it this far, thanks for taking the time!
LM User
·2 years agoI'm not finding a table in the MIB that has 5 fields as shown in the example above. I'd need an snmp walk of .1.3.6.1.4.1.3212.7.1.3.2.2.1.1 to be able to write the example. The MIB is horribly written, using "Description." in every description field, so it's really difficult to know what kind of data all the fields would have. Manoj_Hegde, do you have one of those devices? Could you do an SNMP Walk through the collector debug console and post the output (sanitized if necessary)? I suspect the names "Audio System" and "Projector x" are located somewhere else in the MIB but I don't see them. The snmp walk output will help understand what is actually there.
LM User
·2 years agoProbably one of the ones here:
Notifications has traps. Conformance is for SMI conformance. The RW entries are the same thing as the RO entries, just with the ability to write a value (Bad Creston, take an SNMP 101 course).
If i get bored later, I'll write up a discovery script using my templates.
Manoj_Hegde
·2 years agoThank you very much
LM User
·2 years agoClosest I could find was 1.3.6.1.4.1.3212.7.1. Not sure which child in there has the data.
Manoj_Hegde
·2 years agoHi Martin, may i know which datasources or MIB you are using for Crestron devices?
LM User
·4 years agoCrestron should not do it this way. Bad Crestron. I'll assume they have a reason for not doing SNMP they way it's supposed to be done. Rant over.
What you want is a multi-instance datasource with active discovery.
Given that each row is uniquely identified using the first two fields in each entry, you'll probably need to use scripted discovery. Your script should do a walk of the entire table of entries and output a single line for each entry. Each line will have two terms: 1) WILDVALUE and 2) WILDALIAS.
WILDVALUE: The wildvalue is going to be the unique identifier for the entry. It should be the tail end of the OID containing the status value when you walk the entries table.
WILDALIAS: This is simply the display name of your instance, which will probably be a concatenation of the parameter name and device name
If you provide the OIDs for your two examples (or the output of an SNMP walk on that entry table), I can show you what the output of your discovery script should look like.
After that, your collection shouldn't have to be scripted, you should be able to use simple SNMP collection. You'd create a single datapoint for status and the OID would be 1.3.6.1.4.1.a.b.c.d.e.f.X.##WILDVALUE## where 1.3.6.1.4.1.a.b.c.d.e is the OID for the table of entries and X is the leaf where the status value lives.