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 <DM> --subscribeProp=<yourClass>::.*::.*
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.
== Monitor your Smarts environment using APG ReportPack for Smarts health ==
Solutions Watch4Net Inc
APG & Smarts InCharge integration
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 <yourClass>
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 <your class>::<your instance>::<instrumented attribute>
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=<output file>
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.
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.
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.