WMI has finally come to OpenNMS.
In the feature-wmi branch I have added a capsd plugin, poller monitor and a
service collector. You can collect both single instance (e.g.
Win32_PerfFormattedData_PerfNet_Server) and multi-instance classes (e.g.
Win32_PerfRawData_Tcpip_NetworkInterface.) I have provided a couple sample
configurations in the branch that are, admittedly, pretty bland, but get
collection going.
To use this branch you will have to do the obvious compile and install and
then configure it as you would normally.
Next you will have to uncomment the WMI checks in capsd-configuration.xml
and poller-configuration.xml so that the service "WMI" gets discovered.
These are simple checks against Win32_ComputerSystem's Status object to
verify that you could connect via WMI and that the system is properly
running.
Next you will have to edit collectd-configuration.xml and set the WMI
service to a status of "on" (it is currently defaulted to off.)
Finally you will have to edit wmi-config.xml - this file mimicks the way
snmp-config.xml works, you can do ranges of IPs, a specific IP or defaults.
To get going the easy way edit the username, password and domain to fit that
of your environment. If you don't want to give your system access to your
whole domain you can specific a local user on a system by setting the domain
to the name of the system.
When you restart you should be able to monitor collectd.log to see that it
finds an active WMI service on your node and starts collecting data.
Things left to do:
* Add a web page to configure wmi-config.xml similar to that used to
specific SNMP communities.
* Add graph definitions and set it up so that graphs can be viewed online.
* Finish the tests - may require a refactoring of some of the low level
stuff (just providing an interface to separate J-Interop for testing, no
impact on users of the feature.)
* Document the system.
Technical details:
I created a WmiManager class which functions the same as the NsclientManager
class - you provide it with details and params to check against and it
provides you with the results and a service status (OK, CRITICAL, etc.) I
use this in the capsd and poller code and within collection I use it only to
verify the availability of a group of attributes. For example you'd set up a
WPM for SQL 2005 Express, it would check that the keyvalue exists and if so
start collecting the attributes (WMI properties.) Otherwise it won't waste
time on that group of WMI properties.
Everything else is done using the low-level WmiClient class. This class was
written to be generic and largely independent of the overall OpenNMS code.
You can do InstanceOf calls and Get calls (if you're familiar with the
SWbemServicesEx class.) I will be adding ExecQuery and ExecMethod (both to
WmiClient and to OnmsWbemObject) for future uses of WMI within OpenNMS. Also
I plan on implementing async event handlers for future Event Log retrieval.
Not saying WMI is done - just saying I've now seen it to 90% of the work we
require from it!
--
Matt Raykowski
/s
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-devel mailing list
To *unsubscribe* or change your subscription options, see the bottom of this
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
