pnp4nagios/share/pnp/documents/en_US/tpl_custom.html

<h1><a name="custom_templates" id="custom_templates">Custom Templates</a></h1>
<div class="level1">

<p>

As already described under ”<a href="/pnp-0.6/tpl" class="wikilink1" title="pnp-0.6:tpl">What are templates ?</a>” the appearance of graphs depends on the check command used.
</p>

<p>
There are situations where this behaviour must be overruled, for example when universal commands have been defined.
</p>

<p>
PNP, especially process_perfdata.pl, will search for a config file (&lt;check_command&gt;;.cfg) in the etc/check_commands directory and read its contents (if available).
The following options can be defined in it:
</p>

</div>
<!-- SECTION "Custom Templates" [1-477] -->
<h2><a name="custom_template" id="custom_template">CUSTOM_TEMPLATE</a></h2>
<div class="level2">

<p>

Outgoing from the following example of a Nagios command-definition:

</p>
<pre class="code">
define command {
  command_name check_nrpe
  command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a &quot;$ARG2$&quot;
}
</pre>

<p>
This would lead to a call of the check_nrpe.php template even when the monitored host would use a completely different plugin which is called via NRPE.
</p>

<p>
As our example command is called check_nrpe it will be searched for etc/check_commands/check_nrpe.cfg.
</p>

<p>
During installation a sample config file with the extension .cfg-sample is copied to etc/check_commands.
</p>
<pre class="code">
# check_command check_nrpe!load!-w 4,4,4 -c 5,5,5
# ________0__________|       |       |
# ________1__________________|       |
# ________2__________________________|
#
CUSTOM_TEMPLATE = 1
</pre>

<p>
<code>CUSTOM_TEMPLATE = 1</code> assures that only the contents of $ARG1$ will be used as a template name. As $ARG1$ contains “load” in this example the template name would result in “load.php”.
</p>

<p>
<code>CUSTOM_TEMPLATE = 0,1</code> results in → “check_nrpe_load.php”
</p>

<p>
<code>CUSTOM_TEMPLATE = 1,0</code> results in → “load_check_nrpe.php”
</p>

<p>
This option has effect only during creation of the RRD database.
</p>

</div>
<!-- SECTION "CUSTOM_TEMPLATE" [478-1657] -->
<h2><a name="datatype" id="datatype">DATATYPE</a></h2>
<div class="level2">

<p>

The option “DATATYPE” controls the datatype which is used during creation of the RRD database. Default is “GAUGE”. For consecutive values the type should be “COUNTER”. Plugin-developers should use the unit “c” for counters but this is not always the case.
</p>

<p>
To set all datasources to COUNTER

</p>
<pre class="code">DATATYPE = COUNTER</pre>

<p>
Setting datasources to different types

</p>
<pre class="code">DATATYPE = GAUGE,GAUGE,COUNTER,COUNTER</pre>

<p>
More datatypes are explained in the RRDTool documentation found at <a href="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html" class="urlextern" title="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html"  rel="nofollow">rrdcreate</a>.
</p>

<p>
This option has effect only during creation of the RRD database.
</p>

</div>
<!-- SECTION "DATATYPE" [1658-2296] -->
<h2><a name="use_min_on_create_and_use_max_on_create" id="use_min_on_create_and_use_max_on_create">USE_MIN_ON_CREATE and USE_MAX_ON_CREATE</a></h2>
<div class="level2">

<p>

In a few situations it might be necessary to limit the values which are valid for RRDTool.
</p>

<p>
RRD databases can be created with fixed minimum and maximum values. You will find further details at <a href="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html" class="urlextern" title="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html"  rel="nofollow">http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html</a>.
</p>

<p>
Account for the maximum value taken from the performance data

</p>
<pre class="code">USE_MAX_ON_CREATE = 1</pre>

<p>
Account for the minimum value taken from the performance data

</p>
<pre class="code">USE_MIN_ON_CREATE = 1</pre>

<p>
This option has effect only during creation of the RRD database.
</p>

</div>
<!-- SECTION "USE_MIN_ON_CREATE and USE_MAX_ON_CREATE" [2297-2858] -->
<h2><a name="rrd_storage_type" id="rrd_storage_type">RRD_STORAGE_TYPE</a></h2>
<div class="level2">
<pre class="code">RRD_STORAGE_TYPE = SINGLE</pre>

<p>

