File: plugins.html

package info (click to toggle)
icinga 1.14.2%2Bds-3
  • links: PTS, VCS
  • area: main
  • in suites: buster
  • size: 49,264 kB
  • sloc: ansic: 108,564; sql: 9,656; sh: 4,945; perl: 3,439; makefile: 1,213; php: 581; xml: 104
file content (649 lines) | stat: -rw-r--r-- 32,311 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>5.1. Icinga Plugins</title>
<link rel="stylesheet" href="../stylesheets/icinga-docs.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.75.1">
<meta name="keywords" content="Supervision, Icinga, Nagios, Linux">
<link rel="home" href="index.html" title="Icinga Version 1.14 Documentation">
<link rel="up" href="ch05.html" title="Chapter 5. The Basics">
<link rel="prev" href="ch05.html" title="Chapter 5. The Basics">
<link rel="next" href="macros.html" title="5.2. Understanding Macros and How They Work">
<script src="../js/jquery-min.js" type="text/javascript"></script><script src="../js/icinga-docs.js" type="text/javascript"></script>
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<CENTER><IMG src="../images/logofullsize.png" border="0" alt="Icinga" title="Icinga"></CENTER>
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">5.1. Icinga Plugins</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="ch05.html">Prev</a> </td>
<th width="60%" align="center">Chapter 5. The Basics</th>
<td width="20%" align="right"> <a accesskey="n" href="macros.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="section" title="5.1. Icinga Plugins">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="plugins"></a>5.1. <a name="Icinga_plugins"></a>Icinga Plugins</h2></div></div></div>
<div class="toc"><dl>
<dt><span class="section">5.1.1. <a href="plugins.html#introduction_plugins">Introduction</a></span></dt>
<dt><span class="section">5.1.2. <a href="plugins.html#plugins-overview">What Are Plugins?</a></span></dt>
<dt><span class="section">5.1.3. <a href="plugins.html#abstractionlayer">Plugins As An Abstraction Layer</a></span></dt>
<dt><span class="section">5.1.4. <a href="plugins.html#plugins-available">What Plugins Are Available?</a></span></dt>
<dt><span class="section">5.1.5. <a href="plugins.html#plugins-obtaining">Obtaining Plugins</a></span></dt>
<dt><span class="section">5.1.6. <a href="plugins.html#plugins-hints">Switch to the Icinga user</a></span></dt>
<dt><span class="section">5.1.7. <a href="plugins.html#plugins-extending">Extending the environment</a></span></dt>
<dt><span class="section">5.1.8. <a href="plugins.html#plugins-howto">How Do I Use Plugin X?</a></span></dt>
<dt><span class="section">5.1.9. <a href="plugins.html#plugins-new_plugin">Integrating a new plugin</a></span></dt>
<dt><span class="section">5.1.10. <a href="plugins.html#plugins-rawcommandline">Raw command line</a></span></dt>
<dt><span class="section">5.1.11. <a href="plugins.html#plugins-thresholdranges">Threshold and ranges</a></span></dt>
<dt><span class="section">5.1.12. <a href="plugins.html#plugins-errors">Activating the definition</a></span></dt>
<dt><span class="section">5.1.13. <a href="plugins.html#pluginsapi">Plugin API</a></span></dt>
</dl></div>
  

  <div class="section" title="5.1.1. Introduction">
<div class="titlepage"><div><div><h3 class="title">
<a name="introduction_plugins"></a>5.1.1. Introduction</h3></div></div></div>
    

    <p>Unlike many other monitoring tools, Icinga does not include any internal mechanisms for checking the status of hosts and
    services on your network. Instead, Icinga relies on external programs (called plugins) to do all the dirty work.</p>
  </div>

  <div class="section" title="5.1.2. What Are Plugins?">
