Try   HackMD

WinRM in OpenNMS

WSMAN support has been present in OpenNMS for a while. The primary motivator for adding support to this was Dell iDRAC. Still, it is Microsoft Windows infrastructure, the one that can have more benefits from it, as an alternative of SNMP to gather statistics from Windows.

Through WinRM, everything exposed by WMI is accessible (if the user has the right permissions), which makes it a more attractive solution than using WMI directly.

The challenge is always how to configure the Windows Infrastructure in terms of user authentication easily. Fortunately, thanks to Active Directory, we have GPOs (Group Policy Objects), which we can use to configure a set of Windows machines from a central place.

Traditionally, WinRM (which stands for Windows Remote Management) is just a tool used by PowerShell to have remote access to a Windows machine to perform administrative tasks. For this reason, the protocol and access to WMI statistics require administrators privileges.

That said, when speaking about monitoring Windows infrastructure, there is no need to have a privileged account, as the purpose of a monitoring tool is only to read statistics, and never perform changes.

Using an administrator account makes monitoring easy, but it could be a security breach. That has been the reason why the usage of WMI Tools in OpenNMS is rare, as the credentials are in plain text inside a configuration file.

Fortunately, to use WinRM, Kerberos has to be the algorithm to use when using Domain Accounts, as basic authentication is only allowed for local administrators. If Active Directory and GPOs are going to be used to facilitate deployment, for sure, we can use Domain Account for WinRM, so Kerberos is going to be mandatory.

With Kerberos, OpenNMS, and the WSMAN library use GSS to negotiate authentication, and the only requirement is having an initialized KeyTab. That means there is no need to store the credentials in plain text on a configuration file. Of course, we must protect the KeyTab file to make sure it won't be misused to compromise the Windows infrastructure.

Using privileged Domain Account (or accounts with administrator access) can make the Windows Administrators nervous, so it is reasonable to consider using a non-domain account.

In terms of WinRM access, this is entirely possible, but the problem is going to be having access to WMI.

The changes required to allow a non-admin account to perform WMI queries cannot be done through a GPO directly. That means this GPO would have to distribute a PowerShell script that executed through the Task Manager, to perform all the changes required locally to allow non-admin users to have access to WMI, as explained in this article.

This article is not about explaining how to configure the Domain Account, is about configuring WinRM with Kerberos on Linux to monitor Windows Server using OpenNMS. For this reason, we won't cover those details in this document, and all the upcoming content assumes that there is an account with WinRM and WMI access (regardless if it is an administrative account or not).

DNS

To use Kerberos, DNS should be working correctly on the Linux machine where OpenNMS is running; otherwise, we cannot test connectivity, verify authentication, and use WSMAN in general.

Usually, the OpenNMS server has to use the same DNS used by the Domain Controller, and it should be able to perform forward and reserve lookups against any Windows Server that OpenNMS monitors.

That is very important for the following reason:

Kerberos only work with FQDNs, not IP addresses, while OpenNMS only work with IP addresses not FQDNs

That might sound contradictory, but fortunately, that is not the case, and DNS plays an important role here.

Because when performing any Kerberos related operation, we must use FQDNs, the DNS should be able to translate FQDNs to IP addresses adequately, the same way the Domain Controller would do it.

When configuring OpenNMS, usually through requisitions, the operator declares nodes and set at least one IP Address to the node. Usually, this IP is marked as primary if SNMP is available. Still, with WSMAN/WinRM, a reverse lookup against that IP must resolve to the same FQDN used by the Domain Controller to recognize the Windows machine in question; otherwise, Kerberos authentication is going to fail.

In other words, the WSMan library within OpenNMS translates that IP into an FQDN, and if that operation succeeds, it uses that hostname to perform the WinRM request, and Kerberos works if the FQDN is valid from Active Directory's perspective.

Here is a simple example:

Let's say that we have a domain called mynet.local, and the server that it is required to access is called winsrv01, so its FQDN would be winsrv01.mynet.local.

The following is how to validate if DNS works on the OpenNMS server:

















[root@opennms ~]# cat /etc/resolv.conf
search mynet.local
nameserver 172.31.0.10

[root@ip-172-31-0-200 ~]# nslookup winsrv01.mynet.local
Server: 172.31.0.10
Address: 172.31.0.10#53

Name: winsrv01.mynet.local
Address: 172.31.0.100

