Introduction

On my previous post – Some Icinga Core basics – Part Four – I discussed host dependencies (parent/child relationships between hosts) and using icons and images with Icinga Core.  In this post I’m going to cover how to monitor Windows based remote hosts using NSClient++.  I’ll cover using the basic out-the-box commands as well as adding your own arguments (local and remote) on a Windows 2008 R2 and Windows 2012 test server.

There are a few protocols you can use to communicate with NSClient++ but as this series has used NRPE for monitoring remote hosts we’ll continue to use that here.

NOTE: while a lot of this is stated as Raspberry Pi specific it’s really just general Icinga configuration on a Debian based system (e.g. Ubuntu).

Installation

  1. Download the setup file from www.nsclient.org and place this on your remote Windows server (or a central location).
    NOTE: I’m working with the latest release (0.4.2) at time of writing.
  2. Connect to your remote Windows host (e.g. via RDP).
  3. Run the setup file (e.g. NSCP-0.4.2.88-x64.msi)
  4. Click Next at the welcome screen.
  5. Check the box to accept the license agreement and click Next.
  6. Click Typical.
  7. Accept the defaults and click Next.
    NOTE: This places the ini files in the same place as the executable.
  8. Only enter the IP address of your Icinga server here as we will enable a select few modules manually. Click Next.
  9. Click Install.
  10. Click Finish.

Browse to the Command Prompt, right click and choose Run as administrator.
Enter cd “\Program Files\NSClient++” to change into the NSClient++ directory.
Run the following commands to enable the modules we want:

> nscp settings –activate-module NRPEServer –add-missing
> nscp settings –activate-module CheckSystem –add-missing
> nscp settings –activate-module CheckDisk –add-missing
> nscp settings –activate-module CheckExternalScripts –add-missing