<div class="titlepage"><div><div><h3 class="title">
<a name="plugins-overview"></a>5.1.2. What Are Plugins?</h3></div></div></div>
    

    <p>Plugins are compiled executables or scripts (Perl scripts, shell scripts, etc.) that can be run from a command line to check the
    status or a host or service. Icinga uses the results from plugins to determine the current status of hosts and services on your
    network.</p>

    <p>Icinga will execute a plugin whenever there is a need to check the status of a service or host. The plugin does
    <span class="emphasis"><em>something</em></span> (notice the very general term) to perform the check and then simply returns the results to Icinga.
    Icinga will process the results that it receives from the plugin and take any necessary actions (running <a class="link" href="eventhandlers.html" title="7.3. Event Handlers">event handlers</a>, sending out <a class="link" href="notifications.html" title="5.11. Notifications">notifications</a>, etc).</p>
  </div>

  <div class="section" title="5.1.3. Plugins As An Abstraction Layer">
<div class="titlepage"><div><div><h3 class="title">
<a name="abstractionlayer"></a>5.1.3. Plugins As An Abstraction Layer</h3></div></div></div>
    

    <p><span class="inlinemediaobject"><img src="../images/plugins.png"></span></p>

    <p>Plugins act as an abstraction layer between the monitoring logic present in the Icinga daemon and the actual services and
    hosts that are being monitored.</p>

    <p>The upside of this type of plugin architecture is that you can monitor just about anything you can think of. If you can automate
    the process of checking something, you can monitor it with Icinga. There are already a lot of plugins that have been created in
    order to monitor basic resources such as processor load, disk usage, ping rates, etc. If you want to monitor something else, take a look
    at the documentation on <a class="link" href="pluginapi.html" title="11.1. Icinga Plugin API">writing plugins</a> and roll your own. It's simple!</p>

    <p>The downside to this type of plugin architecture is the fact that Icinga has absolutely no idea what it is that you're
    monitoring. You could be monitoring network traffic statistics, data error rates, room temperature, CPU voltage, fan speed, processor
    load, disk space, or the ability of your super-fantastic toaster to properly brown your bread in the morning... Icinga doesn't
    understand the specifics of what's being monitored - it just tracks changes in the <span class="emphasis"><em>state</em></span> of those resources. Only
    the plugins themselves know exactly what they're monitoring and how to perform the actual checks.</p>
  </div>

  <div class="section" title="5.1.4. What Plugins Are Available?">
<div class="titlepage"><div><div><h3 class="title">
<a name="plugins-available"></a>5.1.4. What Plugins Are Available?</h3></div></div></div>
    

    <p>There are plugins currently available to monitor many different kinds of devices and services, including:</p>

    <div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
        <p>HTTP, POP3, IMAP, FTP, SSH, DHCP</p>
      </li>
<li class="listitem">
        <p>CPU Load, Disk Usage, Memory Usage, Current Users</p>
      </li>
<li class="listitem">
        <p>Unix/Linux, Windows, and Netware Servers</p>
      </li>
<li class="listitem">
        <p>Routers and Switches</p>
      </li>
<li class="listitem">
        <p>etc.</p>
      </li>
</ul></div>
  </div>

  <div class="section" title="5.1.5. Obtaining Plugins">
<div class="titlepage"><div><div><h3 class="title">
<a name="plugins-obtaining"></a>5.1.5. Obtaining Plugins</h3></div></div></div>
    

    <p>Plugins are not distributed with Icinga, but you can download the official Nagios plugins and many additional
    plugins created and maintained by Nagios and Icinga users from the following locations:</p>

    <div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
        <p>Monitoring Plugins Project: <a class="link" href="https://www.monitoring-plugins.org" target="_top">https://www.monitoring-plugins.org</a></p>
      </li>
<li class="listitem">
        <p>Monitoring Plugins Downloads Page: <a class="link" href="https://www.monitoring-plugins.org/download.html" target="_top">https://www.monitoring-plugins.org/download.html</a></p>
      </li>
<li class="listitem">
        <p>Icinga Exchange: <a class="link" href="https://exchange.icinga.org" target="_top">https://exchange.icinga.com</a></p>
      </li>
</ul></div>

    <p>After downloading you have to install the plugin(s). Please check the accompanied documentation on how to do that. It may contain
    important information about the prerequisites like additional packages, (perl) modules and on how to install the plugin together with
    hints for your distribution.</p>

    <p>Sometimes you have to compile the plugin preparing the compile process using "<code class="code">./configure</code>" with or without options.
    Please check the file <code class="filename">config.log</code> for errors regarding missing (devel) packages before issuing the actual compile
    command (mostly "make" or "make all"). In most cases the plugin is copied to the plugins directory (i.e.
    <code class="filename">/usr/local/icinga/libexec</code>) during "make install".</p>

    <p>Sometimes you have to alter the plugin to reflect your environment (i.e. path to "utils.pm", ...). You may create a logical link
    pointing to the plugin directory instead so you don't have to change the plugin to circumvent this issue easing plugin updates later on
    doing something like</p>

    <pre class="programlisting"> $&gt; mkdir /usr/local/nagios
 $&gt; ln -s /usr/local/icinga/libexec /usr/local/nagios/libexec</pre>

    <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.png"></td>
<th align="left">Note</th>
</tr>
<tr><td align="left" valign="top">
      <p>Using packages the path to the plugins directory might be different (e.g. <code class="filename">/usr/lib/plugins</code>) so please
      change that accordingly.</p>
    </td></tr>
</table></div>
  </div>

  <div class="section" title="5.1.6. Switch to the Icinga user">
<div class="titlepage"><div><div><h3 class="title">
<a name="plugins-hints"></a>5.1.6. Switch to the Icinga user</h3></div></div></div>
    

    <div class="important" title="Important" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Important">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Important]" src="../images/important.png"></td>