[root@ip-172-31-0-200 ~]# nslookup 172.31.0.100
Server: 172.31.0.10
Address: 172.31.0.10#53

100.0.31.172.in-addr.arpa name = winsrv01.mynet.local.

Make sure to install the bind-utils RPM package to use the nslookup command.

As shown in the above output, both a forward and a reverse lookup are working. That means, the requisitioned node should use that IP to detect and collect data through WSMAN using WinRM, for example:







<node node-label="winsrv01.mynet.local" foreign-id="winsrv01" building="HQ">
  <interface snmp-primary="P" status="1" ip-addr="172.31.0.10"
    descr="Interface that resolves to winsrv01.mynet.local">
    <monitored-service service-name="WS-Man"/>
  </interface>
</node>

The node should only have the interface marked as primary only when using SNMP. Also, there is no need to force the WS-Man service. That was to demonstrate how to define the node properly.

Verify connectivity using the wsman CLI

For simplicity, I'm going to assume that the Operating System where OpenNMS is running is CentOS/RHEL 7 or newer.

To install the wsman CLI:

yum install wsmancli

The command should be part of the core packages of the OS.

Then, we also need the Kerberos utilities:

yum install krb5-workstation

The command should be part of the core packages of the OS.

Now that we have DNS correctly configured, the required tools are present, and there is a domain account with WinRM/WMI access, we can verify the installation.

Of course, before use Kerberos, the Kerberos Realm must be configured.

We can do that by overriding the main configuration file (i.e. etc/krb5.conf, or by extending it by adding the following to /etc/krb5.conf.d/winrm.conf

[realms]
MYNET.LOCAL = {
kdc = dc1.mynet.local
admin_server = dc1.mynet.local
}

[domain_realm]
.mynet.local = MYNET.LOCAL
mynet.local = MYNET.LOCAL

The configuration requires knowing the domain (i.e. mynet.local), the realm to use with Kerberos (i.e., MYNET.LOCAL), and the FQDN of the Domain Controller (i.e., dc1.mynet.local).

Now, we're ready to initialize the Ticket Cache.

We should use the username in Kerberos format, which is USERNAME@KERNEROS_REALM, let's assume that the username we got from the Windows Team is operator, so the username is operator@MYNET.LOCAL.

To initialize the cache:

kinit operator@MYNET.LOCAL

The above asks for the user's password. If everything went well, the command klist should show something like this:

Ticket cache: KEYRING:persistent:0:0
Default principal: operator@MYNET.LOCAL

Valid starting   Expires       Service principal
08/22/2019 18:42:27 08/23/2019 04:42:27 krbtgt/MYNET.LOCAL@MYNET.LOCAL
    renew until 08/29/2019 18:42:26

Now that we got the TGT (Ticket Granting Ticket), represented by the krbtgt service, we can use the wsman command:








wsman -d 6 \
     -h winsrv01.mynet.local \
     -P 5985 \
     --username operator@MYNET.LOCAL \
     --password "password_here" \
     -y gss \
     enumerate http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_OperatingSystem

Here is an explanation about the options:

a) -d 6

Enable DEBUG.

b) -h winsrv01.mynet.local

The FQDN of the target machine. Keep in mind that this FQDN should be the same used when the server joined the domain in Active Directory.

c) -P 5985

The WinRM Port. For simplicity, we use HTTP. However, we recommend HTTPS for production environments. We omit this because it increases the level of complexity of the solution.

d) --username operator@MYNET.LOCAL

That is an optional parameter with the username in Kerberos format, as mentioned before. If omitted, the tool prompts for it.

f) --password "password_here"

That is an optional parameter with the user's password. If omitted, the tool prompts for it.

g) -y gss

To enable GSS/Kerberos authentication, or instruct the command to initiate GSS/Kerberos negotiation.

f) enumerate http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_OperatingSystem

To execute a WinRM enumerate command against the provided WMI resource.

If the above command works, a bunch of information about the server will be displayed. The output itself can be huge, so the following includes a partial content as an example:
