This enables the following modules – NRPEServer (for accepting connections via NRPE), CheckSystem (for some out of the box system related check modules e.g. cpu, memory etc), CheckDisk (for working with drives and files) and CheckExternalScripts (for working with aliased command and external scripts you might want to call.

Now restart the NSClient++ service:

> net stop nscp
> net start nscp

From your Icinga server you can now query this server and confirm it’s operational:

$ /usr/lib/nagios/plugins/check_nrpe -H <ip_of_server>
I (0,4,2,88 2014-03-16) seem to be doing fine…

$ /usr/lib/nagios/plugins/check_nrpe -H <ip_of_server> -c check_cpu
OK: |’total 5m’=0%;80;90 ‘total 1m’=0%;80;90 ‘total 5s’=0%;80;90

Test Mode

A really good feature in NSClient++ is the test mode. This mode effectively leaves a debugging screen up so you can see the incoming connections and their results. To activate test mode:

Browse to the Command Prompt, right click and choose Run as administrator.
Enter cd “\Program Files\NSClient++” to change into the NSClient++ directory.
Run the following commands to run through the test mode operation:

> net stop nscp

> nscp test

Here’s an example test window showing the modules loading (“core adding…”)and a couple of successful connections at the end from an Icinga server:

nsclient6

<perform your testing then close the test window>

> net start nscp

(Alternatively you can stop the service in the Windows Services snap-in, then run the item in the start menu named NSClient++ (x64, test) as administrator. When your testing is complete, close the test mode window and start the service again)

Key Files

The following files are some of the most important ones you’ll come across right away.

  • C:\Program Files\NSClient++\nsclient.ini – This is the primary configuration file for NSClient++
  • C:\Program Files\NSClient++\nscp.exe – This is the NSClient++ executable.
  • C:\Program Files\NSClient++\nsclient.log – When logging is enabled all events will be written to this file.
  • C:\Program Files\NSClient++\NSCP.pdf – This is the NSClient++ manual in PDF form.  There are the occasional formatting issues as it seems to be taken straight from the online wiki.

Configuration

The way checks are configured with NRPE and NSClient++ on Windows are very similar to the way I described them working with NRPE monitoring remote Linux servers. There are three methods:

NOTE: Internal commands refer to the built in check commands that come with NSClient++ (e.g. check_cpu).

  1. Compose your commands on the remote host(s) with NSClient and call the commands from the Icinga server. These could be internal commands or external scripts (e.g. batch, vbs, PowerShell).
  2. Compose your commands (based on the NSClient++ internal commands), including arguments, locally (on the Icinga server) and send these to NSClient (via NRPE).
  3. Compose your commands (based on the external scripts on the remote host(s)), including arguments, locally (on the Icinga server) and send these to NSClient (via NRPE).

These methods are all a trade off between security and ease of management. You’ll need to make a decision depending on your environment and security policies.  I’ll go through configuring each one and then we’ll put it all together into Icinga.

(Method 1) Compose Commands on Remote Host

This method includes three options:

  • Using the built in commands ‘as is’ e.g. just using check_cpu or check_drivesize etc. These require no arguments and return the required data for Icinga.
  • Creating aliases by adding arguments to built in commands to produce specific output (e.g. writing an alias that just looks at the C: drive and reports back specific information to Icinga)
  • Using external scripts with any arguments specified in the same place.

Pros: This is the most secure solution and does not allow any arguments to be passed to the remote hosts.

Cons: It means the configuration has to be done on each host and cannot be centrally maintained on the Icinga server.

This option requires the following values set in the nsclient.ini file (NOTE: these are the default values):

[/settings/NRPE/server]
allow arguments=false

[/settings/external scripts]
allow arguments=false

I covered this option when we installed NSClient++ as we tested this with check_cpu and confirmed an internal command worked as expected.

Let’s look more closely at the second option and create the example I mentioned above. I like to create a separate .ini file for my own commands and reference this from the main file.

If you don’t want to do this just locate the relevant sections (in square brackets) in the nsclient.ini file and append the commands.

  1. On the remote host open the nsclient.ini file in Notepad or your particular text editor.
    NOTE: Run your text editor as administrator and open the file from there otherwise you won’t be able to save the nsclient.ini file in place.

  2. Under the [/includes] includes section add the following:
    <name>=<filename>.ini
    where <filename>.ini is your new file name that will contain custom commands and name is a unique value (if you have more than one include). You can make this the same as the file name (but without the .ini suffix)

  3. Save the file and exit.

  4. Create a new ini file in the same folder as nsclient.ini called <filename>.ini (based on the name you gave it above)

  5. On the first line add the following:
    [/settings/external scripts/alias]

  6. On the second line add the following command:
    alias_cdrive=check_drivesize “drive=C” “top-syntax=${list}” “detail-syntax=${status} – ${drive_or_name}: ${used}/${size} used”

  7. Save the file and exit.

  8. Restart the NSClient++ (ncsp) service.

  9. From your Icinga server run:
    $ /usr/lib/nagios/plugins/check_nrpe -H 192.168.24.45 -c alias_cdrive

  10. You should get something like this returned:
    OK – C: 8.875GB/29.9GB used|’C used’=8GB;23;26;0;29 ‘C used %’=29%;79;89;0;100

I’ll break down the command above:

  • alias_cdrive – the name of the alias to be called from NRPE.
  • check_drivesize – the name of the internal (built in) command that will be used.
  • “drive=C” – designates a filter on the drive itself (only return the C: drive)
  • “top-syntax=${list}” – This is the overall message being returned (NOT the performance data). list returns all items matching the filter (drive=C in this case)
  • “detail-syntax=${status} – ${drive_or_name}: ${used}/${size} used” – This is the selection of items in the message being returned. This is just a list of variables and free text to create a friendly message. It returns the status (e.g. OK), a hyphen, the drive (e.g. C), a colon then the used space and total size. You can see this above. The data after the pipe symbol is the performance data returned to Icinga. This includes the value, warning threshold, critical threshold, minimum and maximum respectively.

You can see what each internal command accepts as variables and filters at the reference documentation here.

The third and final option is a little out of scope of this post (it’s only the basics after all) but is similar to the above option only it uses an external script (e.g. a PowerShell script you’ve written).

NOTE: I can elaborate further in another post if required. The documentation for this can be found here.

(Method 2) Compose Internal Commands on Icinga Server

This method allows you to build up an internal command with arguments on the Icinga server. It will allow arguments to be sent to internal commands on the remote host but not external scripts.

Pros: Allows the configuration for internal commands to be done on the Icinga server.

Cons:External scripts will still need to be configured on the remote host itself. Reduces the security as arguments are sent to internal commands.

This option requires the following values set in the nsclient.ini file:

[/settings/NRPE/server]
allow arguments=true

[/settings/external scripts]
allow arguments=false

From testing I’ve found I needed the following as well (changed from false to true):

[/settings/NRPE/server]
allow nasty characters = true

This seems to be required because you might be sending arguments in single or double quotes.

Once you’ve changed the values above, restart the NSClient++ (nscp) service.

We’ll run the same check as above (checking the C: drive) but fully composed on the Icinga server.

  1. From your Icinga server run:
    $ /usr/lib/nagios/plugins/check_nrpe -H 192.168.24.45 -c check_drivesize -a ‘drive=C’ ‘top-syntax=%(list)’ ‘detail-syntax=%(status) – %(drive_or_name): %(used)/%(size) used’

  2. You should get something like this returned:
    OK – C: 8.875GB/29.9GB used|’C used’=8GB;23;26;0;29 ‘C used %’=29%;79;89;0;100

Notice the ${…} variables were replaced with %(…). Icinga sees the ${…} as unknown macros and doesn’t return any data (it seems to work at the command line but not via the daemon). This happens because the current version of Icinga has the option keep_unknown_macros set to false (0). Replacing them with %(…) is a supported way of passing the same arguments through without needing to change this option to true (1).

(Method 3) Compose External Commands on Icinga Server

This method allows you to build up an external command with arguments on the Icinga server. It will allow arguments to be sent to internal commands and external scripts.

Pros: Allows the configuration for internal commands and external scripts to be done on the Icinga server.

Cons: The least secure method if the hosts involved are not secured properly.

This option requires the following values set in the nsclient.ini file:

[/settings/NRPE/server]
allow arguments=true

[/settings/external scripts]
allow arguments=true

As above, I’ve found I needed the following as well (changed from false to true):

[/settings/NRPE/server]
allow nasty characters = true

This final method is a little out of scope of this post but is similar to the second method only it allows you to send arguments to external scripts (e.g. a PowerShell script you’ve written) and internal commands.

NOTE: I can elaborate further on this in another post if required. The documentation for this can be found here.

Putting it all together

To bring this altogether we really want to see some Windows hosts and services in the Icinga Core web page!  I mentioned at the start that I have a Windows 2008 R2 server (named win20008r2) and a Windows 20012 server (named win2012).  For the purposes of this section I will configure the Windows 2008 R2 server with method 1 (all commands are on the remote Windows host) and the Windows 2012 server with method 2 (all commands composed on the Icinga server).

NOTE: Ensure you check and change the IP address information (and names if applicable) for your environment.

Windows 2008 R2

Earlier I gave an example of setting up an alias_cdrive command on the remote host – follow this example again (if it’s a new server).

On the Icinga server you can then create a new object file for your remote host.

$ sudo nano /etc/icinga/objects/win2008r2.cfg

Add the following configuration:

define host{
        use                     generic-host            ; Name of host template to use
        host_name               win2008r2
        alias                   Windows 2008R2 Test Server
        address                 192.168.0.45
        }

define service{
        use                             generic-service
        host_name                       win2008r2
        service_description             Windows CPU
        check_command                   check_nrpe_1arg!check_cpu
        }

define service{
        use                             generic-service
        host_name                       win2008r2
        service_description             Windows Memory
        check_command                   check_nrpe_1arg!check_memory
        }

define service{
        use                             generic-service
        host_name                       win2008r2
        service_description             Disk Drive - C
        check_command                   check_nrpe_1arg!alias_cdrive
        }

Save the file and exit.

Windows 2012

As all the commands are being composed on the Icinga server you only need to set the following options in the nsclient.ini file on the remote host (and restart the remote NSClient++ service)

[/settings/NRPE/server]
allow arguments = true
allow nasty characters = true

On the Icinga server you can then create a new object file for your remote host.

$ sudo nano /etc/icinga/objects/win2012.cfg

Add the following configuration:

define host{
        use                     generic-host            ; Name of host template to use
        host_name               win2012
        alias                   Windows 2008R2 Test Server
        address                 192.168.0.46
        }

define service{
        use                             generic-service
        host_name                       win2012
        service_description             Windows CPU
        check_command                   check_nrpe!check_cpu!'top-syntax=%(list)'
        }

define service{
        use                             generic-service
        host_name                       win2012
        service_description             Windows Memory
        check_command                   check_nrpe!check_memory!'top-syntax=%(list)'
        }

define service{
        use                             generic-service
        host_name                       win2012
        service_description             Disk Drive - C
        check_command                   check_nrpe!check_drivesize!'drive=C' 'top-syntax=%(list)' 'detail-syntax=%(status) - %(drive_or_name): %(used)/%(size) used'
        }

Save the file and exit. Restart the Icinga service.

$ sudo service icinga restart

Browse to your Icinga homepage and you should see your new hosts and their services will hopefully appear and after a few minutes go green with a status of OK.

nsclient4a

nsclient4b

nsclient4c

NOTE: Ensure you enter a firewall rule to allow ICMP (ping) or disable the firewall (depending on your environment) so that Icinga can monitor host state/availability.

Host Group and Services

The most efficient way to monitor your hosts is obviously with the same method (at least for the majority of them) so you can utilize host groups and services based on host groups.

Here’s an example host group configuration (you can add this to a new file or an existing one):

$ sudo nano /etc/icinga/objects/custom-hostgroups.cfg

Add the following configuration:

define hostgroup {
        hostgroup_name  windows-servers
        alias           Windows servers
        members         win2008r2,win2012
        }

Here’s three example services applied to the host group instead of configuring them per host.  You’ll notice the hostgroup_name directive being used instead of hostname.  This will apply these services to all hosts in the host group.

$ sudo nano /etc/icinga/objects/windows-servers.cfg

Add the following configuration:

define service{
        use                             generic-service
        hostgroup_name                  windows-servers
        service_description             Windows CPU
        check_command                   check_nrpe!check_cpu!'top-syntax=%(list)'
        }

define service{
        use                             generic-service
        hostgroup_name                  windows-servers
        service_description             Windows Memory
        check_command                   check_nrpe!check_memory!'top-syntax=%(list)'
        }

define service{
        use                             generic-service
        hostgroup_name                  windows-servers
        service_description             Disk Drive - C
        check_command                   check_nrpe!check_drivesize!'drive=C' 'top-syntax=%(list)' 'detail-syntax=%(status) - %(drive_or_name): %(used)/%(size) used'
        }

Remove all service configuration entries from win2008r2.cfg and win2012.cfg. Ensure both remote hosts have the following options set in their nsclient.ini file:

[/settings/NRPE/server]
allow arguments = true

allow nasty characters = true

Finally, restart the Icinga service:

$ sudo service icinga restart

Browse to your Icinga homepage and go to Host Group Summary | Windows Servers | View Host AND Services Status Detail For This Hostgroup.  You should see both hosts now displaying the same format of information:

nsclient5

To add more hosts with the same checks just run through the NSClient++ installation, setting options, creating a configuration file for the host and adding the host name to the previously created Windows Servers host group.

Summary

As NSClient++ is a completely separate product I hope you appreciate that it has its own learning curve and configuration requirements. Hopefully I’ve laid out enough information to get you up and running with monitoring Windows hosts so you can progress with the official documentation and your own testing. As always if anything is unclear or you have any questions then just let me know in the comments.

Some Icinga Core basics – Part One

Some Icinga Core basics – Part Two

Some Icinga Core basics – Part Three

Some Icinga Core basics – Part Four

References

The NSClient++ documentation took me a while to pull together in my head but it still has pretty much all the information you’ll need:

NSClient++ Documentation

Some Icinga Core basics – Part Five – Monitor Windows Hosts with NSClient
Tweet about this on TwitterShare on Google+0Share on Facebook0Email this to someone
Tagged on:                     

6 thoughts on “Some Icinga Core basics – Part Five – Monitor Windows Hosts with NSClient

  • Pingback: Some Icinga Core basics – Part One « geeklee's Notes

  • Pingback: Some Icinga Core basics – Part Two « geeklee's Notes

  • Pingback: Some Icinga Core basics – Part Three « geeklee's Notes

  • Pingback: Some Icinga Core basics – Part Four « geeklee's Notes

  • 25 July 2014 at 10:22
    Permalink

    Hi, me again 🙂

    I’ve been testing this on a Windows 2008 server, not R2 but it is up to date with patches and service packs.

    I get a ‘no handler’ error with the check_drivesize but it accepts the legacy checkdrivesize. I’ve used the latest stable version of NSClient for 64bit and I wondered why the change from the legacy command? I’d prefer to create an up to date set of files rather than write them again in the future.

    Using this in windows-servers.cfg

    check_nrpe!checkdrivesize! ‘drive=c’ ‘top-syntax=%(list)’ ‘detail-syntax=%(status) – %(drive_or_name): %(used)/%(size) used’

    Gives the error ‘top-syntax top-syntax reason: 3: The system can not find the path specified.’

    I can get output from the icinga terminal session in regards to drive size using the line below

    /usr/lib/nagios/plugins/check_nrpe -H 192.168.0.3 -p 5666 -c CheckDriveSize -a ShowAll MinWarnFree=10% MinCritFree=5% Drive=c:

    But using it in a windows-server.cfg file on the icinga host I get issues around the host name not being defined anywhere and I can’t get my head around where it should be defined!

    I know the IP shouldn’t be there and it should be some sort of wildcard or $hostname$ and I have used the cutom.hostgroups.cfg where the name of the server is in the members line.

    I’m going round in circles a bit so I’m taking a break, walking away and asking for help. 🙂

    just for info I’m also getting errors on the CPU and memory generic service lines but I’ve parked that for now to concentrate on the disk size issue. I figure this will explain the other errors.

    cheers.

    David.

    Reply
    • 25 July 2014 at 21:26
      Permalink

      Hi David – I’ll PM you directly if that’s OK? I can get some config files and hopefully get to the bottom of things.

      As a starter… the hostname is defined in the host definition for the windows server. Typically the $HOSTADDRESS$ macro is used by NRPE and this is taken from the address directive.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *