OpenNMS and WMI - Part 1, getting started

I’ve setup and used OpenNMS at my last job and my current job, and it works very nicely. One thing I haven’t done until last week, though, is get WMI monitoring/graphing working properly. WMI is the Windows Management Instrumentation API, and it gives you access to all sorts of internals on a Windows box. In my case, I want to access performance counters, particularly for IIS and ASP.NET.

Support for WMI is added in OpenNMS 1.7, which is still technically the unstable version – but it should be released as 1.8 any day now. I’d put it as late beta quality at worst, and if you’ve found this post via Google the final 1.8 version has probably already been released.

However, as 1.7 is still unstable, the documentation for all the new features, like WMI, is a bit sketchy. The OpenNMS wiki page is here, and it’ll get you about 80% through turning on WMI, but doesn’t really tell you what to do from there to actually start collecting data and setting up your own checks. Admittedly a lot of the OpenNMS documentation is like that, you have to rely a lot more on the examples and mailing list discussion than the formal documentation.

So, here’s a quick HowTo for getting WMI working with OpenNMS. I’m using OpenNMS v1.7.6 on a Ubuntu 9.0.4 box, and I’m assuming you already have everything working and just want to add WMI. All the code dependencies required for WMI (like the J-Interop libraries) are included with the OpenNMS Debian/Ubuntu packages, so I’m not going to get into that either, it’s all just configuration. All the files noted below are in your OpenNMS configuration directory, wherever that is on your system.

First, in collectd-configuration.xml, for the WMI service change the status from off to on.

Second, add credentials to wmi-config.xml for a user that is remotely allowed to access your servers and has permissions for WMI, which I think is the DCOM permission, but may require others. Note that, similar to the snmp-config.xml file, you can build config blocks based on IP ranges with different credentials – the docs are pretty clear about this part.

Third, if you prefer to use the poller for WMI, add these chunks of XML to poller-configuration.xml. Note that WMI monitoring is done through another mechanism, so the poller is not required. The first chunk goes inside a <package> definition.

        <service name="WMI" interval="300000" user-defined="false" status="on">
                <parameter key="retry" value="2" />
                <parameter key="timeout" value="3000" />
                <parameter key="matchType" value="all"/>
                <parameter key="wmiClass" value="Win32_ComputerSystem" />
                <parameter key="wmiObject" value="Status" />
                <parameter key="compareOp" value="EQ" />
                <parameter key="compareValue" value="OK" />
                <parameter key="service-name" value="WMI" />
        </service>

and this chunk goes near the bottom of the file with the other <monitor> definitions.

<monitor service="WMI" class-name="org.opennms.netmgt.poller.monitors.WmiMonitor" />

Update Oct 19: using the poller for WMI may cause a file descriptor leak that will cause your OpenNMS to hang and crash. Best not to add this.

Fourth, add the following XML chunk to the capsd-configuration.xml file, inside the <capsd-configuration> section.

<!-- WMI Monitoring -->
    <protocol-plugin protocol="WMI" class-name="org.opennms.netmgt.capsd.plugins.WmiPlugin" scan="on" user-defined="false">
        <property key="timeout" value="2000" />
        <property key="retry" value="1" />
        <property key="matchType" value="all"/>
        <property key="wmiClass" value="Win32_ComputerSystem" />
        <property key="wmiObject" value="Status" />
        <property key="compareOp" value="EQ" />
        <property key="compareValue" value="OK" />
        <property key="service-name" value="WMI" />
    </protocol-plugin>

I’m still not entirely sure when I need to restart OpenNMS to have it re-read configuration files, so at this point I’d recommend restarting, that will for sure re-read all the files. Assuming you have everything setup properly, the next time a services scan is done on your nodes the WMI service will be discovered, and start collecting data for the preconfigured WMI data sources (CPU, physical disk, logical disk, memory, system objects, network interfaces, Terminal Service, server sessions).

Next post will cover adding data collection and graphing for other WMI data that you’re interested in, using the examples that I wanted of HTTP requests and ASP.NET requests.