<s:Body>
 <n:PullResponse>
  <n:Items>
   <p:Win32_OperatingSystem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_OperatingSystem" xmlns:cim="http://schemas.dmtf.org/wbem/wscim/1/common" xsi:type="p:Win32_OperatingSystem_Type">
    <p:BootDevice>\Device\HarddiskVolume1</p:BootDevice>
    <p:BuildNumber>7601</p:BuildNumber>
    <p:BuildType>Multiprocessor Free</p:BuildType>
    <p:Caption>Microsoft Windows Server 2008 R2 Datacenter </p:Caption>
    <p:CodeSet>1252</p:CodeSet>
    <p:CountryCode>1</p:CountryCode>
    <p:CreationClassName>Win32_OperatingSystem</p:CreationClassName>
    <p:CSCreationClassName>Win32_ComputerSystem</p:CSCreationClassName>
    <p:CSDVersion>Service Pack 1</p:CSDVersion>
    <p:CSName>WINSRV01</p:CSName>
...
    <p:Version>6.1.7601</p:Version>
    <p:WindowsDirectory>C:\Windows</p:WindowsDirectory>
   </p:Win32_OperatingSystem>
  </n:Items>
  <n:EndOfSequence/>
 </n:PullResponse>
</s:Body>
</s:Envelope>

When the above output is displayed, that means that WinRM, as well as WMI, are correctly configured. If not, the Windows Team should verify the permissions, depending on the error reported by the tool.

Remember, for a non-admin account, having access to WinRM doesn't guarantee access to WMI. That is only guaranteed when using privileged users (or administrator accounts).

Unfortunately, the command requires the username and the password even if the authentication is going to be GSS. Fortunately, this is just for testing.

Verify connectivity using the WSMAN Java Library

The idea here is to use the WSMAN library that OpenNMS uses directly from the command line to verify that the JDK can communicate with the server using WSMAN and Kerberos.

Most of the configuration files required for this CLI are going to be the same that OpenNMS uses, so the location of these files reflects this fact.

Previously, we've used the OS Kerberos Cache. Even if it is possible to do this with Java, we suggest using a Kerberos KeyTab file instead.

We need the credentials of the WinRM/WMI user to generate and initialize the KeyTab.

If you're planning to use an administrator account, and the Windows Team doesn't want to share the credentials, they should be able to generate the KeyTab file and initialize it for you on any Windows server. That way, they can provide the KeyTab to you (without the credentials). Unfortunately, that also means you cannot use the wsman command to verify the communication, and the operator must rely on the Java tool for this purpose.

To generate the KeyTab file, use the following command:

ktutil

After running the command, you'll see a distinctive prompt, and when this happens, introduce the following command:

addent -password -p operator@MYNET.LOCAL -k 1 -e RC4-HMAC

Provide the username in Kerberos format. The tool asks for the password after hitting enter at the end.

Save the Keytab File by entering the following command and press enter:

wkt /opt/opennms/etc/winrm.keytab

Finally, exit the KTUtil CLI by entering q and press enter.

Now that we have a KeyTab, we should initialize it to store the TGT on it:

kinit operator@MYNET.LOCAL -kt /opt/opennms/etc/winrm.keytab

The tool requests the user's password.

Now that the KeyTab exist, we need to provide the Kerberos configuration. The following is similar to the initial one but includes additional information and should be stored at /opt/opennms/etc/krb5.conf (which is the equivalent of overriding /etc/krb5.conf with everything requried):

[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
proxiable = true
rdns = false
kdc_timesync = 1
ccache_type = 4
default_realm = MYNET.LOCAL

[realms]
MYNET.LOCAL = {
kdc = dc1.mynet.local
admin_server = dc1.mynet.local
}

[domain_realm]
.mynet.local = MYNET.LOCAL
mynet.local = MYNET.LOCAL

Finally, we need to instruct the WSMAN Client how to authenticate the requests. For this purpose, create a file called /opt/opennms/etc/winrm-login.conf with the following content:

WSManClient {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
debug=true
storeKey=true
principal="operator@MYNET.LOCAL"
keyTab="/opt/opennms/etc/winrm.keytab";
};

Note that it has a reference to the principal (i.e., the username in Kerberos format), and more importantly, the location of the KeyTab created earlier.

debug=true is optional and can be used to understand what's going on during the Kerberos negotiation and authentication phase (it helps for troubleshooting).

At this point, we have everything required to use the Java Client.

We recommend to download the latest version of the WSMAN CLI for Java from the following link:

https://github.com/OpenNMS/wsman/releases

Currently, the latest version is:

https://github.com/OpenNMS/wsman/releases/download/v1.2.3/org.opennms.core.wsman.cli-1.2.3.jar

Here is the syntax for the Java client to get the same content as the wsman CLI we've used before:













/usr/lib/jvm/java-1.8.0/bin/java -Dsun.security.krb5.debug=true \
  -Djava.security.krb5.conf=/opt/opennms/etc/krb5.conf \
  -Djava.security.krb5.realm=MYNET.LOCAL \
  -Djava.security.krb5.kdc=dc1.mynet.local \
  -Djava.security.auth.login.config=/opt/opennms/etc/winrm-login.conf \
  -jar /root/org.opennms.core.wsman.cli-1.2.3.jar \
  -gssAuth \
  -r http://winsrv01.mynet.local:5985/wsman \
  -resourceUri http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_OperatingSystem \
  -o enum \
  -w WSMAN_1_0 \
  -vvv

The above tool only works with Java 8. It won't work with Java 11 due to JAXB issues, as reported here. That means WinRM/WSMAN can only be used with OpenNMS when using either OpenJDK 8 or Oracle JDK 8 unless you're using Horizon 25+ or Meridian 2019.

Note that multiple JVM level settings have to be added when using Kerberos. The following explains each of them:

a) -Dsun.security.krb5.debug=true

