→ Read more...

PNP supports several modes to process performance data. The modes differ in complexity and the performance to be expected.

The following image shows the connections between Nagios, PNP and RRDtool
Nagios invokes a command for every host and every service whose performance data should be processed. Depending on the mode you choose the data will be passed to process_perfdata.pl or will be written to temporary files and processed at a later time. process_perfdata.pl writes the data to XML files and stores them in RRD files using RRDtool.

Before you choose a mode please read the documentation and decide which way will be the best for installation.

→ Read more...

The installation of PNP will be described in more detail. It is expected that nagios was compiled from source and is located in /usr/local/nagios.
Attention: The description applies to PNP 0.4.14. Hints to the current version can be found here.
Please note that PNP has to be configured after the installation.

→ Read more...

The configuration of the already mentioned modes of performance data processing will be described in more detail.

→ Read more...

If everything went well until now you can try to call PNP using your web browser. On the assumption nagios can be reached using the URL /nagios PNP should be called using /nagios/pnp/index.php.

Called without any arguments PNP looks for RRD and XML files in share/perfdata and shows all graphs of the first host.

ATTENTION: Immediately after (re-)starting Nagios after you enabled the processing of performance data you will get error messages in your browser because performance data has to be collected and stored in RRD files. Depending on the check interval you are using you have to wait some time before you can view the graphs.

→ Read more...

Since PNP 0.4.12 the contrib directory contains a perl script (verify_pnp_config) which enables you to check the configuration settings as well as performance data of hosts or services. It can be used prior and during runtime of PNP.

* Note *: The information applies to verify_pnp_config v0.1.17 which is available in the current developer version (starting with SVN Rev. 644) downloadable via http://www.pnp4nagios.org/pnp/dwnld. Older versions may have fewer options so in the descriptions of the various options you will find hints to the PNP versions.
* Note *: The “long” options always start with two ”-” which isn't clearly visible in the text.

PNP-Version 0.4.12 contains verify_pnp_config 0.1.2
PNP-Version 0.4.13 contains verify_pnp_config 0.1.9
PNP-Version 0.4.14 contains verify_pnp_config 0.1.12

* Attention * 0.1.9 contains a bug which leads to an error message while checking the template definition in bulk and NPCD mode. The last parameter will be flagged as erroneous even if it is correct. Please add the statement $val .= “\\t”; prior to line 632 so that the lines look like this:

629	if ($val !~ /([A-Z]+?::[A-Z\$]+?.?)+/) {
630		info ("invTemplate");
631	}
632	$val .= "\\t";
633	while ($val =~ s/([A-Z]+?)::(.+?)([^A-Z\$].)//) {

* Attention * 0.1.12 contains bugs when checking performance data. If you need this feature then please use the current SVN version (starting with Rev. 633).
0.1.12 contains another bug which leads to an error message while checking the template definition in bulk and NPCD mode. SERVICEOUTPUT and HOSTOUTPUT resp. are reported missing but they don't belong to the template definition of PNP. They are in the default config file of Nagios instead (fixed in Rev. 639).

Checking the configuration can be done executing

./verify_pnp_config -m <mode>

replacing <mode> by default, bulk or NPCD.

Specifying the option -h or –-help respectively shows the following lines:

-h, --help        print these lines
-b, --basedir=s   Nagios Base directory (default: /usr/local/nagios)
-B, --binary=s    Nagios binary (default: nagios)
-c, --config=s    Nagios main config file (default: /usr/local/nagios/etc/nagios.cfg)
-m, --mode=s      PNP mode ("default", "bulk", "NPCD")
-l, --logfile=s   check configure log file
-N, --npcdcfg=s   PNP config file for NPCD mode (default: /usr/local/nagios/etc/pnp/npcd.cfg)
-P, --ppcfg=s     process_perfdata config file (default: /usr/local/nagios/etc/pnp/process_perfdata.cfg)
-p, --precheck    use config files instead of objects cache
-r, --rrdtool=s   specify the location of the RRDtool binary
-R, --RRDpath=s   specify the perfdata directory (default: /usr/local/nagios/share/perfdata) or "no" for no check
-U, --resource=s  location of the resource config file (default: /usr/local/nagios/etc/resource.cfg)
-M, --monitor=s   specify the monitoring product (default: nagios)
-L, --layout=s    specify a layout (Nagios2, Nagios3, SuSE, Fedora)
-T, --template=s  specify the path to the templates directory (default /usr/local/nagios/share/pnp/templates.dist)
-u, --user=s      user of the perfdata directory
-g, --group=s     group of the perfdata directory 	
-q, --quiet       quiet mode, non-zero return code will indicate errors
-o, --object=s    Nagios object (host name, service description)
-n, --native      show messages in native language (so far "es" or "de")
-e, --english     show english messages/links
-d, --debug       some debugging output

The Nagios program and access to the main configuration file are always necessary. If you have non-standard paths because you installed a Nagios package you can try to use one of the predefined layouts. “suse” and “fedora” should work on the appropriate distributions while “nagios2” and “nagios3” should work on other depending on the Nagios version you installed. If none of these methods work you can use three options (-b, -B and -c) to specify the nagios base directory, the name of the binary and the place of the main config file. If the program name starts with a ”/” then this value is taken as an absolute path which isn't modified anymore. If it doesn't start with a ”/” then the path is composed of the basedir, the string “bin” and the binary. Using -U you can specify the location on the resource config file. (-b / -c starting with PNP 0.4.12; -B starting with Rev. 612; -U starting with Rev. 635)

Without specifying any options the help page will be shown so you'll have to specify either the mode or an object.

Using the option -m (–mode) you specify one of the PNP modes whose settings will be checked. The option -l <filename> (–logfile=<filename>) allows to check the config during installation of PNP. You have to execute ./configure (with additional options if necessary) first which creates the file config.log. This name has to be passed as parameter value. The script checks if software requirements are met and if several settings have been specified correctly. That includes a call of the RRDtool binary so you may use the option -r <location> (–rrdtool <location>) if the binary can not be found at /usr/bin/rrdtool. (-m / -l starting with PNP 0.4.12, -r starting with PNP 0.4.13)

The script checks if owner and group of the directories and files below the perfdata folder correspond to the values given in nagios.cfg. Additionally the xml files are checked for non-zero return codes of RRDtool. Using the option -R (–RRDpath) you can specify the directory where the RRD files are located if its place is non-standard. If you don't wish these checks to be performed please specify “no” as directory name. Using the options -u (–user) and -g (–group) you can specify user and/or group of the perfdata directory if they don't match the values of the nagios user. (-R starting with PNP 0.4.14 / SVN Rev. 598; -u / -g starting with Rev. 635).

After the installation the changes in nagios.cfg can be checked using the option -p (–precheck) before restarting nagios. This way you can correct any errors without restarting every time.

Together with the option -o <object> (–object=<object>) you specify a string which is compared to hostnames and/or service descriptions in the objects cache file. The string should be enclosed in quotes to escape blanks and several special characters. If the string matches the name and any performance data will be shown. If no or invalid performance data is present appropriate messages will be given.

Appending a semicolon to the string will result in comparing only hostnames, prepending a semicolon only inspects service descriptions. A semicolon within the string separates hostname and service description.

• hostname/service description ⇒ string matches hostname or service description
• hostname; ⇒ string only matches against hostnames
• ;service description ⇒ string only matches against service descriptions
• hostname;service description ⇒ hostname and service description have to match

(-o starting with PNP 0.4.12, semicolon starting with PNP 0.4.13)

When using the NPCD mode you can use -N <config file> (–npcdcfg=<config file>) to specify the location of the config file if its name or location differs from the default (NAGIOS_BASE/etc/pnp/npcd.cfg) (-N starting with PNP 0.4.13).

Using the option -P <config file> (–ppcfg=<config file>) you can specify the name of the config file for process_perfdata.pl if name or location differs from the default (NAGIOS_BASE/etc/pnp/process_perfdata.cfg) (-P starting with PNP 0.4.13).

Using the option -M (–monitor) enables you to specify the product which delivers the data to PNP. The default is “nagios” but “icinga” is supported now as well. Additionally you may have to use the options -b, -B and -c as well. (-M starting with Rev. 640)

Sometimes changes in template files result in error which are hard to find in the web GUI. Using the option -T the template files are checked for errors. Specify the path to the templates diretory as a parameter. (-T starting with Rev. 655)

Using -n (–native) you can specify “es” or “de” to see spanish or german messages, respectively. (-e starting with Rev. 664, PNP 0.4.15)

The option -e (–english) enables you to force the use of english messages if the script detects german language settings (-e starting with PNP 0.4.13).

The option -d (–debug) will output additional lines which may help during trouble shooting whereas -q (–quiet) suppresses all output. Errors will result in a non-zero return code. (-d starting with PNP 0.4.12, -q starting with PNP 0.4.13)

Each output line will start with a letter indicating the type of information:

[I] informational message about settings, things to be done, …
[A] actions to be taken
[W] warning message
[E] error message: PNP will not work without resolving the problem(s)
[H] hint: it might be worth reading the appropriate documentation
[D] debugging message, hopefully showing the source of your problem
(one letter types starting with PNP 0.4.13).

Of course PNP should be easily accessible. You do not want to search long for the right graph.

Nagios itself features external URLs using so called extended info configs. Due to changes between Nagios 2.x and Nagios 3.x both versions are described.

→ Read more...

The behaviour of the PNP Web-Frontend can be controlled through the config file etc/pnp/config.php. This file will be overwritten during updates of PNP as the paths and options are detected during ./configure.

Own adjustments should be made in etc/php/config_local.php. If this file does not exist the file config.php can be taken as a guideline.

→ Read more...

In the overview PNP shows five timeranges which can be defined in config.php.

Additionally you can influence the end of the timeranges via the URL. This can be useful to automatically create PDF documents. The ranges can be defined using the option “end”.

Example:

 http://<Nagios host>/pnp/index.php?host=<hostname>&srv=<servicedesc>&end=-1week

The graph will end one week prior to the current date and time. The start will be adjusted depending on the selected view.

Examples of different specifications

Using relative offsets (-<n> <timeperiod>) results in timestamps relative to the current time otherwise the ending time is at midnight.

“pages” provide the opportunity to collect graphs of different hosts/services on one page. That way - as an example - you can display the traffic rates of all tape libraries. Regular expressions are possible so you can accomplish a lot with only few definitions - provided that you have appropriate names. The directory specified using “$conf['page_dir']” contains one or more file with the extension ”.cfg”.

The file name (without the extension) appears in the list of available pages and will be used as title of the browser window. Comments start with a hash-sign (#) and are possible within lines as well. Each file contains a “page” definition which specifies the name of the page and it determines whether the following graph definition contains regular expressions or not.
Attention: “host_name” and “service_desc” refer to the name of the file in the perfdata directory, not to the definition in Nagios. Blanks are replaced by underscores (_).

define  page  {
        use_regex 1		# 0 = use no regular expressions, 1 = use regular expressions
        page_name test-page	# page description
}

One or more “graph” definitions follow:

define graph {
        host_name       host1,host2,host3
        service_desc    Current_Load
}

define graph {
        host_name       host4
        service_desc    Current_Users
}

And now some definitions with regular expressions. At first all hosts whose names are starting with “Tape”:

define graph {
        host_name       ^Tape
        service_desc    Traffic
}

all hosts whose names are ending with “00”:

define graph {
        host_name       00$
        service_desc    Load
}

all services of localhost whose names contain “a” or “o”, respectively:

define graph {
        host_name       localhost
        service_desc    a|o
}

all services whose names contain an underscore followed by (at least) three digits on all hosts whose names start with “UX”:

define graph {
        host_name       ^UX
        service_desc    _\d{3}
}

PNP uses templates to influence the appearance of RRD graphs.

The selected check_command determines which template will be used to control the graph. Following will be described where templates are stored and how the decision for the “right” template is made.

→ Read more...

As already described under ”What are templates ?” the appearance of graphs depends on the check command used.

There are situations where this behaviour must be overruled. This has to be done when universal commands have been defined.

→ Read more...

If Nagios is implemented as a distributed system you have to decide where PNP should be installed.

From a technical view this question is not important. PNP can be installed on the slave(s) as well as on the master server. Or only on the master?

If PNP is running on the master you have to make sure that data passed via send_nsca from the slave server(s) contains performance data. Often another check command is used on the master.

To help PNP on the master to recognize which check command was used on the slave to collect the information process_perfdata.pl responds to an additional field at the end of the performance data.

OK - 127.0.0.1: rta 2.687ms, lost 0% | rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;; [check_icmp]

If PNP finds a string enclosed in brackets at the end of performance data it will be recognized as check command and will be used as PNP template.

Nagios documentation related to this topic can be found here. The command used in the documentation can be adapted easily.

define command{
	command_name	submit_check_result
	command_line	/usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$'
	}

should be changed to

define command{
	command_name	submit_check_result
	command_line	/usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$ | $SERVICEPERFDATA$ [$SERVICECHECKCOMMAND$]'
	}

→ Read more...

In big installations sooner or later one will recognize that processing the performance data will result in a relatively high I/O load. RRDtool has to do very much disk updates but cannot use the disk cache in an optimal way.

One improvement is made by collecting and sorting the data. It is more effective to write many updates to an RRD database in one block. The disk cache can be used more effectively that way.

The current RRDtool ( SVN trunk 1550+ ) contains rrdcached which should improve exactly this situation.

At this point I'd like to thank Florian octo Forster, Kevin Brintnall and Tobi Oetiker. The development of this daemon has been coordinated exemplary on the rrd-developers mailing list.

→ Read more...

NPCD (Nagios-Perfdata-C-Daemon) was written to provide an asynchronous mode to handle performance data with nagios.

→ Read more...