monitoring

NSClient++ for NRPE users

Posted by Michael Medin at 2013-06-05

article header image

A lot of people coming to NSClient++ has a background in NRPE since it is a common transport mechanism for check results on Linux.

And while NSClient++ is fully NRPE compatible it allows for more control and has more features which can make it seem difficult to get started with. This is a guide for getting started with NSClient++ from a NRPE perspective.

Overview

The biggest difference between NRPE and NSClient++ is that NSClient++ provides built-in commands through its modules. This means that for many common checks you do not need to configure any external scripts. The other major change is the configuration and command line syntax is somewhat different.

The illustration tries to depict this visually. Where the regular NRPE server (lower right) responds to a query and sends a reply NSClient++ (upper right) has a series of servers which accepts requests (NRPEServer) which are forwarded to a number of modules (CheckExternalScripts) which in turn execute the command. In a way one could consider NSClient++ as a broker who facilitate exchange.

Configuration

The configuration in NSClient++ is based on the Windows INI file format. The structure of an ini file is somewhat similar to the NRPE configuration format (and many other Linux configuration files) but it also features section (which NRPE lacks). A simple configuration entry might look like this:

[section]
key 1=value 1
key 2 = value 2

When it comes to key names most are inherited from the Original NRPE implementation so you should feel right at home. One difference is that keys in NSClient++ use white space ( ) instead of under score (_). When it comes to sections they are hierarchical and form a tree structure where each module has its own node under /settings. To use NRPE and external scripts you need to configure three sections:

  1. Which modules to load (/modules)
  2. Server properties (/settings/default and /settings/NRPE/server)
  3. Execution properties (/settings/external scripts)

Modules

The first thing we need to do is load the modules. In our example here we load NRPEServer and CheckExternalScripts as well as CheckSystem to showcase the features of a built-in module. CheckSystem provides (amongst others) the check_cpu and check_mem commands.

[/modules]
NRPEServer=enabled
CheckExternalScripts=enabled
CheckSystem=enabled

Default settings

Configuring defaults for our server is a good way to save yourself a few lines of typing especially if you plan to use multiple protocols. The default values are used whenever specific values are not pressent.

[/settings/default]
allowed hosts = 10.11.12.13

Thus the following would yield the same result:

[/settings/NRPE/server]
allowed hosts = 10.11.12.13

The value for allowed hosts is the Nagios IP address which we have entered here as 10.11.12.13. The purpose is the same as the allowed_hosts option in nrpe.conf where we configure which IP addresses is allowed to connect.

Reloading settings

restart-op5-nscpNow we can restart the service and try connecting from our Nagios server.

Simplest way to restart the service is to open a command prompt and type:

net stop nscp
net start nscp

Another option is to restart the service from the Service manager.

Connecting

The simplest way to diagnose connection details and network related issues is to run check_nrpe without a command. This is identical to the regular NRPE behavior and looks like this in the NSClient++ case:

./check\_nrpe -H <nsclient++ server ip>
I (0.4.2.1 2013-06-05) seem to be doing fine...

If this works out we want to try running an internal command to validate that everything is working ok. A simple one to use is alias_cpu which will check the CPU metrics for us.

./check\_nrpe -H <nsclient++ server ip> -c alias\_cpu
OK CPU Load ok.\|'5m'=0%;80;90 '1m'=0%;80;90 '30s'=1%;80;90

In case of errors

If this did not work we probably want to do some debugging. This is vastly different since on Linux with regular NRPE your first bet would be the start tailing the syslog or messages file. But with NSClient++ your closest resemblance is the is the nsclient.log file.

But a much better option is the NSClient++ test mode. To activate test mode all you need to do is shut down the regular client and start NSClient++ in test mode:

cd \\program files\\nsclient++
net stop nscp
nscp test
...
... wait
...
... error
...
exit
net start nscp

What this does is give you real-time debugging information as well as errors and such.

Executing scripts

Hopefully by now we have managed to connect and utilize the built-in commands. Before we move on to external scripts lets discuss arguments a bit since it is a source of confusion for many users. Arguments work much the same as vanilla NRPE in that you can allow arguments and “nasty characters”. The difficulty is that there are TWO places to allow arguments:

  1. NRPEServer For all inbound commands
  2. CheckExternalScripts Only for external scripts

The reasoning behind this is that it could be considered less dangerous to deny arguments only for externals scripts which are executed by the shell (and a lot less to configure if you allow them for internal commands). For details about arguments see the HOWTO about using external scripts.

external-scripts-args-2

Scripts

The final thing we need to do is load and configure scripts. This is a bit different from the NRPE syntax but works much the same. You give each script an alias which becomes the command. Arguments are forwarded using $ARG1$ argument variables:

[/settings/external scripts/scripts]
test=scripts\\check\_ok.bat

You can add as many script as you like as long as the alias (command) is unique.

Scripts on Windows

One snag which is really more related to how windows work than NSClient++ is that most scripting languages requires the full command line syntax.

This means that if I want to use a VBS (VisualBasic Script) I would have to enter:

[/settings/external scripts/scripts]
test=cscript.exe //T:30 //NoLogo scripts\\check\_test.vbs

This means it is a lot more to configure when your using script on Windows fortunately to combat this the concept of “wrapped scripts” was added to NSClient++. Wrapped script work much like a macro where you can define how vbs scripts are executed and have NSClient++ add-in all the nitty gritty details.

The same command above using wrapped scripts look like this:

[/settings/external scripts/wrapped scripts]
test=check\_test.vbs

Which is much simpler, for more details on wrapped scripts see the HOWO section about wrapped scripts.

Summary

So using NSClient++ if you have an NRPE background is not that different. Most of the changes are simply syntactical. And once you get started you will be able to explore many of the more advanced features which NSCLient++ provides over the regular NSRPE program such as:

The full configuration is shown below:

[/modules]
NRPEServer=enabled
CheckExternalScripts=enabled
CheckSystem=enabled


[/settings/default]
allowed hosts = 10.11.12.13

[/settings/external scripts/scripts]
test\_script=scripts\\check\_ok.bat

Share on: Twitter Facebook Google Email

I will be presenting at Nagios World Conference North America 2013!
A conference to remember…

Related articles

Open Source Monitoring Conference 2013

As always I really enjoyed the conference as much as the social aspect of it. It truly is one of the best conferences in the field. This was my sixth year which as I noted earlier started out a bit weird. I will not cover the limousine story here again instead this is purely about the conference.

The conference started off with the usual introduction by bernd who did it in English this year which I think was nice but quite frankly the usual “food is in the food area” and “conference is in the conference are” I can pretty much understand even in German. As I only speak English I will, as usual, only cover the English track here.

Putting some client into NSClient

NSClient++ despite its name is most often used in server mode responding to remote calls via either NRPE or check_nt. The closest thing to a client we get in normal mode of operation is NSCA where we submit data back. But NSClient++ can act as a client as well which is not just something I use for unit testing but something which can actually be useful in your monitoring environment.

check_cpu with top consumers in NSClient++ (part 1 of 2)

An often requested feature is to include the top-5 consumers of high CPU load in the result from check_cpu (or checkCpu). I have often discarded this as a non-core feature since it is not something I think should be part of NSClient++ instead I think it should be a script. Since no-one has created such a script I figured it would make a nice blog post so here I describe in a step by step guide how to create such a script for NSClient++.

Comments