This is for enabling DEBUG, for troubleshooting purposes.

b) -Djava.security.krb5.conf=/opt/opennms/etc/krb5.conf

That is to tell Java where is the Kerberos Configuration (with the domain and realm information).

If not specified, it defaults to /etc/krb5.conf

c) -Djava.security.krb5.realm=MYNET.LOCAL

To specify the Kerberos realm to be used.

If not specified, it defaults to the one declared on the Kerberos configuration. If it is used, java.security.krb5.kdc must be specified as well.

d) -Djava.security.krb5.kdc=dc1.mynet.local

To specify the FQDN of the KDC or the Domain Controller.

If not specified, it defaults to the one declared on the Kerberos configuration. If it is used, java.security.krb5.realm must be specified as well.

e) -Djava.security.auth.login.config=/opt/opennms/etc/winrm-login.conf

The location of the authentication handler we've created earlier.

For more information, follow this link.

The rest are arguments of the Java CLI:

a) -jar /root/org.opennms.core.wsman.cli-1.2.3.jar

That is to specify the JAR that contains the CLI implementation.

b) -gssAuth

To enable GSS/Kerberos authentication via KeyTab

c) -r http://winsrv01.catsnet.local:5985/wsman

The Full URL of the WinRM location for the target host in question. Once again, note the usage of HTTP. For this reason, the port is the default one for HTTP; in other words, 5985, and the path has to be /wsman. Note that we use the FQDN of the target host (i.e., winsrv01.mynet.local).

d) -resourceUri http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_OperatingSystem

Similar to the wsman CLI, that's the URL of the WMI information of interest.

e) -o enum

To specify to the Java CLI that we're going to run a WSMAN enumeration.

f) -w WSMAN_1_0

The version of WSMAN. That is crucial as it seems that Microsoft only supports version 1.0, which is not the default of the Java CLI.

g) -vvv

To increase verbosity for troubleshooting purposes.

When executing the command, it shows much information, even more than the wsman command (especially for the Kerberos authentication). In the end, the output is the same. It shows the SOAP response, but this client also enumerates it in plain text to facilitate reading.

Configure OpenNMS

Most of the required configuration files should be present:

  • /opt/opennms/etc/krb5.conf
  • /opt/opennms/etc/winrm-login.conf
  • /opt/opennms/etc/winrm.keytab

There are only 2 additional files that should be updated:

  1. /opt/opennms/etc/opennms.conf; this file should include all the JVM level properties used on the Java CLI, for example:






# Configure WinRM/WSMAN
ADDITIONAL_MANAGER_OPTIONS="${ADDITIONAL_MANAGER_OPTIONS} -Dsun.security.krb5.debug=true" # For troubleshooting only
ADDITIONAL_MANAGER_OPTIONS="${ADDITIONAL_MANAGER_OPTIONS} -Djava.security.krb5.conf=/opt/opennms/etc/krb5.conf"
ADDITIONAL_MANAGER_OPTIONS="${ADDITIONAL_MANAGER_OPTIONS} -Djava.security.krb5.realm=MYNET.LOCAL"
ADDITIONAL_MANAGER_OPTIONS="${ADDITIONAL_MANAGER_OPTIONS} -Djava.security.krb5.kdc=dc1.mynet.local"
ADDITIONAL_MANAGER_OPTIONS="${ADDITIONAL_MANAGER_OPTIONS} -Djava.security.auth.login.config=/opt/opennms/etc/winrm-login.conf"