<th align="left">Important</th>
</tr>
<tr><td align="left" valign="top">
      <p>Always execute the plugin using the Icinga user (specified using the directive icinga_user in
      <code class="filename">icinga.cfg</code>) because some plugins will create temporary files. If you're testing plugins with another user then
      the Icinga user may not have the permissions to overwrite existing files later on. Using another user you will not be able to
      find out if the Icinga user is allowed to access several files (e.g. shared libraries) at all.</p>

      <p>When testing it don't call the plugin using relative paths (i.e <code class="filename">./check_test_plugin</code>). Always use absolute
      paths because that's the way Icinga does it (i.e. <code class="filename">/usr/local/icinga/libexec/check_test_plugin</code>).</p>

      <p>Please note that the Icinga <span class="emphasis"><em>user</em></span> has a different environment than the Icinga
      <span class="emphasis"><em>process</em></span>. Using the first the logins script have been executed and there is a terminal connected to the user
      session so successfully running the plugin from the command line doesn't (necessarly) mean that it will run when executed by the
      process. Furthermore the process will not use a shell per default but execute calls to popen/execvp instead depending on the command
      (popen in case the command line contains meta characters meaningful to the shell like
      <code class="literal">!$^&amp;*()~[]\|{};&lt;&gt;?'"</code>, execvp if no meta characters are present).</p>
    </td></tr>
</table></div>

    <p>Switch to the Icinga user as defined in <code class="filename">icinga.cfg</code> unless already done and clear the
    environment</p>

    <pre class="screen"> #&gt; su - icinga
 #&gt; env -i</pre>

    <p>If you are logged in now then skip to "Extending the environment"</p>

    <p>Due to security awareness of the packager / sys admin this might fail because the account is not allowed to login. Please ask your
    sys admin to change that temporarily or do one of the following</p>

    <div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
        <p>get the current shell from <code class="filename">/etc/passwd</code> and change it by issuing something similar to </p>
<pre class="screen"> #&gt; OLD_SHELL=`grep icinga /etc/passwd | sed 's/.*://'`
 #&gt; usermod -s /bin/sh icinga</pre>
<p>execute the command(s) after switching to the Icinga user and clearing the environment as
        described above</p>

        <p>don't forget to restore the shell setting after testing and leaving the session </p>
<pre class="screen"> #&gt; usermod -s $OLD_SHELL icinga</pre>
      </li>
<li class="listitem">
        <p>execute the command using "sudo -u icinga"</p>

        <pre class="screen"> #&gt; sudo -u icinga /usr/local/icinga/libexec/sample-plugin.pl ...</pre>
      </li>
</ul></div>
  </div>

  <div class="section" title="5.1.7. Extending the environment">
<div class="titlepage"><div><div><h3 class="title">
<a name="plugins-extending"></a>5.1.7. Extending the environment</h3></div></div></div>
    

    <p>Several checks (like check_oracle_health) depend on various environment variables to be set. Don't put these in
    <code class="filename">.bashrc</code> or similar user dependent files but choose a central location. The default init script sources the file
    <code class="filename">/etc/sysconfig/icinga</code> so that would be an ideal place. Don't use the init script itself because your changes might
    be lost during updates.</p>

    <p>Example of <code class="filename">/etc/sysconfig/icinga</code></p>

    <pre class="programlisting"> export ORACLE_HOME=/usr/lib/oracle/11.2/client64
 export LD_LIBRARY_PATH=$ORACLE_HOME/lib
 export PATH=$PATH:$ORACLE_HOME</pre>
<p>After you logged in these variables are not set but doing so is pretty easy</p>

    <pre class="screen"> $&gt; . /etc/sysconfig/icinga</pre>
<p>Please verify the settings</p>
<pre class="screen"> $&gt; echo $ORACLE_HOME
 $&gt; echo $LD_LIBRARY_PATH
 $&gt; echo $PATH</pre>
  </div>

  <div class="section" title="5.1.8. How Do I Use Plugin X?">
<div class="titlepage"><div><div><h3 class="title">
<a name="plugins-howto"></a>5.1.8. How Do I Use Plugin X?</h3></div></div></div>
    

    <p>Nearly all plugins will display basic usage information when you execute them using '<code class="code">-h</code>' or '<code class="code">--help</code>' on
    the command line. For example, if you want to know how the check_http plugin works or what options it accepts, you should try executing
    the following command:</p>

    <pre class="screen"> $&gt; ./check_http --help</pre>
  </div>

  <div class="section" title="5.1.9. Integrating a new plugin">
<div class="titlepage"><div><div><h3 class="title">
<a name="plugins-new_plugin"></a>5.1.9. Integrating a new plugin</h3></div></div></div>
    

    <p>After the installation of the plugin (see "<a class="link" href="plugins.html#plugins-obtaining" title="5.1.5. Obtaining Plugins">Obtaining plugins</a>") call it from the command
    line using the appropriate options. If this works then you can integrate it into Icinga.</p>

    <p>Let's imagine you used the following call on the command line</p>

    <pre class="programlisting"> $&gt; /usr/local/icinga/libexec/sample-plugin.pl -H 192.168.1.2 -a argument1 -p parameter -n 5</pre>

    <p>The command definition has to contain two directives</p>

    <div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
        <p>command_name: this is a short name identifying the command, let's use <span class="emphasis"><em>check_sample</em></span></p>
      </li>
<li class="listitem">
        <p>command_line: here you define the command to execute. You can specify the command you executed on the command line but that
        would be very inflexible. Normally the plugin directory (/usr/local/icinga/libexec) remains the same so we can use a <a class="link" href="macrolist.html#macrolist-user">$USERn$</a> variable which is defined in <code class="filename">resource.cfg</code>. The IP-address changes from
        host to host. There is a macro called <a class="link" href="macrolist.html#macrolist-hostaddress">$HOSTADDRESS$</a> which we can use for that purpose.
        The value of the arguments may vary so these should be flexible, too. This may lead to the following definition:</p>
      </li>
</ul></div>

    <pre class="programlisting"> define command{
    command_name check_sample
    command_line $USER1$/sample-plugin.pl -H $HOSTADDRESS$ -a $ARG1$ -p $ARG2$ -n $ARG3$
    }</pre>

    <p>Then we have to define the check_command directive which is part of the host/service definition starting with the short name
    followed by the arguments separated by exclamation marks (!):</p>

    <pre class="programlisting"> check_command check_sample!argument1!parameter!5</pre>

    <p>As you can see the IP-address is not specified because it is taken from the host definition.</p>

    <p>Putting it all together in reverse order shows how Icinga will process the information:</p>

    <pre class="programlisting"> check_command check_sample!argument1!parameter!5
                                |         |     +-------------------------------------+
                                |         +---------------------------------+         |
                                +---------------------------------+         |         |
                                                                  |         |         |
 Host macro ----------------------------------------+             |         |         |
                                                    |             |         |         |
 User macro --------+                               |             |         |         |
                    |                               |             |         |         |
 command_line      $USER1$/sample-plugin.pl -H $HOSTADDRESS$ -a $ARG1$ -p $ARG2$ -n $ARG3$

results in:

 /usr/local/icinga/libexec/sample-plugin.pl -H 192.168.1.2 -a argument1 -p parameter -n 5</pre>

    <p><a name="plugins-hints2"></a>In addition to the <a class="link" href="macros.html" title="5.2. Understanding Macros and How They Work">macros</a> already mentioned there are a lot of
    others making life easier. Please note:</p>

    <div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
        <p>All Icinga macros use all upper case and are enclosed in dollar signs ($)</p>
      </li>
<li class="listitem">
        <p>Most macros are only valid for some types of commands. If you try to use a macro for a type of command for which it is not
        valid you'll get a dollar sign ($) instead of the expected value</p>
      </li>
<li class="listitem">
        <p>The <a class="link" href="macrolist.html#macrolist-user">$USERn$</a> macros can be used to "hide" sensitive information like passwords because
        these values are not shown in the web interface. Additionally they can be used to specify special characters which otherwise may
        lead to problems. One example would be <code class="literal">USER99=;</code>. This way you can use a semicolon which otherwise would be
        treated as start of a comment within your definitions</p>
      </li>
<li class="listitem">
        <p>Native non-english speaking persons should note that <a class="link" href="macrolist.html#macrolist-hostaddress">$HOSTADDRESS$</a> is written
        with a double "D"</p>
      </li>
</ul></div>

    <p><a name="plugins-nrpe"></a><span class="bold"><strong>NRPE and "dont_blame_nrpe=1"</strong></span></p>

    <p>Using NRPE with arguments requires some attention. Given that you have enabled argument processing on the remote server in
    <code class="filename">nrpe.cfg</code> using "dont_blame_nrpe=1" (or "allow_arguments=1" in <code class="filename">nsc.ini</code>) you can pass parameters
    from the Icinga server to the remote machine. Let us assume some definitions</p>

    <p>On the Icinga server</p>
<pre class="programlisting"> define command{
    command_name check_nrpe
    command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
    }

 define service{
    ...
    check_command check_nrpe!check_process!cupsd</pre>
<p>on the remote server in the NRPE config file</p>
<pre class="programlisting">...
command[check_process]=your_plugin "$ARG1$"</pre>
<p> The Icinga process will resolve the definitions as follows</p>

    <pre class="programlisting"> check_command check_nrpe!check_process!cupsd
                                |         |
                                |         +---------------------------+
                                +---------------------------+         |
                                                            |         |
 Host macro ----------------------------------+             |         |
                                              |             |         |
 User macro --------+                         |             |         |
                    |                         |             |         |
 command_line      $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$

results in:

 /usr/local/icinga/libexec/check_nrpe -H 192.168.1.2 -c check_process -a cupsd</pre>

    <p>On the remote machine the NRPE process receives a call providing two parameters: "check_process" and "cupsd". The first is
    stripped to determine the command to be executed so only <span class="bold"><strong>one</strong></span> argument is passed to the command!</p>

    <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.png"></td>
<th align="left">Note</th>
</tr>
<tr><td align="left" valign="top">
      <p>$ARG1$ on the remote machine is <span class="bold"><strong>not</strong></span> the same as on the Icinga server!</p>
    </td></tr>
</table></div>
  </div>

  <div class="section" title="5.1.10. Raw command line">
<div class="titlepage"><div><div><h3 class="title">
<a name="plugins-rawcommandline"></a>5.1.10. Raw command line</h3></div></div></div>
    

    <p>The classic UI allows to inspect the raw command line including values from <code class="filename">resource.cfg</code>. Clicking on
    "ACTIVE" next to "Check type" within host/service check details will give access to this information. If you don't have defined a check
    yet choose "View Config" from the main menu on the left, then "Command expansion". Please note that the user has to be permitted
    explicitly using the directive <a class="link" href="configcgi.html#configcgi-authorized_for_full_command_resolution">authorized_for_full_command_resolution</a> in <code class="filename">cgi.cfg</code>
    to see the values of variables from <code class="filename">resource.cfg</code>. The user running the web server must have read access on this
    file, too.</p>

    <p>If you intend to log the raw command line then change some directives in <code class="filename">icinga.cfg</code> to the following
    values</p>

    <pre class="programlisting"> #  16 = Host/service checks
 # 256 = Commands
 debug_level=272
 debug_verbosity=2
 max_debug_file_size=1000000000</pre>
  </div>

  <div class="section" title="5.1.11. Threshold and ranges">
<div class="titlepage"><div><div><h3 class="title">
<a name="plugins-thresholdranges"></a>5.1.11. Threshold and ranges</h3></div></div></div>
    

    <p>Some plugins support specifying ranges for the warning and critical values. Please check the documentation if this is the case for
    the plugin you want to use. The following is an excerpt from the <a class="link" href="https://www.monitoring-plugins.org/doc/guidelines.html#THRESHOLDFORMAT" target="_top">developer guidelines</a>:</p>

    <p>A range is defined as a start and end point (inclusive) on a numeric scale (possibly negative or positive infinity).</p>

    <p>A threshold is a range with an alert level (either warning or critical).</p>

    <p>The theory is that the plugin will do some sort of check which returns back a numerical value, or metric, which is then compared
    to the warning and critical thresholds.</p>

    <p>This is the generalised format for ranges:</p>

    <p><code class="code">[@]start:end</code></p>

    <p>Notes:</p>

    <div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem">
        <p>start = end if :end is not specified</p>
      </li>
<li class="listitem">
        <p>start and ":" is not required if start=0</p>
      </li>
<li class="listitem">
        <p>if range is of format "start:" and end is not specified, assume end is infinity</p>
      </li>
<li class="listitem">
        <p>to specify negative infinity, use "~"</p>
      </li>
<li class="listitem">
        <p>alert is raised if metric is outside start and end range (inclusive of endpoints)</p>
      </li>
<li class="listitem">
        <p>if range starts with "@", then alert if inside this range (inclusive of endpoints)</p>
      </li>
</ol></div>

    <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.png"></td>
<th align="left">Note</th>
</tr>
<tr><td align="left" valign="top">
      <p>Not all plugins are coded to expect ranges in this format yet.</p>
    </td></tr>
</table></div>

    <p>Example ranges</p>
<div class="informaltable">
        <table border="1">
<colgroup>
<col>
<col>
</colgroup>
<tbody>
<tr>
<td><span class="bold"><strong>Range definition</strong></span></td>
<td><span class="bold"><strong>Generate an alert if x...</strong></span></td>
</tr>
<tr>
<td>10</td>
<td>&lt; 0 or &gt; 10, (outside the range of {0 .. 10})</td>
</tr>
<tr>
<td>10:</td>
<td>&lt; 10, (outside {10 .. infinity})</td>
</tr>
<tr>
<td>~:10</td>
<td>&gt; 10, (outside the range of {-infinity .. 10})</td>
</tr>
<tr>
<td>10:20</td>
<td>&lt; 10 or &gt; 20, (outside the range of {10 .. 20})</td>
</tr>
<tr>
<td>@10:20</td>
<td>&gt;= 10 and &lt;= 20, (inside the range of {10 .. 20})</td>
</tr>
</tbody>
</table>
      </div>

    <p>Command line examples</p>
<div class="informaltable">
        <table border="1">
<colgroup>
<col>
<col>
</colgroup>
<tbody>
<tr>
<td><span class="bold"><strong>Command line</strong></span></td>
<td><span class="bold"><strong>Meaning</strong></span></td>
</tr>
<tr>
<td>check_stuff -w10 -c20</td>
<td>Critical if "stuff" is over 20, else warn if over 10 (will be critical if "stuff" is less than 0)</td>
</tr>
<tr>
<td>check_stuff -w~:10 -c~:20</td>
<td>Same as above. Negative "stuff" is OK</td>
</tr>
<tr>
<td>check_stuff -w10: -c20</td>
<td>Critical if "stuff" is over 20, else warn if "stuff" is below 10 (will be critical if "stuff" is less than 0)</td>
</tr>
<tr>
<td>check_stuff -c1:</td>
<td>Critical if "stuff" is less than 1</td>
</tr>
<tr>
<td>check_stuff -w~:0 -c10</td>
<td>Critical if "stuff" is above 10; Warn if "stuff" is above zero</td>
</tr>
<tr>
<td>check_stuff -c5:6</td>
<td>The only noncritical range is 5:6</td>
</tr>
<tr>
<td>check_stuff -c@10:20</td>
<td>Critical if "stuff" is 10 to 20 <span class="bold"><strong>[1]</strong></span>
</td>
</tr>
<tr>
<td>check_stuff -w20:30 -c10:40</td>
<td>Warning if "stuff" below 20 or above 30, critical if "stuff" is below 10 or above 40 <span class="bold"><strong>[2]</strong></span>
</td>
</tr>
</tbody>
</table>
      </div>

    <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.png"></td>
<th align="left">Note</th>
</tr>
<tr><td align="left" valign="top">
      <p>[1]: The command line of the developer guidelines seems to be lacking "@" otherwise the meaning would be wrong (and there
      wouldn't be an example for the @ notation)</p>

      <p>[2]: Please note that the last example shows nested ranges. This might not even work with every plugin supporting ranges. It was
      tested using check_snmp.</p>
    </td></tr>
</table></div>
  </div>

  <div class="section" title="5.1.12. Activating the definition">
<div class="titlepage"><div><div><h3 class="title">
<a name="plugins-errors"></a>5.1.12. Activating the definition</h3></div></div></div>
    

    <p>Check the configuration using "/etc/init.d/icinga show-errors" and resolve any errors before issuing "/etc/init.d/icinga restart".
    Wait until the object is checked and look at the status details. There might be errors.</p>

    <div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
        <p>"...resulted in a return code of 127" / "out of bounds"</p>

        <p>This means the plugin was not found at the specified location or that a file called from within the plugin was not found. If
        you use $USERn$ macros calling the plugin then make sure that the macro really points to the location where the plugin is (is the
        macro defined in resource.cfg?). Notification commands often call a mail program. Make sure that the path to the mail program is
        correct.</p>
      </li>
<li class="listitem">
        <p>"...resulted in a return code of 126"</p>

        <p>Mostly this indicates a permissions problem. The process might not be able to access / execute the plugin and/or other related
        files.</p>
      </li>
<li class="listitem">
        <p>"...resulted in a return code of 13".</p>

        <p>Mostly this indicates a permissions problem. The user might not be able to access / execute the plugin and/or other related
        files. This might happen if you tested a plugin as root which creates temporary files. The Icinga user is not allowed to
        overwrite these files.</p>
      </li>
<li class="listitem">
        <p>"(null)"</p>

        <p>The internal call to execvp didn't return anything.</p>
      </li>
</ul></div>
  </div>

  <div class="section" title="5.1.13. Plugin API">
<div class="titlepage"><div><div><h3 class="title">
<a name="pluginsapi"></a>5.1.13. Plugin API</h3></div></div></div>
    

    <p>You can find information on the technical aspects of plugins, as well as how to go about creating your own custom plugins <a class="link" href="pluginapi.html" title="11.1. Icinga Plugin API">here</a>.</p>

    <a class="indexterm" name="idm140381631575808"></a>

    <a class="indexterm" name="idm140381631574080"></a>

    <a class="indexterm" name="idm140381631572944"></a>

    <a class="indexterm" name="idm140381631571392"></a>

    <a class="indexterm" name="idm140381631569664"></a>

    <a class="indexterm" name="idm140381631568144"></a>

    <a class="indexterm" name="idm140381631566416"></a>

    <a class="indexterm" name="idm140381631564928"></a>

    <a class="indexterm" name="idm140381631563168"></a>

    <a class="indexterm" name="idm140381631561648"></a>
  </div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="ch05.html">Prev</a> </td>
<td width="20%" align="center"><a accesskey="u" href="ch05.html">Up</a></td>
<td width="40%" align="right"> <a accesskey="n" href="macros.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Chapter 5. The Basics </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td>
<td width="40%" align="right" valign="top"> 5.2. Understanding Macros and How They Work</td>
</tr>
</table>
</div>
<P class="copyright">© 1999-2009 Ethan Galstad, 2009-2017 Icinga Development Team, https://www.icinga.com</P>
</body>
</html>