The Win32ServiceMonitor (in OpenNMS since release 1.3.10) enables OpenNMS to monitor the running state of any Windows service, even ones that do not provide a service on the network, as long as the Windows system has the Microsoft SNMP service installed and correctly configured.
The default capsd configuration includes an example of using the Win32ServicePlugin to discover the Task Scheduler service, and the default poller configuration includes the corresponding definition to monitor this service once it is discovered.
To configure discovery of additional Windows services, you need to edit the
$OPENNMS_HOME/etc/capsd-configuration.xml file and add a protocol-plugin definition for the service you would like to monitor. Here is the relevant section of
capsd-configuration.xml to enable the discovery of the Task Scheduler service:
- note when you are adding the value for "service-name", you need to use the windows "Display name" of the service, rather than the actual "Service name", this field can be found in the Window Computer Management MMC (Microsoft management console). You can also get the list by SNMP walking .220.127.116.11.18.104.22.168.22.214.171.124 (LanMgr-Mib-II-MIB::svSvcOperatingState).
<protocol-plugin protocol="Windows-Task-Scheduler" class-name="org.opennms.netmgt.capsd.plugins.Win32ServicePlugin" scan="on" user-defined="false"> <property key="timeout" value="2000" /> <property key="retry" value="1" /> <property key="service-name" value="Task Scheduler" /> </protocol-plugin>
In order to poll the running state of a service that has been discovered, you must also edit the
OPENNMS_HOME/etc/poller-configuration.xml file and add both a service (in one or more poller packages) and a monitor (at the bottom of the file). Here is the service definition for the Task Scheduler service:
<service name="Windows-Task-Scheduler" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="port" value="161"/> <parameter key="service-name" value="Task Scheduler"/> </service>
And here is the corresponding monitor definition, which tells the poller daemon which class to use to poll this service:
<monitor service="Windows-Task-Scheduler" class-name="org.opennms.netmgt.poller.monitors.Win32ServiceMonitor"/>
Like all monitors, the service tag can take a number of parameters:
- the name of the service in OpenNMS, this must be the same as the service name specified in capsd-configuration.xml.
- how often (in milliseconds) to perform a poll using this monitor
- whether or not this service is user-defined, used primarily in the UI
- whether or not the monitor is enabled
Win32ServiceMonitor also takes the following monitor-specific parameter:
- the name of the service, this should be the exact name of the Windows service to monitor as it appears in the Services MSC snap-in (short names such as you might use with net start will not work here)
Since the Win32ServiceMonitor simply extends the SnmpMonitor to simplify configuration, the Win32ServiceMonitor recognizes and will use any parameters supported by the SnmpMonitor. The two exceptions are that the oid, operator, and operand values will be ignored if they are specified for the Win32ServiceMonitor.
The service-name in other language than english is sometime encoded. Like in french, the "Task Scheduler" service is "Planificateur de tâche". Because of the "â" (non-english caracter), the OID value is encoded in hexa (0x50 6C 61 6E 69 66 69 63 61 74 65 75 72 20 64 65 20 74 C3 A2 63 68 65 73).
If you've created a Win32ServiceMonitor poller and are having difficulties with it not being discovered on your hosts, chances are there is a difference in the name of the service you've created, and the actual name in the registry.
For example, I need to monitor a process called "Example Service" on one of our production servers. I retrieve the "Display name" from looking at the service in service manager, and create an entry in the capsd-configuration.xml and poller-configuration.xml files using the exact name in the "Display name" field. However, what I don't see is the errant space at the end of the service display name that is revealed when doing the following:
snmpwalk -v 2c -c <communitystring> <hostname> .126.96.36.199.188.8.131.52.184.108.40.206
This provides the critical piece of information I am missing:
iso.220.127.116.11.18.104.22.168.22.214.171.124.126.96.36.199.188.8.131.52.184.108.40.206.220.127.116.11.18.104.22.168.22.214.171.124.126.96.36.199.110.100.32 = STRING: "Example Service " <-- Note the extra space before the close quote.
The extra space at the end of the name was difficult to notice in the service manager GUI, but is easily visible in the snmpwalk output. The right way to fix this would be to correct the service "Display name" field on the server, however, the intent of this procedure is to recommend verifying the true name using snmpwalk as opposed to relying on the service manager GUI.
- This feature was added in version 1.3.10