As mentioned before, this link provides more information about the Kerberos settings at JVM level.

  1. /opt/opennms/etc/wsman-config.xml; this file contains the credentials to connect via WinRM using the domain account, for example:






<?xml version="1.0"?>
<wsman-config retry="1" timeout="30000" ssl="true" strict-ssl="false" path="/wsman" username="root" password="calvin">
  <definition ssl="false" port="5985" path="/wsman" gss-auth="true">
    <range begin="172.31.0.10" end="172.31.0.199"/>
  </definition>
</wsman-config>

Note that the credentials are not needed, as Java will use the KeyTab when GSS is enabled. If HTTPS was enabled, make sure to update the port and the ssl attribute. Remember to adjust the range to match all the Windows Servers, and add more entries if necessary.

Alternatively, if you want to make Kerberos the default for all the servers:




<?xml version="1.0"?>
<wsman-config retry="1" timeout="30000" ssl="false" port="5985" path="/wsman" gss-auth="true">
</wsman-config>

If all the tests were successful, and the inventory of the Windows machines have been added to be consistent with the DNS resolution, OpenNMS is now ready to collect WMI statistics through WinRM using Kerberos authentication against a Domain Account.

The default configuration contains basic metrics, but there are lots of room for improvements and use specialized metrics for Windows applications like Microsoft Exchange, Active Directory, etc.

What about Minions?

If Minions are going to be involved in the solution, all the configuration files mentioned for OpenNMS must be added to Minion:

  • The KeyTab file
  • The login configuration
  • The krb5.conf

The equivalent for /opt/opennms/bin/opennms.conf on Minion is /etc/sysconfig/minion. The idea is making sure that all the required JVM level settings are applied to JVM_OPTIONS, for example:











# other options to pass to Java on startup
# export JAVA_OPTS="-Xms${JAVA_MIN_MEM} -Xmx${JAVA_MAX_MEM} -XX:+UnlockDiagnosticVMOptions"
# 
# Configure WinRM/WSMAN
WINRM_OPTS="${WINRM_OPTS} -Dsun.security.krb5.debug=true" # For troubleshooting only
WINRM_OPTS="${WINRM_OPTS} -Djava.security.krb5.conf=/opt/minion/etc/krb5.conf"
WINRM_OPTS="${WINRM_OPTS} -Djava.security.krb5.realm=MYNET.LOCAL"
WINRM_OPTS="${WINRM_OPTS} -Djava.security.krb5.kdc=dc1.mynet.local"
WINRM_OPTS="${WINRM_OPTS} -Djava.security.auth.login.config=/opt/minion/etc/winrm-login.conf"
export JAVA_OPTS="-Xms${JAVA_MIN_MEM} -Xmx${JAVA_MAX_MEM} ${WINRM_OPTS}"

Remember to change the path to the KeyTab inside winrm-login.conf.

The credentials or wsman-config.xml are not needed on Minion side, as those details will be part of the RPC request.

Because /etc/sysconfig/minion has to be changed, the Minion instance most be restarted.

Test DNS Reverse lookup in OpenNMS

Through the Karaf Shell, the following command can be used to verify that obtaining the expected FQDN from a given IP works:




admin@opennms> dns-reverse-lookup 172.31.0.100

172.31.0.100 resolves to: winsrv01.mynet.local

To verify it through a Minion, pass the name of the location using the flag -l.

How to use the WsManMonitor?

When WinRM is available, it doesn't make sense to use SNMP anymore to monitor the Windows Servers.

Without it, the usual way to check the status of a given Windows Service is by using the Win32ServiceMonitor. Unfortunately, the implementation doesn't seem to work on recent versions of Windows. After some tests, we found that a given service is listed on svSvcTable only when the service is up and running. If the service is down, it is not listed on that SNMP table, therefore the current code of the Win32ServiceMonitor won't be able to trigger an outage.

Here is when WinRM can be useful. For example, to verify the status of the MSSQL Service:

<service name="MSSQLServer" interval="300000" user-defined="false" status="on">
   <parameter key="retry" value="1"/>
   <parameter key="timeout" value="5000"/>
   <parameter key="resource-uri" value="http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service"/>
   <parameter key="selector.Name" value="MSSQLSERVER"/>
   <parameter key="rule" value="#State matches 'Running' and #Status matches 'OK'"/>
