This post is more than 5 years old
10 Posts
0
2997
Trouble with Dynamic Model Instrumentation
Hi,
I've been trying to write a new model so that our Smarts implementation can correctly poll our Powerware UPS' as a UPS not Hosts and return details such as BatteryCapacity, BatteryTimeRemaining, AmbientTemperature, etc.
When the NRM domain starts up, it loads the dynamic model and the UPS is correctly discovered as a UPS, an instrumentation object is created. When I run the load_accessor.asl (based off the one in Example 3 of the tutorial) to insert the instrumentation object into the instance_instrumentations property of the SNMPAccessor object, I get no errors but nothing is updated and after that, nothing is polled.
I created an event in the instrumentation class for HighTemp and subscribed the SAM domain to this event in the dxa-net-rm-conn-perf.conf file but still no polling is happening.
Does anyone have any clues they can give me to get this polling going? I've searched for as much doco as I can find on dynamic modelling but have had no luck. This model is being tested on a new IP/SAM v8.1 deployment if that makes any difference to the solution and I've attached my current mdl file.
Thanks,
Dan Major.
bkuhhirte
52 Posts
0
March 4th, 2010 11:00
Dan,
Sadly the issue is quite a bit simpler than that - your MODEL file didn't export the event itself. Unexported events cannot be subscribed to, but this in itself is a pretty easy thing to check for - just run:
dmctl> getE
This will show a list of the currently exported events for a given class. As a semantic note, your event guard isn't particularly functional. You may consider removing it since both what it is evaluating and the guard use the same property. The purpose of the guarded event expression is to avoid checking a particular attribute if it cannot be evaluated. This causes a condition known as suspension in our platform where the event cannot be evaluated and may cause downstream problems for people attempting to use it.
Since the general problem you described is something that happens even to experienced developers, below is a quick summary of some troubleshooting steps I use myself to make sure that everything is working properly.
1. Make sure the event is exported
2. Make sure that the event is actually subscribed
If the event isn't subscribed, we determine that none of the instrumented properties required to support that event are necessary and thus not polled.
3. Attempt to fetch the attribute directly through dmctl.
This is an underutilized techniqe. Attempting to fetch the attribute will actually return either the current value *or* the current error in fetching the attribute. This will quickly highlight mismatches in data types, lack of subscription, bad index from SNMP, etc.
dmctl> get :: ::
4. Dumping the accessor cache may reveal polling problems.
We occasionally have issues with SNMPv1 agents (which most UPS systems have) since the protocol can only return a single error message per packet and we may attempt to request as many as 19 MIB values in a single request. As a result, if the agent objects to one, we get an error for all of them. To look at the cache, just run:
dmctl> exec dmdebug --dumpAccessor --output=
This will generate a file in $SM_SITEMOD/logs/ with the output listed by accessor. Look for SNMP (typically DEVSTAT_SNMP_POLLER) in the file to highlight our SNMP poller.
5. Simplify!
Try and make your initial MODEL as simple as possible to verify that all is work - especially with SNMPv1 agents. A single bad attribute can befoul everything you are doing and take hours to troubleshoot.
6. Mind the data types.
Not all attributes will map to the same type in MODEL. There is a section in the MODEL Reference Guide that describes how the various SNMP data types map to MODEL data types. Getting those wrong will produce a similar appearing lack of polling.
6. Make liberal use of the setTrace MODEL operation for the ICIP_SNMPAccessorInterface class. This will allow you to perform packet level tracing of the SNMP messages in the system. This is greatly improved in IP 8.1 allowing you to trace down to a single object within the system that is being polled.
Regards,
Bill
DanMajor
10 Posts
0
February 15th, 2010 13:00
Just a small addition.
The event listed in the attached mdl file is an old event declaration. The one currently running on the server is as follows:
Dan.
FredericMeunier_0588be
143 Posts
0
February 17th, 2010 11:00
Hi Dan,
if I remember well, I think there is an issue with the event's "automatic" subscription ... I think (that's what I'm doing as a workaround and I never tested it against new IP releases) that you have to subscribe directly to these attributes. So, to be sure, can you try subscribing to one or all your polled attrubutes, something like:
echo | /opt/InCharge7/IP/smarts/bin/sm_adapter -s --subscribeProp= ::.*::.*
than wait a little bit (twice the polling cycle you have put in the instrumentation) and see if you have your metrics. It should work. If it works, then you can setup an internal subscriber which will be used at startup. I'll be able to show you how to setup this if you have your metric using the sm_adapter command.
HTH,
--Fred
== Monitor your Smarts environment using APG ReportPack for Smarts health ==
Frederic Meunier
Solutions Watch4Net Inc
APG & Smarts InCharge integration
http://www.watch4net.com
DanMajor
10 Posts
0
February 27th, 2012 20:00
Thanks for the input Bill.
I ended up rewriting the model just about completely and we now have it instrumented and polled nicely using three separate model files for the UPS class, the UPS_Instrumentation class, and the UPS_Threshold_Setting class. Along with these we used an asl script to parse the snmp walk, modified the DISCOVERY_Field.import file to instantiate our GA_Driver::Containment-Powerware-UPS-Details-Driver to poll the right attributes, Containment tabs specific to the new UPS attributes and of course the step that kept catching us, subscribed to it in the dxa files for the SAM domain.
Thanks,
Dan.