Locked
Discussion interactions are currently paused.
device model templates
AD is nice, but sometimes AD leads to missing warnings for elements not present but that probably should be. Having a minimum required device template of some sort could help avoid this, but I am not sure (yet) of a good approach here that doesn't end up with a lot of error-prone manual effort. I do know the fact that this missing power supply in a stack is not reported as a problem is wrong, though.
FAN 1 is OK
FAN 2 is OK
FAN PS-1 is OK
FAN PS-2 is OK
SYSTEM TEMPERATURE is OK
System Temperature Value: 28 Degree Celsius
System Temperature State: GREEN
Yellow Threshold : 46 Degree Celsius
Red Threshold : 60 Degree Celsius
SW PID Serial# Status Sys Pwr PoE Pwr Watts
--- ------------------ ---------- --------------- ------- ------- -----
1A C3KX-PWR-715WAC LIT15300JR3 OK Good Good 715/0
1B C3KX-PWR-715WAC LIT15300JQ8 OK Good Good 715/0
2A C3KX-PWR-715WAC LIT15300JML OK Good Good 715/0
2B UNKNOWN unknown No Input Power Bad N/A 0/0
3A C3KX-PWR-715WAC LIT15300JQY OK Good Good 715/0
3B C3KX-PWR-715WAC LIT15300JSY OK Good Good 715/0
Thanks,
Mark
mnagel
Posted 9 years ago·Last reply 9 years ago
2 comments
mnagel
OP9 years agoYes, something like this could work. I was trying to think of something that did not include datasource applies-to-partitioning since I find that to be a source of serious headache -- difficult to maintain, difficult to know what applies to what without deep diving, and due to lack of inheritance it is too easy to create semantic divergence where there should not be any. You are probably right that this is all I will be able to do at this time, was just trying to think of a method that didn't further encourage that methodology.
Thanks,
Mark
Matthew_Dunham
·9 years agoHi Mark -
If I understand your situation correctly, this use-case could be addressed with a PropertySource targeted at the specific device class coupled with a singleton (non-AD) DataSource designed to collect data from each of the expected FRU modules.
In this case, you'd write a PropertySource that would specifically identify the device in question and and assign a targeted system.category (e.g. "CiscoCatalyst3750"). Then you could write/modify a single-instance DataSource -- which apply only to "CiscoCatalyst3750" -- that would specify as datapoints from each of the known FRUs in a 3750. By having the datapoints alert on a NoData condition, any C3750 with a FRU that wasn't responding would trigger an alert as expected.