</service>
...
<monitor service="MSSQLServer" class-name="org.opennms.netmgt.poller.monitors.WsManMonitor"/>

Unlike its SNMP counterpart, the WsManMonitor requires the name of the Windows Service, not the display name.

What about the detector?

Unfortunately, not all versions of OpenNMS have support for WsManWQLDetector, which is the proper detector to use.

Assuming you're running Horizon 25+ or Meridian 2019+, the following is an example of how it should look like:

<detector name="MSSQLServer" class="org.opennms.netmgt.provision.detector.wsman.WsManWQLDetector">
   <parameter key="resourceUri" value="http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"/>
   <parameter key="wql" value="select Name,Status from Win32_Service where Name = 'MSSQLSERVER' and Status = 'OK'"/>
</detector>

For older versions of OpenNMS, and assuming SNMP is available on the Windows Server, Win32ServiceDetector is still valid, assuming the service is running.

Verify Polling

From the Karaf Shell:



















admin@opennms> poll -c org.opennms.netmgt.poller.monitors.WsManMonitor 172.31.0.100 resource-uri="http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service" selector.Name="SNMP" rule="#State matches 'Running' and #Status matches 'OK'"
Monitor: org.opennms.netmgt.poller.monitors.WsManMonitor
Parameter resource-uri: http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service
Parameter rule: #State matches 'Running' and #Status matches 'OK'
Parameter selector.Name: SNMP
Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt false ticketCache is null isInitiator true KeyTab is /opt/opennms/etc/winrm.keytab refreshKrb5Config is false principal is operator@MYNET.LOCAL tryFirstPass is false useFirstPass is false storePass is false clearPass is false
principal is operator@MYNET.LOCAL
Will use keytab
Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt false ticketCache is null isInitiator true KeyTab is /opt/opennms/etc/winrm.keytab refreshKrb5Config is false principal is operator@MYNET.LOCAL tryFirstPass is false useFirstPass is false storePass is false clearPass is false
principal is operator@MYNET.LOCAL
Will use keytab
Commit Succeeded

Commit Succeeded