The option RRD_STORAGE_TYPE defines the kind of data storage.
</p>

<p>
Possible values are MULTIPLE and SINGLE, respectively.
</p>

<p>
SINGLE: A RRD database per service
</p>

<p>
MULTIPLE: One or more RRD databases per service. Each datasource will be stored in a separate RRD database.
</p>

<p>
<strong>ATTENTION:</strong> The data will not be migrated automatically!
You will find a conversion script <a href="/pnp-0.6/rrd_convert" class="wikilink1" title="pnp-0.6:rrd_convert">here</a>.
</p>

<p>
This option has effect only during creation of the RRD database.
</p>

</div>
<!-- SECTION "RRD_STORAGE_TYPE" [2859-3374] -->
<h2><a name="rrd_heartbeat" id="rrd_heartbeat">RRD_HEARTBEAT</a></h2>
<div class="level2">

<p>

<strong>Starting with PNP 0.6.1</strong>
</p>
<pre class="code">RRD_HEARTBEAT = 305</pre>

<p>
After &lt;RRD_HEARTBEAT&gt; seconds RRDtool expects new data.
</p>

<p>
More information at <a href="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html" class="urlextern" title="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html"  rel="nofollow">http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html</a>
</p>

<p>
This option has effect only during creation of the RRD database.
</p>

</div>
<!-- SECTION "RRD_HEARTBEAT" [3375-3660] -->
<h2><a name="hints_on_template_names" id="hints_on_template_names">Hints on Template Names</a></h2>
<div class="level2">

<p>

In most situations, one can easily get desired template names, by using suitable command object definitions.
</p>

<p>
Consider the followng example:

</p>
<pre class="code">
define command {
  command_name check_by_ssh
  command_line /usr/bin/ssh $HOSTADDRESS$ $ARG1$
}
</pre>

<p>

with commands like:

</p>
<pre class="code">
  …
  check_command check_by_ssh!/usr/lib/nagios/plugins/check_load -w 4,4,4 -c 5,5,5
  …
</pre>

<p>
Even when using “CUSTOM_TEMPLATE = 1” one would end up in template names like “_usr_lib_nagios_plugins_check_load_-w_4,4,4_-c_5,5,5”, which is highly undesired, especially because of the parameters in it.
</p>

<p>
<strong>Solution 1: Split parameters into separate $ARGn$</strong>
</p>

<p>
A simple solution is to use the following command object definition:

</p>
<pre class="code">
define command {
  command_name check_by_ssh
  command_line /usr/bin/ssh $HOSTADDRESS$ $ARG1$ $ARG2$
}
</pre>

<p>

with commands like:

</p>
<pre class="code">
  …
  check_command check_by_ssh!/usr/lib/nagios/plugins/check_load!-w 4,4,4 -c 5,5,5
  …
</pre>

<p>

(notice the additional “!”)
</p>

<p>
This even works, when $ARG2$ is let empty.
</p>

<p>
Of course one would still need to set “CUSTOM_TEMPLATE = 1”.
</p>

<p>

<strong>Solution 2: Hide the remote executor inside the command object definition</strong>
</p>

<p>
Another way is to “hide” the remote excutor in the respective command object definitions.
</p>

<p>
Instead of defining:

</p>
<pre class="code">
define command {
  command_name check_by_ssh
  command_line /usr/bin/ssh $HOSTADDRESS$ $ARG1$ $ARG2$
}
</pre>

<p>

one would define the following for <strong>every</strong> command to be remotely executed:

</p>
<pre class="code">
define command {
  command_name check_load_by_ssh
  command_line /usr/bin/ssh $HOSTADDRESS$ /usr/lib/nagios/plugins/check_load $ARG1$
}
</pre>

<p>

with commands like:

</p>
<pre class="code">
  …
  check_load_by_ssh!-w 4,4,4 -c 5,5,5
  …
</pre>

<p>

Of course one must not set “CUSTOM_TEMPLATE = 1” in this way.
</p>

<p>

Which of above two solutions one follows is largely a matter of taste.
</p>

<p>
<a href="/pnp-0.6/start" class="wikilink1" title="pnp-0.6:start">back to contents</a> | <a href="/pnp-0.6/advanced" class="wikilink1" title="pnp-0.6:advanced">PNP in distributed environments</a>

</p>

</div>
<!-- SECTION "Hints on Template Names" [3661-] -->