Service is Up on 172.31.0.100 using org.opennms.netmgt.poller.monitors.WsManMonitor:
(No properties were returned by the monitor.

In the poll command, 172.31.0.100 would be the primary interface of the Windows server in question. If the node is behind a Minion, pass the location name with -l. For more details, use poll --help

Verify Data Collection

From the Karaf Shell:












































































































admin@opennms> collect -n 1 org.opennms.netmgt.collectd.WsManCollector 172.31.0.100 collection=default | grep "Attribute.*wrm"
		Attribute[wrmTSSessActive:1.0]
		Attribute[wrmTSSessInactive:1.0]
		Attribute[wrmTSSessTotal:2.0]
		Attribute[wrmServerSessions:0.0]
		Attribute[wrmServerSessErrOut:0.0]
		Attribute[wrmServerSessFcdOff:0.0]
		Attribute[wrmServerSessLgdOff:0.0]
		Attribute[wrmServerSessTmdOut:0.0]
		Attribute[wrmServerErrsSystem:0.0]
		Attribute[wrmServerErrsGtdAxs:0.0]
		Attribute[wrmServerErrsAxsPrm:0.0]
		Attribute[wrmServerErrsLogon:0.0]
		Attribute[wrmOSCpuName:_Total]
		Attribute[wrmOSCpuIntsPerSec:1483.0]
		Attribute[wrmOSCpuPctProcTime:0.0]
		Attribute[wrmOSCpuPctDPCTime:0.0]
		Attribute[wrmOSCpuPctIntrTime:0.0]
		Attribute[wrmOSCpuPctUserTime:0.0]
		Attribute[wrmOSCpuName:0]
		Attribute[wrmOSCpuIntsPerSec:874.0]
		Attribute[wrmOSCpuPctProcTime:0.0]
		Attribute[wrmOSCpuPctDPCTime:0.0]
		Attribute[wrmOSCpuPctIntrTime:0.0]
		Attribute[wrmOSCpuPctUserTime:0.0]
		Attribute[wrmOSCpuName:1]
		Attribute[wrmOSCpuIntsPerSec:609.0]
		Attribute[wrmOSCpuPctProcTime:0.0]
		Attribute[wrmOSCpuPctDPCTime:0.0]
		Attribute[wrmOSCpuPctIntrTime:0.0]
		Attribute[wrmOSCpuPctUserTime:0.0]
		Attribute[wrmLDName:_Total]
		Attribute[wrmLDPctFreeMBytes:41830.0]
		Attribute[wrmLDPctDiskRdTime:100.0]
		Attribute[wrmLDPctDiskWrTime:25.0]
		Attribute[wrmLDPctFreeSpace:68.0]
		Attribute[wrmLDSplitIOsPerSec:156.0]
		Attribute[wrmLDName:C:]
		Attribute[wrmLDPctFreeMBytes:41707.0]
		Attribute[wrmLDPctDiskRdTime:100.0]
		Attribute[wrmLDPctDiskWrTime:50.0]
		Attribute[wrmLDPctFreeSpace:68.0]
		Attribute[wrmLDSplitIOsPerSec:156.0]
		Attribute[wrmLDName:HarddiskVolume1]
		Attribute[wrmLDPctFreeMBytes:123.0]
		Attribute[wrmLDPctDiskRdTime:0.0]
		Attribute[wrmLDPctDiskWrTime:0.0]
		Attribute[wrmLDPctFreeSpace:27.0]
		Attribute[wrmLDSplitIOsPerSec:0.0]
		Attribute[wrmPDName:_Total]
		Attribute[wrmPDPctDiskRdTime:78.0]
		Attribute[wrmPDPctDiskWrTime:5.0]
		Attribute[wrmPDSplitIOsPerSec:0.0]
		Attribute[wrmPDTransPerSec:377.0]
		Attribute[wrmPDAvgSecPerTrans:0.0]
		Attribute[wrmPDQueueLen:1.0]
		Attribute[wrmPDAvgQueueLen:0.0]
		Attribute[wrmPDPctBusyTime:83.0]
		Attribute[wrmPDPctIdleTime:11.0]
		Attribute[wrmPDName:0 C:]
		Attribute[wrmPDPctDiskRdTime:78.0]
		Attribute[wrmPDPctDiskWrTime:5.0]
		Attribute[wrmPDSplitIOsPerSec:0.0]
		Attribute[wrmPDTransPerSec:377.0]
		Attribute[wrmPDAvgSecPerTrans:0.0]
		Attribute[wrmPDQueueLen:1.0]
		Attribute[wrmPDAvgQueueLen:0.0]
		Attribute[wrmPDPctBusyTime:83.0]
		Attribute[wrmPDPctIdleTime:11.0]
		Attribute[wrmIpNetIfName:Intel[R] 82574L Gigabit Network Connection]
		Attribute[wrmIpNetCurrSpeed:1000000000]
		Attribute[wrmIpNetBytesSec:2278657.0]
		Attribute[wrmIpNetIBytesSec:1272588.0]
		Attribute[wrmIpNetOBytesSec:1006069.0]
		Attribute[wrmIpNetPktsSec:7013.0]
		Attribute[wrmIpNetIPktsSec:3686.0]
		Attribute[wrmIpNetINUPktsSec:0.0]
		Attribute[wrmIpNetIUCPktsSec:3686.0]
		Attribute[wrmIpNetOPktsSec:3327.0]
		Attribute[wrmIpNetONUPktsSec:0.0]
		Attribute[wrmIpNetOUCPktsSec:3327.0]
		Attribute[wrmIpNetIfName:isatap.nc.rr.com]
		Attribute[wrmIpNetCurrSpeed:100000]
		Attribute[wrmIpNetBytesSec:0.0]
		Attribute[wrmIpNetIBytesSec:0.0]
		Attribute[wrmIpNetOBytesSec:0.0]
		Attribute[wrmIpNetPktsSec:0.0]
		Attribute[wrmIpNetIPktsSec:0.0]
		Attribute[wrmIpNetINUPktsSec:0.0]
		Attribute[wrmIpNetIUCPktsSec:0.0]
		Attribute[wrmIpNetOPktsSec:0.0]
		Attribute[wrmIpNetONUPktsSec:0.0]
		Attribute[wrmIpNetOUCPktsSec:0.0]
		Attribute[wrmW3Name:_Total]
		Attribute[wrmW3GetReq:0.0]
		Attribute[wrmW3HeadReq:0.0]
		Attribute[wrmW3PostReq:0.0]
		Attribute[wrmW3PutReq:0.0]
		Attribute[wrmW3DelReq:0.0]
		Attribute[wrmW3NotFound:0.0]
		Attribute[wrmW3Name:Default Web Site]
		Attribute[wrmW3GetReq:0.0]
		Attribute[wrmW3HeadReq:0.0]
		Attribute[wrmW3PostReq:0.0]
		Attribute[wrmW3PutReq:0.0]
		Attribute[wrmW3DelReq:0.0]
		Attribute[wrmW3NotFound:0.0]

As this is for testing purposes, you could use the FQDN instead of the IP, to verify that it works (in case there are RDNS issues).



admin@opennms> collect -n 1 org.opennms.netmgt.collectd.WsManCollector winsrv01.mynet.local collection=default | grep "Attribute.*wrm" | wc -l
106

In the collect command, -n 1 means the Node ID of the Windows Server in the OpenNMS database, and when not using an FQDN, 172.31.0.100 would be the primary interface of the server in question. If the node is behind a Minion, pass the location name with -l. For more details, use collect --help

Last changed by 
 
Alejandro Galue
0
847

Read more

Sizing Cassandra

The use case for having Cassandra (or ScyllaDB) as the backend for the performance metrics in OpenNMS is for storing a huge amount of non-aggregated data, which is not possible with RRDtool. RRDtool is very good for those installations with a finite and predictable amount of metrics where the size and the I/O requirements are feasible for modern SSD disks. This is important as RRDtool only scales vertically, meaning that when the current disks&apos; limits are reached (mostly due to speed, not space), a faster disk is required. This is when Cassandra or ScyllaDB can help. Although there is a high learning curve, using any of these applications requires a commitment to have qualified personnel to manage this database. ScyllaDB is binary compatible with Cassandra (even at the SSTable level), but they are implemented very differently. Cassandra is implemented in Java, meaning that all the JVM tuning is required and other internal Cassandra tunings. On the other hand, ScyllaDB is implemented in modern C++, taking advantage of the CPU where it is running. That means ScyllaDB can manage huge machines as nodes, whereas Cassandra would require multiple instances on huge machines. It is feasible to have faster results with ScyllaDB compared with its Java sibling in terms of performance. Configuring and managing both applications is different, even if they will provide the same operational result with OpenNMS, so the decision should be carefully analyzed, especially by the team that will support this database.

May 4, 2022
Simple OpenNMS Environment using ScyllaDB

This lab starts an OpenNMS instance, a 3-node ScyllaDB cluster, and optionally an instance for the Scylla Monitoring Stack in the cloud, for learning purposes. To monitor a network, it is advised to enable ActiveMQ or Kafka and use Minions. For simplicity, the embedded ActiveMQ will be enabled. :::success Follow this guide for general information about how to configure Scylla/Cassandra for OpenNMS/Newts. Most of that knowledge is transferable to ScyllaDB. ::: Requirements

Nov 19, 2021
Simple OpenNMS/Minion Environment using Kafka in Azure

This lab starts an OpenNMS instance and a 3 node ZK/Kafka cluster in the cloud and two Minions on your machine, using Kafka for communication through Multipass and Azure, for learning purposes. :::warning The lab doesn&apos;t cover security by default (user authentication and encryption), which is crucial if we ever want to expose the Kafka cluster to the Internet. A separate section covers the required changes for this. ::: :::success Keep in mind that nothing prevents us from skipping using the cloud provider and do everything with Multipass (or VirtualBox, or Hyper-V, or VMWare). The reason for using a cloud provider is to prove that OpenNMS can monitor unreachable devices via Minion. Similarly, we could use any other cloud provider instead of Azure. However I won&apos;t explain how to port the solution here. :::

Nov 19, 2021
Simple OpenNMS/Minion Environment using the embedded ActiveMQ in Azure

This lab starts an OpenNMS instance in the cloud and two Minions on your machine, using ActiveMQ for communication through Multipass and Azure, for learning purposes. :::danger The lab doesn&apos;t cover security (in terms of encryption), which is crucial if you ever want to expose AMQ to the Internet. Follow this guide to learn how to do it with LetsEncrypt. ::: :::success Keep in mind that nothing prevents you from skipping using the cloud provider and do everything with Multipass (or VirtualBox, or Hyper-V, or VMWare). The reason for using a cloud provider is to prove that OpenNMS can monitor unreachable devices via Minion. Similarly, you could use any other cloud provider instead of Azure. However I won&apos;t explain how to port the solution here. :::

Nov 19, 2021
Read more from Alejandro Galue
Published on HackMD